Certificate Automation

You can configure the SBC to perform key X.509 certificate related tasks automatically, including certificate renewals. These functions, based on the Certificate Management Protocol (CMP) defined within RFC 4210 and RFC 4211, make the SBC a CMP client, which interacts with a CMP server managed by a Certificate Authority (CA).

To enable certificate automation, you must enable the Certificate Management Protocol (CMP) entitlement.

Using the SBC as a CMP client simplifies certificate management even as the number of certificates the SBC operates with increases. Without CMP, manually managing large numbers of certificates is time consuming and error-prone.

The SBC supports manual mechanisms for creating and managing its own end-entity certificate that require administrator intervention. You can use the SBC as a CMP client to perform the following tasks automatically:

Support SBC registration and certification with the CMP server for up to 300 certificates
Monitor SBC and CMP certificates for expiration
Generate certificate requests with CMP servers to replace about-to-expire certificates. The system can do this based on certificate-record parameters and CMP policy
Retrieve signed certificates from external root CAs
Import new end-entity certificates into the SBC
Re-configure applicable certificate-record elements, replacing expired certificates with new ones
Delete expired certificates and applicable certificate-record elements

Note:

This functionality applies to end entity certificates. It does not apply to root CA certificates.

The CMP deployment on the SBC does not:

Send certificate revocation messages to a CMP server
Listen for CA key update announcements
Listen for CA revocation messages
Listen for CA processing messages
Update imported CA certificates

The SBC needs different certificates for different applications and interfaces. This CMP feature performs its certificate-related tasks to support the following applications:

A sip-interface that needs a certificate for authentication during the establishment of TLS connections with SIP endpoints.
An ike-interface that needs a certificate for IKE authentication when establishing an IPsec tunnel with IKE endpoints.
Certificates used to establish a secure ACP over a TLS connection towards an SDM system.
Certificates used to establish a secure HTTPS connection towards STIR-based application servers.
Certificates used on a management interface when a secure HTTPS connection is established by the Web GUI or a REST API towards the SBC.

To request a certificate, the SBC uses Certificate Request Message objects in Certificate Request Message Format (CRMF). The SBC inserts these messages, adhering to the applicable transport protocol, to convey the request to a Certification Authority (CA). These flows may also include a Registration Authority (RA). These requests typically include a public key and the associated registration information.

CMP Architecture

When configured, the SBC interacts with CMP servers to manage large numbers of certificates without manual intervention. In addition to SBC element configuration, you must perform some initial offline tasks, which offer insight into the protocol's architecture.

CMP uses a client/server structure wherein the SBC is the client, which talks to one or more CMP servers. These devices use HTTPS over TLS to request and respond to the client's needs for managing security certificates. One or more root CAs maintain an archive of validated certificates, with which the client can validate SIP end entities and establish secure paths.

In this architecture, the SBC acts as a certificate repository, maintaining security between itself and endstations as it provides SIP service. The CA uses CMP servers, with which the SBC interoperates, to host CMP protocol operations on its behalf. The overall architecture automatically provides for a steady stream of valid certificates that have not been compromised, supporting real-time SIP sessions over TLS.

To secure the connections between the client and server, however, you establish secure paths between them. You establish the authentication and validation needed to secure these paths by establishing key-pairs and exchanging certificates manually. After CMP starts operation, the SBC and the CMP server can manage those certificates automatically, in addition to the certificates the SBC uses for SIP service.

Before configuring CMP elements, you perform the following tasks:

Enable the Certificate Management Protocol (CMP) entitlement. You must save and activate the configuration and reboot the SBC.
Configure the certificate-record for the root CAs.
Configure the certificate-record for the CMP servers.
Import the certificate of the root CA.
Import the certificate of the issuer CMP server. Specifically, the certificate of the CMP server that issues the end entity certificate.
Configure the tls-profile elements that include the applicable trusted-ca-certificates for interacting with the CMP server.
Specify and share the Initial Authentication Key (IAK) and reference value.
Consider the deployment's certificate authority hierarchy and configure the applicable servers as follows to ensure discrete communications paths when you have separate certifying CA and CMP servers:
- Configure the root CA, which issues the end-entity certificate (Certifying CA), under server-certificate in the applicable cmp-server.
- Configure the CA that issues the CMP server's connection certificate in the trusted-ca-certificates parameter of the tls-profile.
For mutual authentication, the end-entity-certificate of the SBC must be signed by the CA, using the hostname or IP address of the sip-interface facing the CMP server.
You base the SBC end-entity-certificate on a sip-interface so that the SBC can maintain different CA relationships for various media and management interfaces. You can configure the SBC with multiple end-entity-certificate elements, representing different interfaces or realms.

After completing the above, the SBC is ready for CMP element configuration, described below, which sets up connections to the CMP server. Typically, you configure the SBC with access to multiple CAs, which may or may not use the same tls-profile.

