Genesys Cloud - Main

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Hello, thank you for the detailed explanation. 

Is there a way to test this prior to March 9, 2026 or the only action we can do is to ask the provider to inspect the TLS trace and look for the "Certificate Request"?

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Hi - can you confirm that this is still going ahead on March 9th?

We had feedback from Cisco regarding the CUBEs they said that there is no way to prevent them doing mTLS and that the calls will fail. Cisco will release a new firmware to allow TLS to establish in the future prior to May 9th but this is not yet available (see: https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74350.html).

Have you checked how many user agents are cisco cubes currently connecting to BYOC because if these certs are replaced then all of those customers will not be able to make outbound calls after this change is completed.

The other thing i want to point out is that for some reason this specific deprecation was not emailed out so the only way customers would be aware of it is if they read the depreciations page or this forum post.

It would be good if you renewed the cert with client EKU for this year and sent out the deprecation to all customers otherwise you will potentially have a lot of support cases on the 9th

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Thanks David for your response and details from Cisco.  This is the type of engagement I hoped for with this thread.  We do plan to renew our certs with the client authentication EKU in this cycle, the updated notification shoukd be published soon.  We will update when the plan is final but the renewal, with the client authentication EKU, is tentatively planned for early April. I was not aware that the deprecation announcement was communicated differently and with inquire about that as well.  

Hi - can you confirm that this is still going ahead on March 9th?

We had feedback from Cisco regarding the CUBEs they said that there is no way to prevent them doing mTLS and that the calls will fail. Cisco will release a new firmware to allow TLS to establish in the future prior to May 9th but this is not yet available (see: https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74350.html).

Have you checked how many user agents are cisco cubes currently connecting to BYOC because if these certs are replaced then all of those customers will not be able to make outbound calls after this change is completed.

The other thing i want to point out is that for some reason this specific deprecation was not emailed out so the only way customers would be aware of it is if they read the depreciations page or this forum post.

It would be good if you renewed the cert with client EKU for this year and sent out the deprecation to all customers otherwise you will potentially have a lot of support cases on the 9th

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Hi - can you confirm that this is still going ahead on March 9th?

We had feedback from Cisco regarding the CUBEs they said that there is no way to prevent them doing mTLS and that the calls will fail. Cisco will release a new firmware to allow TLS to establish in the future prior to May 9th but this is not yet available (see: https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74350.html).

Have you checked how many user agents are cisco cubes currently connecting to BYOC because if these certs are replaced then all of those customers will not be able to make outbound calls after this change is completed.

The other thing i want to point out is that for some reason this specific deprecation was not emailed out so the only way customers would be aware of it is if they read the depreciations page or this forum post.

It would be good if you renewed the cert with client EKU for this year and sent out the deprecation to all customers otherwise you will potentially have a lot of support cases on the 9th

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Hi - can you confirm that this is still going ahead on March 9th?

We had feedback from Cisco regarding the CUBEs they said that there is no way to prevent them doing mTLS and that the calls will fail. Cisco will release a new firmware to allow TLS to establish in the future prior to May 9th but this is not yet available (see: https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74350.html).

Have you checked how many user agents are cisco cubes currently connecting to BYOC because if these certs are replaced then all of those customers will not be able to make outbound calls after this change is completed.

The other thing i want to point out is that for some reason this specific deprecation was not emailed out so the only way customers would be aware of it is if they read the depreciations page or this forum post.

It would be good if you renewed the cert with client EKU for this year and sent out the deprecation to all customers otherwise you will potentially have a lot of support cases on the 9th

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.  

Genesys recently announced the removal of the Client Authentication Extended Key Usage (EKU) from BYOC Cloud SIP TLS X.509 certificates.  This discussion will be for sharing more information and allowing users to ask questions regarding this announcement. Client authentication EKU support removed from Genesys Cloud certificate

Public Certificate Authorities, such as DigiCert and Amazon Trust Services, which are used to sign BYOC Cloud SIP endpoints announced they are removing the Client Authentication EKU from issued X.509 certificates in alignment with Google Chrome's root program requirements. DigiCert Announcement

Genesys Cloud will be renewing the server certificates for the BYOC Cloud SIP endpoints the week of March 9, 2026, which will remove the Client Authentication EKU from those certificates.  Depending on the configuration of your remote SIP endpoints, this could cause disruption if not validated in advance.  

More details about BYOC Cloud TLS capabilities are listed on this page: TLS trunk transport protocol specification

Remote SIP Endpoints

In this discussion a "remote SIP endpoint" represents a device external from the Genesys platform that communicates with Genesys Cloud using BYOC Cloud with the SIP protocol.  This device is usually controlled and managed by telephony or network administrators or one of their partners, such as a carrier or service provider.  These devices are not controlled or managed within Genesys Cloud.

BYOC Cloud SIP Endpoints

In this discussion, a "BYOC Cloud SIP Endpoint" represents the public SIP endpoints for Genesys Cloud listed on this page: BYOC Cloud Public SIP IP Addresses.  These devices are controlled and managed by Genesys and there is no Genesys Cloud configuration required for this deprecation.  

GC External Trunk

In this discussion the "GC External Trunk" represents the Genesys Cloud SIP trunk configuration for the BYOC Cloud trunk.  This is the Genesys Cloud configuration where the details for the communication between the BYOC Cloud SIP Endpoints and the remote SIP endpoints is defined.  

Nothing needs to be changed in your Genesys Cloud configuration - the use of client authentication is determined by your remote SIP endpoint; most likely a Session Border Controller (SBC), SIP Trunk, or carrier configuration, or carrier device.  

Mutual TLS is initiated by the Server via a "Certificate Request" during the TLS handshake. 

Inbound Calls (Carrier or SBC to Genesys Cloud)

For inbound calls the BYOC SIP endpoints act as the Server and they never request client certificates, so there is no risk with this change for inbound.

Outbound Calls  (Genesys Cloud to Carrier or SBC)

For outbound calls, the customer remote SIP endpoints act as the Server and they may request a client certificate, based on configuration, from the BYOC SIP endpoints and those endpoints would respond with their server certificate which currently includes the Client Authentication EKU. Because of this, customer endpoints could be incorrectly configured to initiate or require mutual TLS and satisfy that requirement with the certificate Genesys provides; however, that is not a valid form of authentication and does not provide any security improvements.

If customer endpoints are configured this way, they will continue to work for now, but when Genesys renews certificates after March 9, 2026 new certificates will not include this usage and although these endpoints will continue to provide a response in the TLS handshake, the server certificate will no longer contain the client authentication EKU and those connections may be rejected by the remote SIP endpoints. Customers should ensure that they are not configured for client authentication or mutual TLS. 

How to determine the if Client Authentication is being used

The best way to review the TLS handshake is to review a packet capture of the SIP communication.  Although with TLS trunks the SIP communication will be encrypted and not visible in the capture, the TLS handshake process provides details that can be derived from the capture.  It is important to look at outbound calls specifically.

Identify if a "Certificate Request" message exists, which could be requested with other messages, such as highlighted below.  The presence of the "Certificate Request" message is an indication that the remote SIP endpoint is configured to attempt mutual TLS.  In this example, the Server provides its Server certificate with the Client Authentication EKU, and the Client validates the certificate and uses it as a valid client certificate.