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 (https://help.mypurecloud.com/articles/certificate-authorities/). 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 (https://help.mypurecloud.com/articles/tls-trunk-transport-protocol-specification/) 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/tld.cloud>, i.e. voice.us-east-1.mypurecloud.com) 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
------------------------------
Original Message:
Sent: 12-03-2020 08:04
From: Dean Thames
Subject: BYOC Cloud certificate renewal / 12/2 update
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?
Thks.
Dean.
#PlatformAdministration
#SIP/VolP
------------------------------
Dean Thames
Koch Business Solutions
------------------------------