For networks running the Transport Layer Security protocol (TLS), you need to configure the certification file and the private key information required to pass SIP traffic.
TLS (sometimes referred to as Secure Socket Layer or SSL) is an encapsulation and cryptographic protocol that provides privacy and security between communicating applications over the Internet. The ME uses TLS to authenticate SIP users and to encrypt/decrypt SIP traffic across participating real time collaboration networks and enterprise SIP applications.
TLS handles presentation of certificates differently for clients (initiators) and servers (responders). Usually in a TLS connection, only the server presents a certificate: the client is only allowed to present a certificate if it is requested to do so by the server. Typically, the ME functions as a TLS server, and as such, presents a certificate to the peer. Occasionally, however, the ME functions as the client, for example, when it connects to a Microsoft LCS server. In this case, the server presents the certificate to the ME.
This operation will effect the peer-certificate-verification property setting of the certificate object. If-presented sets the ME to request a certificate from its peer, but allows the connection if the peer does not present. Required ensures that the peer presents a certificate for connection. If the certificate entry is used when the ME is a client, then If-presented and Required are equivalent. (This is because the server always presents a certificate.)
These two settings function differently when the ME is answering the connection (is the server). In the if-presented case, if the peer (client) doesn't present a certificate, the ME still allows the connection. If set to required, if the client doesn't present, the ME terminates the call. Realistically, therefore, the if-presented setting makes sense only for an ME.
The ME has the ability to verify a peer's certificate. By default, this behavior is disabled; all peer certificates are accepted. When enabled, however, the ME verifies a peer's certificate and rejects the connection if the certificate doesn't meet configured requirements. To verify, the ME checks the following:
The validity of the certificate's chain. It must be signed by a trusted Certificate Authority (CA), and must not have expired.
Clearing the Certificate Revocation List (CRL). This list tracks those certificates that a CA has revoked. If any of the certificates in the chain presented to the ME appear in the CRL, the ME rejects the connection.
The name of the host that is presenting the certificate. If the name does not match the name the ME expects (as set in the required-peer-name property), then the ME rejects the certificate, even if the chain is valid.
Certificate files and CA files can be in either PEM or PKCS#12 format. CRL files must be in PEM format. For a complete description of the TLS protocol, refer to the following RFCs:
The ME uses a certificate configuration to identify the certificate file and the characteristics of the certificate. There are two types of certificate configuration: a named certificate entry that can be applied to specific TLS connections and default certificate settings for use when a specific entry was not identified.
The entry created by the certificate object is used when the ME functions as a server in a TLS connection. Or, it can be used in an ME-as-client setup, if you have configured the connection to use a specific certificate. For example, when you set the connection type to the LDAP server to TLS in the directory object, you are required to enter a named certificate.
The entry created by the default-outgoing-settings object is used when the ME is a client with an unspecified certificate. For example, if you were to set the protocol that the DNS resolver server uses to TLS, you are not prompted for a certificate name. The ME uses either:
The certificate identified in the sip-settings object, if the session matched a configured policy
The default-outgoing-settings if the session did not match a configured policy or the policy did not have a certificate specified
The certificate and default-outgoing-settings objects are otherwise the same; all certificate properties are described in the default-outgoing-settings object.
Opens the TLS configuration object for editing. Through this object, you can configure certificate and private key information.
Creates a certificate object that sets characteristics of certificate use. This default certificate is used in cases when TLS is selected as a transport protocol and a specific certificate is not specified. See Using Certificates Vs. Default-Outgoing-Settings for more information.
The certificate for initiated connections also specifies the version of SSL/TLS to support. The ME supports SSL versions 2 and 3, and TLS version 1. You can specify any combination of these but be certain that at least one is set to true or the ME is not able to make connections. (By default, SSLv3 and TLSv1 are set to true.)
The ME can apply both a Certificate Authority (CA) and Certificate Revocation List (CRL) to a certificate. The CA file contains certificates that a peer can use to validate the certificate the ME presents to it during an SSL/TLS connection (see default-ca for more information). The CRL file is a list of certificates that a CA has revoked, and thus can no longer be trusted (see default-crl for more information). In each case, you have the option to configure a default file and/or a specific file to the certificate.
default: A file, or set of files, that are applied to all certificates. The ME applies the files to a certificate if the use-default-ca/use-default-crl property is set to true. If set to false for a particular certificate, then that certificate does not use the default files. (You can still configure the certificate to use a CA or CRL file using the specific option, described below.)
specific: A specific file that is applied either in addition to (if use-default is set to true) or instead of (if default is set to false) the default CA or CRL files for an individual certificate. You specify the specific file with the specific-ca-file property of this or the certificate objects.
certificate-file: Specifies the name of the certificate file used to establish connections made with this object. The system supports the following certificate formats.
PKCS#12: Public Key Cryptography Standard #12 format, often from Microsoft IIS Version 5 (binary)
PEM: Privacy Enhanced Mail format, from any OpenSSL-based web server (ASCII)
Enter a full path name to identify the certificate location.
Default: There is no default setting
Example: set certificate-file /cxc/certs/example.p12
passphrase-tag: Specifies the passphrase associated with the certificate file. Use this property if the certificate file is encrypted to have its private key information protected. This passphrase must match the string that the certificate was encrypted with.
Default: There is no default setting
Example: set passphrase-tag abc123xyz
allow-sslv2: Specifies whether the system can negotiate Secure Socket Layer Version 2 sessions with a peer. By default, the system only supports SSLv3 or TLSv1. If you require SSLv2 for interoperability, set this property to true. Note that SSLv2 is considered to suffer serious security holes.
Default: false
Values: true | false
Example: set allow-sslv true
allow-sslv3: Specifies whether the system can negotiate Secure Socket Layer Version 3 sessions with a peer.
Default: true
Values: true | false
Example: set allow-sslv3 false
allow-null-cipher: Specifies whether to use a null string in the client Hello. This setting is ignored if you have a value set in the cipher-config-string property.
Note that this property should never be enabled in a production environment, as it disables encryption. It is for debugging purposes only. If you do enable the null cipher, the client must list only the null cipher in its client Hello. Because the null cipher disables encryption, if any alternative is listed, the server will use it.
Default: disabled
Values: enabled | disabled
Example: set allow-null-cipher enabled
dynamic-buffers: Specifies whether to use dynamic buffers, an enhancement to the OpenSSL library. When enabled, the system allocates and frees transmit and receive buffers as they are needed, allowing support for many more TLS connections. When disabled, the system allocates both a transmit and a receive buffer at connection time, and holds the buffers open until the connection is dropped.
Default: enabled
Values: enabled | disabled
Example: set dynamic-buffers disabled
enable-cbc-counter-measure: Enables or disables an OpenSSL strategy the system uses when sending TLS records. The strategy is designed to prevent an attack on cipher block chaining (CBC) ciphers, which have a vulnerability in some SSL implementations. If set to false, you disable the protection.
Default: true
Values: true | false
Example: set enabled -cbc-counter-measure false
tx-record-length: Sets the record length in bytes for TLS packets. By setting the length to a value less than the default of 16,384 bytes, you reduce the amount of memory required on transmit.
Default: 2048 Values: Min: 1024 / Max: 16384
Example: set tx-record-length 4096
peer-certificate-verification: Specifies whether the system requests a certificate from a peer and the action in takes in response to the peer response.
Default: none
Values: none: The system does not request a certificate from a peer. The system allows the connection whether or not peer presents a certificate. (If the peer does present, the system ignores the certificate.)
if-presented: The system requests a certificate from the peer. If the peer presents, the certificate must pass verification for the connection to proceed. If the peer does not present, the system allows the connection. Use this setting only when the system functions as a server. See Certificate Presentation for details.
required: The system requests a certificate from the peer. If no certificate is presented, or if the presented certificate does not pass verification, the system terminates the connection.
Example: set peer-certificate-verification required
use-default-ca: Specifies whether to use the default revocation list(s) configured in the default-ca object.
Default: true
Values: true | false
Example: set use-default-ca false
specific-ca-file <filePath><passwordTag>: Specifies a CA file, and optionally a password, that should be used in addition to, or instead of, the default CA file(s). See Default Vs. Specific CA and CRL Files for more information.
Default: There is no default setting
Example: set specific-ca-file cxc/certs/caZ.pem tagA
use-default-crl: Specifies whether to use the default revocation list(s) configured in the default-crl object.
Default: true
Values: true | false
Example: set use-default-crl false
specific-crl-file <filePath><passwordTag>: Specifies a CRL file, and optionally a password, that should be used in addition to, or instead of, the default CA file(s). See Default Vs. Specific CA and CRL Files for more information.
Default: There is no default setting
Example: set specific-crl-file cxc/certs/cr199.pem tag1
required-peer-name: Specifies a name that must appear in the presented certificate. If you do not set this property, the system does not check the presented name.
If you do specify a name, then it must appear in either the DNS field of the altSubjectName field or in the Common Name field. To verify the peer, the system first checks to see whether there is an entry in the DNS field of the altSubjectName field. If there is, the system compares it to the required-peer-name. If it matches, the system allows the connection (and performs no further peer-name checks). If the names do not match, the system disallows the connection (and performs no further peer-name checks). If there is no entry in the DNS field, then the system checks the Common Name field. If there is a match, the system allows the connection. If the presented name does not match the required name, the system rejects the connection. You can use wildcards to express the name.
Default: There is no default setting
Example: set required-peer-name *.companyABC.com
cipher-config-string: Secondary property. Sets ciphers using the OpenSSL method. Do not change this parameter unless instructed to by Technical Support personnel.
Creates a pointer to a Certificate Authority file, which then becomes the default CA file for all certificates. This file contains certificates that a peer can use to validate the certificate the ME presents to it during an SSL/TLS connection. See Default Vs. Specific CA and CRL Files for information on using the default CA file.
CA files can be stored anywhere. However, if you store them in /cxc/certs directory, the ME copies them to all systems in the cluster. To make a CA file available for use, simply copy it on to the ME.
ca-file <path>[passwordTag]: Specifies the path to the CA file and the password (if required) to access the file. The default-outgoing-settings and certificate objects can then be configured to use or ignore these default files. You can specify multiple CA files to be used as part of the default.
Default: There is no default setting
Example: set ca-file /cxc/certs/ca1.pem tag1
Creates a pointer to the one or more Certificate Revocation List (CRLs), which the ME uses for certificate validation. The CRL file is a list of certificates that a CA has revoked, and thus can no longer be trusted. If any of the certificates in the chain presented to the ME appear in the CRL, then the ME rejects the connection.
Each certificate authority maintains an up-to-date list of revoked certificates. Because there are multiple CAs, you may wish to use multiple CRLs. CRL files can be stored anywhere. However, if you store them in /cxc/certs directory, the ME copies them to all systems in the cluster. To make a CRL file available for use, simply copy it on to the ME.
See Default Vs. Specific CA and CRL Files for information on using the default CRL file.
crl-file <path>[passwordTag]: Specifies a path to a CRL file and a password for that file. The default-outgoing-settings and certificate objects can then be configured to use or ignore these default files. You can specify multiple CRL files to be used as part of the default.
Default: There is no default setting
Example: set crl-file /cxc/certs/crl1.pem tag3
Creates a certificate object that sets characteristics of certificate use. The object is then used in other areas of the configuration to associate a certificate with a TLS connection. See Using Certificate Vs. Default-Outgoing-Settings for more information.
Enter a certificate name to open this object.