Skip to end of metadata
Go to start of metadata

In this section:


The SBC 5000 series supports Transport Layer Security (TLS) enabling SIP and HTTP applications to securely communicate on an insecure network, and to reliably verify the identity of a user via digital signatures. SIP/TLS applications may act as a TLS server or client for their respective TLS sessions. HTTP/TLS applications as a web server (for the EMA) always act as a TLS server for a TLS session. As a TLS session is being negotiated, the TLS server presents its digital certificate to its client for authentication and for encryption of client-generated shared secret. Sometimes, a TLS server may also request the client to send its certificate for mutual authentication as in the case of the SIP peering and the management access to the EMA that requires Common Access Card (CAC) based public key (PK) authentication. In any case, a TLS connection’s security is not established until every individual certificate on the chain presented by the peer device is successfully authenticated and Online Certificate Status Protocol (OCSP) validated.

The status of the certificates corresponding to established ongoing TLS sessions, however, may change over the lifetime of the TLS session, especially when the sessions are long-lived. The SBC periodically checks all certificates and trust chains associated with ongoing sessions, and then terminates any ongoing sessions if the corresponding certificates are revoked, no longer trusted, or expired.

Remote certificates are installed in the SBC for presentation along with local certificates, installed as trust anchors for the verification of credentials presented by peer devices, and installed as the OCSP responder certificates for the verification of signed OCSP responses. These installed remote certificates are not automatically renewed and thus can expire. The SBC gives the user an alert before any installed certificates are near expiration so the user can take action upon it.

Certificate Re-Check

Upon failure of any one of the checks, the SBC terminates the TLS session and logs a MAJOR level event (sonusSbxFailedCertificateReCheck) to alert the user. The one exception will be if OSCP is enabled but SBC does not receive revocation status of successful.good or successful.revoked, the corresponding TLS session continues for SIP/TLS.

Certificate Expiry Warning

SBC logs an event into the security event log at a high severity level when a local or remote certification installed on SBC is within 60 days of its expiration date. The event repeats based on the configuration available in the expiration periodic warning until the certification is replaced or deleted (even after it has expired).

Disabled certificates are not included in the certificate expiry warning check.

To View and Edit Cert Expiry Check

On SBC main screen, go to Configuration > System Provisioning > Security Configuration > Cert Expiry Check. The Cert Expiry Check window is displayed.

Figure : Security Configuration - Cert Expiry Check


The following fields are displayed:

Table : Cert Expiry Check Parameters



Cert Re Check Rate 

Specifies the interval, in hours, for SBC to re-check certificates. Select 'disable' to turn off this feature.  The default value is 24. The options are:

  • disable
  • 8-720 hours, in increments of 1 hour

Expiry Warning Threshold

Specifies the number of days prior to a certificate expiration date on which to generate an expiry warning message. Select 'disable' to turn off this feature. The default value is 60. The options are:

  • disable
  • 30-90 hours, in increments of 1 day

Expiration Periodic Warning 

Specifies the frequency, in days, for sending periodic warning reminders once the Expiry Warning Threshold has been met. Select 'disable' to turn off this feature. The default value is 7. The options are:

  • disable
  • 3-14 days, in increments of 1 day

Make the required changes and click Save at the right hand bottom of the panel to save the changes made.


  • No labels