CMP Client Operation

When the SBC and CMP servers have established a trusted client-server relationship and you have configured and activated at least one certificate to be managed by CMP, the SBC starts a CMP processing timer that examines the status of all applicable certificates and begins to manage them. The timer starts this function every 5 minutes.

The SBC also starts to monitor CMP-managed certificates and performs interactions with CMP servers. During service operation, the SBC supports the following types of CMP requests:

Initialization Request/Response (IR/IP)
End-entity Certificate Renewal - Key Update Request (KUR)
Polling Requests

IR/IP Operation

For IR/IP, the SBC initiates certificate enrollment against the configured CMP server, and includes the certificate signing request. After enrolling the certificate, the CMP server signs it and returns it in the response. The process assumes that you have configured the SBC with a secret IAK value and a reference value that is shared with the CMP server. This IAK is used to protect the CMP messages sent by the SBC and authenticates the SBC with the CMP server.

The SBC also initiates an IR message towards CMP server when:

A certificate-record transitions from manual to CMP.
You change the cmp-profile name in the certificate-record.
You change the subject DN related parameters in the certificate-record, including the country, state, locality, organization, unit, common-name and email-address.

KUR Operation

The SBC issues a KUR for changes to certificate-record configurations that are not subject related or a key-pair expiry. Key-pair expiry conditions may or may not include a new certificate.

The SBC initiates a configuration change KUR message towards CMP server when all of the below are true:

Applicable certificate-record configuration changes occur, including key-size, alternate-name, key-usage-list, extended-key-usage-list, key-algor, digest-algor and ecdsa-key-size.
The system determines that the certificate-record is managed by CMP.
The system has already successfully obtained the applicable certificate using CMP.

The SBC does not initiate a configuration change KUR message towards CMP server if the certificate has a CMP transaction in progress.

The SBC initiates new KUR messages and saves new certificates resulting from KUR messages only during the window of time defined by the kur-start-time-of-day and kur-end-time-of-day parameters on the cmp-global-config element. Any KUR messages generated outside of this window are added to a batch, which the SBC processes during the next window. Using the KUR window allows you to maintain system performance during busy times by restricting certificate renewals to low traffic times.

After performing the KUR, the SBC waits until it obtains a renewed certificate from the CMP server. After it is successfully obtained, the SBC updates its configuration with the new certificate and deletes the expired certificate. If the key update attempt fails before certificate expiry, the SBC retries multiple times until it gets a successful KUR response from the time renew-before-expiry starts until certificate expiry. If all the KUR attempts fail, which is unlikely, and the certificate expires, then the SBC deletes the certificate-record and the configuration of that certificate under tls-profile.

Note:

The SBC does not automatically delete a certificate-record that is not managed by CMP.

If the validity period of the certificate from the CMP server is less than the renew-before-expiry days, the SBC rejects the certificate with a PKI failure, then retries the request in 1 hour and 5 minute intervals (the retry timer plus the CMP processing timer). If you want to retry the request sooner, you can delete the existing certificate-record and recreate it.

When the SBC starts processing for a KUR message within the KUR window, processing continues until the transaction completes, even if this exceeds the KUR window. For example, if a message is sent during the KUR window, but the SBC must make multiple retry attempts, the SBC continues to retry beyond the KUR window, until the transaction concludes with a success or failure. If the success comes with a new certificate outside of the KUR window, the transaction to save that certificate is added to the batch for the next KUR window.

You can also manually force a KUR update by running the cmp-keyupdate-request <cert-record-name> command. The SBC sends the message immediately, even if the current time is outside of the configured KUR window, but any resulting certificate updates are not saved until the next configured KUR window or next manual save and activate.

Polling Request Operation

To determine the status of outstanding requests when the CMP server returns a PKI status of waiting, the SBC issues polling requests.

The timing and number of polling requests is controlled by:

The checkAfter value on the CMP server response determines how long to wait between polling messages.
The polling-retry-count parameter on the cmp-server specifies the maximum number of times to send a polling message.
After the retry count has been reached, the CMP processing timer, which elapses every five minutes, determines when to restart the retry count and start polling again.

The flow is as follows:

The initial response from the CMP server has a PKI status of waiting.
The SBC sends a polling request.
If no certificate is ready, the CMP server returns a PKI status of waiting with a checkAfter value.
The SBC waits for the checkAfter period, then sends a polling request.

The final two steps repeat until one of the following happens:

The CMP server completes the process (with a failure or a success). Polling stops and processing the success or failure continues as normal.
The cmp-msg-timeout or total-timeout is reached. Polling stops and the entire transaction times out.
The number of polling requests specified in polling-retry-count is reached. Polling stops but the transaction remains outstanding. The next time the CMP processing timer elapses (every five minutes), the retry count is reset and polling resumes.

When there are multiple CMP servers, if a connection or a polling transaction fails with a given server, the SBC attempts to reach each server in the cmp-server-group, using a round-robin approach, in the sequence configured the list. If the polling attempt fails for all servers in the group, the SBC restarts the poll from the beginning of the list.

Operation on Receiving Certificates

In all certificate request scenarios, the CMP server returns a PKI status for each certificate requested. These include an encrypted certificate in a successful case. The SBC proves possession of private key (POP) by decrypting the certificate and verifying whether or not the received certificate is acceptable.

If the received certificate is acceptable to the SBC, it calculates the hash of its own certificate and populates the CertHash field, then provides successful confirmation of the receipt of certificate by providing the correct CertHash for the certificate. The CMP server verifies the CertHash, authenticates the confirmation and sends back an acknowledgment using a PKI Confirm message.

If the SBC does not accept the certificate issued by CA for any reason, it responds with a PKI status of rejected and does not attempt to re-acquire the certificate from any other CMP servers.

Because TLS client authentication is optional, the SBC is not required to have its own certificate for HTTPS connection.

The SBC operates with new certificates until they expire. To inform you of certificate expiry status, the SBC uses the same certification expiration notifications that it uses for manually managed certificates. The applicable parameters, configured within the security-config, include:

local-cert-exp-warn-period
local-cert-exp-trap-int

For more information about these traps and their associated alarms, see the Certificate Automation Reporting section below and the MIB Guide. MIBOIDs used to monitor CMP operation are also documented in the MIB Guide.

During operation, the SBC can report on extensive certificate detail in the output using CLI commands. Examples include whether or not the certificate is updated, whether or not a certificate is present, and what triggered certificate renewal. See detail on ACLI commands that report on CMP in the Certificate Automation Reporting section and the Viewing CMP Certificate Statistics and Errors section of the Maintenance and Troubleshooting Guide.

You can also determine what triggered certificate renewal using the display-alarms command.

Operation for Failed Updates

If you update a certificate-record object and the corresponding CMP server transaction fails (for example, if the server is down or the request is rejected), Oracle recommends resolving the reason for the failure (bringing the server back up or addressing the rejection reason) and waiting until the first transaction succeeds before making other modifications.

Because the SBC always considers the most recent action on a configuration element, performing more actions before the first action succeeds can result in conflicting or incorrectly applied data. The SBC cannot track multiple stacked modifications in failure scenarios.

For example, suppose you update a subject DN related certificate-record parameter that triggers an IR action, such as state. If the a CMP server goes down, the IR cannot complete, and the SBC retries the IR every five minutes.

During the outage, before the IR completes, you do one of the following:

Scenario 1: You update a parameter on a different configuration element that impacts the certificate, such as updating renew-before-expiry for the cmp-profile associated with the certificate-record.
If the original certificate now falls within the renewal period, the SBC initiates a KUR to renew it.

When the CMP server comes back online, the IR to update the certificate goes through, and a new validity period is established. The KUR, which applied to the original certificate, should no longer be needed, since the updated certificate has a new validity period.
Scenario 2: You update a non-subject DN related parameter on the same certificate-record, such as key-size. The SBC initiates a new KUR.
When the CMP server comes back online, the new KUR supplants the IR.

Note:

During the retry period for failed transactions, if you reboot the SBC, the retry cycle is stopped. Any failed CMP transactions are not retried after rebooting. You must repeat the modification to the certificate-related parameter, then save and activate your changes to retry the transaction. This also applies in HA scenarios, where the standby or active node is rebooted and the switchover happens during the retry cycle.

High Availability for CMP

The SBC supports CMP in high availability (HA) environments. The system replicates CMP configurations and managed certificates from the active node to the standby node. However, the state of CMP transactions (IR and KUR messages) and statistics for CMP managed certificates are not replicated.

When the standby node becomes active, it automatically takes over CMP operations, including reviewing the certificate record table and initiating requests.

If the switchover happens during a pending IR or KUR transaction, the new active node will initiate a new transaction for the same certificate. For polling requests, if the switchover happens while waiting for the checkAfter period, the new standby node (previously active node) resets the certificate status to the default of Unknown.

CMP Entitlement Considerations

You must enable the Certificate Management Protocol (CMP) entitlement before you can use the CMP client functionality.

If you disable the entitlement after operating with it enabled, the following notes apply:

The SBC will no longer perform CMP actions (IR and KUR messages).
Any certificates previously managed by CMP remain, but you must now manage them manually.
CMP-related configurations and commands will no longer be available in the ACLI. The cmp elements under security is still visible, but no subelements will appear.
The system will still generate configured alarms for certificates that are expired or are expiring soon, but the system will not automatically delete expired certificates.
The certd process will operate as a single thread.
CMP-related metadata and configurations will remain in the dataDoc and backConfig files, but will not be visible in the ACLI.
The show security certificates detail <certificate_name> command will still show certificate acquisition and management information, but Certificate Management will be set to Manual for all certificates, even those previously managed by the CMP client.
CMP-related OIDs will not be available.
CMP-related widgets will still appear in the GUI, but will not produce any output. Do not use them.

Changing entitlement settings requires a system reboot. If you enable the entitlement and do not reboot, the CMP process will not start. If you disable the entitlement after operating with it enabled, the process and memory timers for CMP will not be freed, and no new CMP transactions will take place. For any certificates that were retrieved but not yet committed to the database when the entitlement was enabled, you must commit them manually.

Secure Certificate Mode

For additional security, you can enable secure-certificate-mode on the system-config element. When this is enabled, the system enforces the following configuration requirements:

For media interfaces, cmp-server-address cannot be set to an IP address (IPv4 or IPv6), only a hostname. Management interfaces can use a hostname or an IPv4 address (not IPv6).
Any certificate-record that uses an IP address in the common-name or alternate-name is considered invalid. The system rejects certificates with IP addresses in the CN or SAN.

You must reboot the system after enabling this parameter.

CMP Configuration

The cmp configuration branch resides within the security branch. This branch contains many of the key objects you use to configure this feature. With the exception of the cmp-global-config, CMP configuration consists of nesting related elements using parameters that refer the system to the applicable elements. The CMP configurations are only available when the Certificate Management Protocol (CMP) entitlement is enabled.

You configure the following objects to set up CMP:

cmp-global-config: This single-instance element contains parameters defining global CMP behavior for all servers and profiles.
tls-profile: These profiles establish generic configurations to support communication with any target object using TLS, including CMP servers.
When you have enabled mutual-authentication in the applicable tls-profile, you also configure end-entity-certificate. If mutual-authentication is disabled (default), then only one or more trusted-ca-certificate is required.
cmp-server: This multi-instance configuration object holds CMP-server related details and CMP protocol-specific parameters that the SBC uses to operate with a CMP server. Each cmp-server must reference a tls-profile.
The CMP protocol is transport agnostic and is typically carried over a secure transport protocol. The SBC uses HTTPS. When you specify a tls-profile within a cmp-server, the SBC acts as an HTTPS/TLS client with that CMP server over a specific realm.

The cmp-server element supports the following options:
cmp-server-group: This multi-instance element contains one or more cmp-server names. These groups establish server redundancy.
cmp-profile: This multi-instance element specifies CMP-related parameters applicable to operation with one or more certificates. Each cmp-profile references a cmp-server-group element, thereby specifying the configured redundancy and transport functions used by individual certificate-record elements.
certificate-record: These elements include a reference to a single cmp-profile parameter, making them the final objects in your CMP configuration propagation. Any gap in this propagation, such as a cmp-server-group that does not reference any cmp-server objects prevents the SBC from using CMP to manage a certificate-record.
A certificate-record represents either an end-entity certificate or a CA certificate. The system uses certificate-record objects to specify the required certificate parameters and to provide a target location for a renewed certificate.

Note:
When secure-certificate-mode is enabled, for end-entity CMP-managed certificates, do not use IP addresses in the common-name or alternate-name parameters.

The SBC can manage up to 300 certificates. When registering large numbers of certificates, you can register up to 120 certificates in a single batch. Wait for each batch to complete before submitting another batch. Because large CMP configurations can have a heavy impact on system performance, Oracle recommends registering batches during a maintenance window.

The verify-config command includes notifications for the following CMP configuration issues:

An applicable tls-profile is empty. In this case, the system tells you that CMP does not work without secure a TLS connection.
A realm name used in a cmp-profile is not a valid realm.
A cmp-client-address does not fall within the configured realm-id or the network-interface associated with that realm.
A cmp-server-address is configured as a hostname and the network-interface corresponding to the cmp-server-address is not configured with DNS IP address information. This error informs you that the cmp-server hostname cannot be resolved without a DNS server IP.
If the auth-method is shared-secret and if secret-value is empty, the system tells you that a secret value needs to be configured.
The cmp-msg-timeout is not less than or equal to the total-timeout.
The existing verify-config implementation for tls-profile and http-client is used for CMP.
If there are more than 10 servers configured in a cmp-server-group list, the done command throws an error and prevents you from saving this object.
If a cmp-server-group is empty or contains a name that is not configured in a cmp-server, verify-config throws an error message.
If renew-before-expiry is enabled and a cmp-server-group is empty, the system throws an error saying that the certificate renewal will not work until you configure the cmp-server.
If the server-certificate is empty, the system throws an error saying that it must be set to authenticate the CMP response message from the CMP server.