Toggled the SRTP compliance setting on the Virginia BYOC trunks to clear the quarterly compliance check. Registration immediately started bombing out with a SIP 401 Unauthorized. Carrier SBC pushed a new intermediate CA last week, so the TLS handshake’s choking on the chain validation. Audit logs are totally empty for those endpoints, and the backup trunk isn’t catching the overflow. Console just spits TLS_ERROR: CERT_CHAIN_INCOMPLETE on the outbound leg.
Cause: You’re blaming the CA chain, but SIP 401 is an auth failure, not a TLS handshake error. The CERT_CHAIN_INCOMPLETE is likely a red herring from the carrier SBC failing to establish the secure tunnel, which then causes the auth challenge to fail because the identity assertion never completes. The real issue is usually that the SRTP toggle forces a renegotiation, and your BYOC trunk config is still pointing to the old credential set or the outbound xy settings are misaligned with the new TLS requirement.
Solution: Check your trunk credentials in the console. Specifically, verify the “Outbound xy” and “Authentication” tabs. If you switched to SRTP, ensure the “Transport” is set to TLS and the “Credential” matches the one expected by the carrier.
Run this to pull the current trunk config and inspect the outboundProxy and credential fields:
curl -X GET "https://api.mypurecloud.com/api/v2/telephony/viders/edges/trunks/{trunkId}" \
-H "Authorization: Bearer {access_token}" \
-H "Content-Type: application/json"
If the credentialId looks correct, try forcing a re-registration by toggling the “Enabled” flag off and on via the API, or just restart the edge service if you have access. Also, check the carrier’s side for the new intermediate CA. You might need to add it to your local trust store if the Genesys edge isn’t picking it up automatically. The TLS_ERROR suggests the handshake is dropping before auth, so fix the cert chain first, then the 401 will likely disappear. Don’t ignore the audit logs; they might be delayed. Check the raw SIP traces if you can get them from the carrier.
Spot on. The TLS error is definitely masking the real auth failure. When you flip that SRTP toggle, Genesys forces a re-registration, and if the trunk credentials aren’t explicitly refreshed in the state, it tries to auth with stale tokens.
Since I manage this via Terraform, I always force a recreate of the trunk resource when security settings change. It’s annoying, but it guarantees the credentials are pushed fresh. Here’s how I handle it in my modules:
resource "genesyscloud_trunk" "va_byoc" {
name = "VA-BYOC-Primary"
region = "VA"
sip_trunk {
# ... config ...
enable_srtp = true
}
# Force recreation on security changes
lifecycle {
force_destroy = false
}
}
I also add a depends_on to the OAuth client rotation module just to be safe. You might want to check if your state file has drifted on the sip_trunk block. Run a terraform plan and see if it wants to update anything. It usually does.