Outbound call to provider works, inbound without audio
This usually is related to a missing Root CA (of the provider) in the Trusted CA chain of the SBC Edge. An outbound call would work fine, as the provider accepts the self-signed (or public) cert of the SBC.
But for the inbound call, the SBC has to verify the incoming TLS. This fails, as the Root CA of the provider is missing. So the TLS handshake fails.
This is the failure from a log:
[2020-01-03 13:51:47,637] 8041 0013 com.sonus.sbc.sip.libctl DEBUG (TransportTlsSocket.cpp:1630) - TLS Server OPERATING Version: SSLv23 for conn_id: 923
[...] (TransportTlsSocket.cpp:2852) - SSL_accept after: socket fd=637 for conn_id: 923 in state: error, negotiated version: (NONE) and cipher: (NONE)
[2020-01-03 13:51:47,637] 8046 000e com.sonus.sbc.sip.libctl WARN (TransportTlsSocket.cpp:3542) - TLS Peek Code: 0, Error Code: 336109761, Reason: 193(Unknown) for conn_id: 923
[2020-01-03 13:51:47,637] 8047 000d com.sonus.sbc.sip.libctl WARN (TransportTlsSocket.cpp:3597) - TLS Handshake Failed alert msg send 40 was notified for conn_id: 923
[2020-01-03 13:51:47,637] 8048 000c com.sonus.sbc.sip.libctl ERROR (TransportTlsSocket.cpp:2878) - TLS Accept failed with error: -1, retry: 0 for conn_id: 923
[2020-01-03 13:51:47,637] 8049 000b com.sonus.sbc.sip.libctl ERROR (TransportTlsSocket.cpp:2817) - TLS Server handshake negotiation failed for conn_id: 923 on handle: 0x2692a80
I saw some past cases where alert 40 indicates that either parameters (version, ciphers) are unacceptable or no certificate from peer cannot be validated on the SBC Edge.
Upgrade version X to Y, TLS Signalling Groups are not up
- Reboot in old partition (Version X) and export the Ribbon SBC device certificate.
- Reboot in new version Y.
- Once you try to import the SBC device cert, it will say that CA certs are not correct.
- Just re-import all necessary CA certificates and re-import the Ribbon SBC certificate then. (the one which was exported in step 1)
The CA certificates got certainly corrupted when switching to the later version.
Failed to append the (Server Certificate) private key to the Server certificate in store
The error message „Failed to append the (Server Certificate) private key to the Server certificate in store“ often refers to the issue of Certificate and Private Key not matching.
I had several past cases where the device certificate did not include the private key when customers tried to import them into the SBCs.
So what happens when a customer exports the certificate for example as x.509? -> The Private key isn’t exported.
And is then missing when one imports the certificate into a new SBC.
PKCS12 is a file format which contains both private key and X.509 certificate ;_)
This also applies if customers have to replace SBCs because of an RMA or so. The Ribbon built-in export wont export the Private Key if you use the X.509 format.
SBC ↔ SBA / Skype: SIP-TLS Handshake Inactivity Timeout Failure
If things like the following are happening and the Skype Signalling Group goes down for 4-5 seconds…
Experiences so far:
As part of some customer security audits, the ASM/SBA part of the Ribbon SBCs might be blocked from the internet as there might be some issues related to SSL 2.0/3.0 being enabled.
It appears that the SBA’s do a CRL (certification revoke list) check to ensure the certificate(s) used in communication have not been revoked. As in such case, this is not available due to missing internet connection – the SBA shortly drops connection.
After allowing SSL2.0/3.0 for the ASM/SBA policy-wise, all the errors/warnings have stopped on the SBCs and errors in the event log on the ASM/SBA have also stopped.
TLS handshake failure bad certificate
Alarm message:
TLS client handshake failed with alert code. Action: Refer to Error Alerts in RFC 5246 for the problem. (bad certificate)
Short one: Bad certificate -> Just check the time stamp / the time on SBC
