TLS Profile Configuration

Use the following procedure to configure a tls-profile that identifies the cryptographic resources, specifically certificates and protocols, required for the establishment of a secure/encrypted connection between the Oracle® Enterprise Session Border Controller and the Oracle Communications Operations Monitor (OCOM) Mediation Engine.

  1. From superuser mode, use the following command sequence to access tls-profile configuration mode.
    ACMEPACKET# configure terminal
    ACMEPACKET(configure)# security
    ACMEPACKET(security)# tls-profile
    ACMEPACKET(tls-profile)#
  2. Use the name parameter to provide a unique identifier for this tls-profile.
    ACMEPACKET(tls-profile)# name commMonitor
    ACMEPACKET(tls-profile)#
  3. Use the required end-entity-certificate parameter to specify the name of the certificate-record configuration that identifies the credential (specifically, an X509.v3 certificate) offered by the Oracle® Enterprise Session Border Controller in support of its asserted identity.
    ACMEPACKET(tls-profile)# end-entity-certificate commMonitor509
    ACMEPACKET(tls-profile)#
  4. Use the required trusted-ca-certificates parameter to compile a list or one or more certificate-record configuration elements referencing trusted Certification Authority (CA) certificates used to authenticate the offered certificate. These referenced certificates are conveyed to the OCOM Monitor Mediation Engine as part of the TLS exchange.

    Provide a comma separated list of existing CA certificate-record configuration elements.

    ACMEPACKET(tls-profile)# trusted-ca-certificates verisignClass3-a,verisignClass3-b,baltimore,thawtePremium,acme-CA
    ACMEPACKET(tls-profile)#
  5. Retain the default value, all, for the cipher-list parameter.
  6. Use the verify-depth parameter to specify the maximum number of chained certificates that will be processed while authenticating end-entity certificate received from the OCOM Mediation Engine.

    Provide an integer within the range 1 through 10 (the default).

    The Oracle® Enterprise Session Border Controller supports the processing of certificate chains (consisting of an end-entity certificate and some number of CA certificates) when X.509v3 certificate-based authentication is used. The following process validates a received TLS certificate chain.

    • Check the validity dates (Not Before and Not After fields) of the end certificate. If either date is invalid, authentication fails; otherwise, continue chain validation
    • Check the maximum length of the certificate chain (specified by verify-depth). If the current chain exceeds this value, authentication fails; otherwise, continue chain validation.
    • Verify that the Issuer field of the current certificate is identical to the Subject field of the next certificate in the chain. If values are not identical, authentication fails; otherwise, continue chain validation.
    • Check the validity dates (Not Before and Not After fields) of the next certificate. If either date is invalid, authentication fails; otherwise, continue chain validation.
    • Check the X509v3 Extensions field to verify that the current certificate identifies a CA. If not so, authentication fails; otherwise, continue chain validation.
    • Extract the Public Key from the current CA certificate. Use it to decode the Signature field of the prior certificate in the chain. The decoded Signature field yields an MD5 hash value for the contents of that certificate (minus the Signature field).
    • Compute the same MD5 hash. If the results are not identical, authentication fails; otherwise, continue chain validation.
    • If the hashes are identical, determine if the CA identified by the current certificate is a trust anchor by referring to the trusted-ca-certificates attribute of the associated TLS-profile configuration object. If the CA is trusted, authentication succeeds. If not, return to Step 2.
    ACMEPACKET(tls-profile)# verify-depth 8
    ACMEPACKET(tls-profile)#
  7. Use the mutual-authenticate parameter to enable or disable (the default) mutual authentication.

    Protocol requirements mandate that the server present its certificate to the client application. Optionally, the server can implement mutual authentication by requesting a certificate from the client application, and authenticating the certificate offered by the client.

    Upon receiving a server certificate request, the client application must respond with a certificate; failure to do so results in authentication failure.

    ACMEPACKET(tls-profile)# mutual-authenticate disabled
    ACMEPACKET(tls-profile)#
  8. Retain the default value, compatibility, for the tls-version parameter.
  9. Retain default values for all other parameters.
  10. Use done, exit, and verify-config to complete tls-profile configuration.
  11. Repeat Steps 1 through 10 to configure additional tls-profiles as required.