Genesys Cloud CX

 View Only
Discussion Thread View
  • 1.  BYOC Cloud certificate renewal / 12/2 update

    Posted 12-03-2020 08:05
    Hi All, 

    Regarding this update, I'm unclear on how exactly a remote endpoint can be configured to trust or reference a particular certificate. In the BYOC Cloud TLS trunks I've set up to-date, I've basically just dropped the certs for each endpoint into my Certificate Authorities list. I don't believe I ever did anything to specify that a remote endpoint or BYOC cloud trunk actually use a specific cert....

    What am I missing? 


    Dean Thames
    Koch Business Solutions

  • 2.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 12-03-2020 09:59
    Hi Dean -

    BYOC Cloud does not used the "Certificate Authorities" section in the telephony administration.  That section is reserved for BYOC Premises only.  A note about that does appear on the Resource Center (  A similar note will be added to the UI page in a later release.  

    If you followed the instructions to setup your BYOC Cloud TLS trunk on the Resource Center ( you should not experience any issues; regardless, it is still beneficial to review your BYOC Cloud TLS configuration prior to this change to ensure you will not experience any interruption.  

    In your case, I believe the "remote" endpoint you reference is your own device that connects to BYOC Cloud, likely an SBC, but it could also be another SIP platform or cloud provider.  Whichever device connects to BYOC Cloud and performs the TLS handshake is the device we are concerned with.  Currently, when that device connects to BYOC Cloud (**more on this below**) and it is acting as the client the BYOC Cloud SIP endpoint (the server) will send its X.509 certificate in a "Certificate" TLS message following the Server Hello TLS message.  At this point your endpoint should be configured to "trust" this certificate.  It is important with the change being made that the trust was established by your endpoint trusting the DigiCert Root CA file (named "DigiCert High Assurance EV Root CA").  This is important because the root issuer will not change.  However, if you trusted the server certificate itself (which is a Genesys issued cert named "voice.<region>.<mypurecloud/pure>.<com/>, i.e. that would allow the TLS handshake to proceed for the moment, but it is expected to break after this change.

    Outbound calls would still proceed as they largely use the certificate on your device for the handshake, and although those are required to be updated over time, it is not likely going to change exactly when we change our certs.  

    Going back to the  **more on this below** and why i said a certain cert is "largely" used based on the direction of the call...  When a call is initiated one side acts as the client and one side acts as the server, and when the call is initiated that is determined by the direction of the call.   Your endpoint is the client when you want to send a call to Genesys Cloud and Genesys Cloud is the client when it wants to send an outbound call to your endpoint.  The servers certificate is used is all cases, so the client must trust the server for a call to proceed.  However, once the call is established, the roles can shift for later transactions with that call dialog.  Once a call is established, if the receiving party hangs up the call first - then the endpoint that was the server during call initiation will be the client for the BYE transaction.  In the case where there are TLS issues or certificate issues, you could see odd behaviors where a call sets up successfully, but then experiences issues when the call is disconnected.  Another thing that further complicates this is socket timeouts; and this is usually want contributes to issues showing inconsistent results.  Once the two endpoints successfully setup a call the socket that was used will remain mostly for around 2 minutes - but each endpoint has a timer where they will decide to close an idle socket.  If the receiving party sends a BYE, like we just discussed, but while the socket is still open - a new connection will not be established because there is an active socket that can be reused.  

    Session Timers introduce a very similar scenario but they are sometimes unknown to the user.  If a call has session timers and is experiencing TLS handshake issues you can experience calls ending unexpectedly.  Additionally session timers can be configured to be sent on interval by either the UAS or the UAC, it is determined during the call setup.

    This just leads into unique conditions to test when setting up or diagnosing a TLS based SIP trunk, each of these conditions may have unique results:
    • Call initiated by remote endpoint
    • Call initiated by BYOC Cloud
    • Call terminated by remote endpoint (after 5 minutes)
    • Call terminated by BYOC Cloud (after 5 minutes)
    • Call with UAS session timers (ensure call lasts past session timer interval)
    • Call with UAC session timers (ensure call lasts past session timer interval)

    Phil Whitener
    Genesys - Employees

  • 3.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 07-21-2021 19:18
    Hello Phil, 

    I hope you are well,

    I would like to know if you can guide me or help me with a problem I have in a Byoc Cloud integration. I have an SBC provider in which we have worked to perform a voice channel integration with TLS. Incoming calls to Genesys Cloud work correctly, but outgoing calls fail, we do not understand what may be happening or what is the problem.

    At the certificate level, the SBC has a GoDaddy certificate loaded, but outgoing calls do not work anyway. It is worth mentioning that in the UDP or TCP protocol, outgoing and incoming calls work correctly. Therefore, we believe that the problem could be the certificate.

    Do you have any suggestions that allow me to solve this problem, please?

    Luiggi Vilca
    Protiviti Member Firm Peru SAC

  • 4.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 04-22-2022 14:41
    Hi Luiggi

    Wanted to ask you if you can to solve this issue with TLS and outbound calls?

    I have the same issue currently and it's been more than a week and we have not been able to solve the issue.


    David A.

    David Alvarez

  • 5.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 05-11-2022 10:58

    Hi David,

    Sorry for the delay,

    With the SBC team it was possible to solve the incident. Could you solve the problem?


    Luiggi Vilca
    Protiviti Member Firm Peru SAC

  • 6.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 05-11-2022 14:40
    If you could provide more details of your issue we can help look at it.  Based on what you describe (GC->SBC outbound works, SBC->GC inbound does not work) often is related to the "issuer" certificate.  Ensure your SBC has both your end-entity cert installed as well as all intermediate certs - this should force the SBC to include the intermediate certificate in the "Server Hello/Certificate" message so that the BYOC SIP endpoint can validate the chain.  You can observe the TLS handshake with a network capture tool such as Wireshark to see why the handshake is failing.

    Phil Whitener
    Genesys - Employees

  • 7.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 04-20-2023 22:04

    Hi Phil, similar issues on my side. Calls from SBC > GC inbound works fine. Outbound GC > SBC fail. Using GoDaddy certs, but from what I understand we are missing the DigiCert High Assurance EV Root CA for a successful handshake. Does Genesys provide the root CA's for DigiCert ?

    477 Connection Failed/Rejected error when placing outbound calls (GC > SBC)

    Thank you

    Henry Morales
    Tetra Tech, Inc.

  • 8.  RE: BYOC Cloud certificate renewal / 12/2 update

    Posted 04-21-2023 09:21

    Henry - when a call initiates in the outbound direction (GC > SBC) the Genesys certificate signed by DigiCert is not used at all, only your GoDaddy cert is used.  The most common issue I see with this error, is actually not an issue with the certs, but an 'incomplete chain'.  If you have a packet capture we can check to confirm.  When BYOC Cloud connects to your SBC it will start with a TLS 'Client Hello', the SBC will respond with it's server certificate - which you stated was from GoDaddy.  When the SBC responds and provides it's server certificate it must also provide ALL intermediate certificates in that chain, but it does not need to provide the root.  The BYOC Cloud SIP servers already have the trusted roots, but are not aware of the intermediates, so the SBC must provide them during the handshake.  If that happens then our SIP Servers can walk that chain and confirm that your certificate is trusted.

    To get the SBC to send the full chain you typically need to install your Intermediate Certificates in the TLS Profile/Context for the public interface as "Trusted CA Certificates" - this likely where you also installed the DigiCert High Assurances EV Root Certificate used by the SBC to trust the BYOC Cloud SIP Servers.  In most cases that is what is missing - some SBCs, like Oracle/Acme, want you to include the intermediate in the PEM when you upload the signed server certificate.

    Phil Whitener
    Genesys - Employees

Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources