Configuring SSL certificates

The MCU supports certificate-based user authentication over HTTPS, and is capable of mutual TLS authentication with the client. The client presents a certificate, signed by a certificate authority (CA), which the MCU trusts if it recognizes the CA from its trust store. Similarly, the client requests the MCU's local certificate and checks the signing CA against its own trust store.

To manage the MCU's local certificate and its trust stores for HTTPS and SIP TLS, and optionally to configure OCSP checks (Online Certificate Status Protocol) for HTTPS connections, go to Network > SSL certificates.

The SSL certificates page is also used to allow or enforce certificate-based login in place of standard, password-based login. Any attempts to authenticate with a revoked certificate are recorded in the MCU's Audit log.

In this topic:

• Prerequisites
• Managing trust stores
• Configuring SIP verification
• Configuring HTTPS verification
• Configuring client certificate security
• Configuring server certificate security
• OCSP checks for client certificate revocation
• Certificate details reference

Prerequisites

You should have your own local certificate and trust store(s), which must be in .pem format (Base64 encoded text).

HTTPS access to the web user interface requires the following prerequisites:

• The Secure management (HTTPS) or Encryption feature key must be installed on the MCU.
• HTTPS must be enabled on the Network > Services page.

To make SIP TLS calls between the MCU and remote parties requires the following prerequisites:

• The Encryption feature key must be installed on the MCU.
• A SIP username and password that are known by the registrar must be added to the Settings > SIP page.
• The Encrypted SIP (TLS) checkbox on the Network > Services page should be checked, for either IPv4 or IPv6, or both (depending on your requirements).
• The Use local certificate for outgoing connections and registrations checkbox should be checked if your environment dictates that the SIP registrar must receive the MCU's certificate.

Caution: A local certificate and private key are pre-installed on the MCU and are used by default for HTTPS access. As all MCUs have identical default certificates and keys, to ensure security we recommend that you replace it with your organization's own certificate and private key (see below).

Managing the local certificate

Uploading a local certificate and private key

1. Go to Network > SSL certificates.
2. Go to the Local certificate configuration section.
3. Click Browse for the Certificate field to navigate to the certificate .pem file.

4. Click Browse for the Private key field to navigate to the private key file that accompanies your certificate.

   You must upload the certificate and its key simultaneously.

5. In the Private key encryption password field, type the relevant password.

6. Click Upload certificate and key.

   The uploaded certificate overwrites the previously held certificate.

7. Restart the MCU.

Deleting a local certificate and private key

1. Go to the Local certificate section.
2. Click Delete custom certificate and key.
3. Restart the MCU.

Managing trust stores

A trust store is a collection of certificates from intermediate and root certificate authorities against which the MCU can attempt to verify client certificates it receives.

The MCU can hold three trust store files - one for HTTPS connections, one for SIP TLS connections and one for Call Home connections to verify the connection to the Smart Call Home server. When you upload a new trust store file, the previously held file is overwritten.The MCU has a certificate pre-installed, however, it is possible to delete and upload new certificates. You can also reset the certificate to default.’

Putting multiple CA certificates in a trust store

1. Open the first certificate in a text editor, and save it as yourfilename.pem.
2. Open the next certificate in your text editor, and copy all the lines from -----Begin Certificate----- to -----End Certificate----- (inclusive).

3. Paste the text block at the end of yourfilename.pem.

   Repeat this to copy as many certificate blocks into your .pem file as you need to, making sure not to modify any of the pasted text.

4. Save the resulting file.

Uploading a trust store

1. Go to Network > SSL certificates.
2. Go to the appropriate trust store configuration section (either the SIP trust store, HTTPS trust store or Call Home trust store).
3. Click Browse to navigate to your trust store .pem file (eg. yourfilename.pem).
4. Click Upload trust store.

5. Confirm that you wish to proceed.

   The trust store is uploaded, replacing the previous one (if it existed).

   Each certificate in the trust store appears in its own table row that shows pertinent certificate details in plain text.

Deleting a trust store

1. Go to Network > SSL certificates.
2. Go to the appropriate trust store configuration section (either the SIP trust store, HTTPS trust store or Call Home trust store).
3. Click Delete trust store.

4. Confirm that you wish to proceed.

   The trust store is deleted.

Resetting the Call Home trust store to default

1. Go to Network > SSL certificates.
2. Go to the Call Home trust store) configuration section.
3. Click Reset trust store to default.

4. Confirm that you wish to proceed.

   The trust store is reset to default.

Configuring SIP TLS verification

You can configure the MCU to secure incoming and outgoing SIP calls using TLS. The MCU uses its SIP trust store to verify the certificate presented by the remote end of a SIP TLS connection.

1. Go to Network > SSL certificates.
2. Go to the SIP trust store section.
3. Select one of the options from the Verification settings field.
4. Click Apply changes.

SIP verification options
No verification	All outgoing connections are permitted, even if the remote end does not present a valid and trusted certificate (remote end always trusted).
Outgoing calls only	Outgoing SIP TLS connections are only permitted if the remote end has a trusted certificate.
Outgoing and incoming calls	Outgoing and incoming SIP TLS connections are only permitted if the remote end has a trusted certificate.

Certificate identity requirements for SIP TLS

For an outgoing SIP TLS call, when inspecting the received certificate as part of the SIP TLS handshake, the MCU looks for either an IP address or a domain identifier for the remote party in the URI and DNS fields of the certificate's subject alternative name (subjectAltName) extension. If the subjectAltName is not present, the MCU looks for either an IP address or a domain identifier in the certificate's Common Name (CN) field.

For an incoming SIP TLS call, the received certificate should be trusted by MCU's SIP Trust store.

You should ensure that the certificates presented by your SIP entities to the MCU contain both the SIP URI and the IP address of the entity.

The remote party must similarly be able to verify the MCU's local certificate against its trust store, so the local certificate must also be generated according to the guidelines above.

Note: If you require TLS on non-proxied SIP calls from the MCU, the MCU's local certificate must identify the MCU by its IP address. This requirement arises because the remote endpoint will be establishing TLS connections directly to the MCU, which provides its IP address as its identity.

Configuring HTTPS verification

The HTTPS trust store section is where you can configure certificate-based authentication for users logging in to the web interface and for applications interacting with the API. This section also lets you configure whether the MCU should verify server certificates, presented by an OCSP server or by feedback receivers, before allowing these connections.

Configuring client certificate security

1. Go to Network > SSL certificates.
2. Go to the HTTPS trust store section.
3. Select one of the options from the Client certificate security field.
4. Click Apply changes.

Client certificate security options
Not required	Certificate-based client authentication is not required (default) and client certificates are ignored. Password-based authentication is required for all client access, whether by users over HTTPS or applications making API calls.
Verify certificate	Incoming HTTPS connections are only permitted if the client certificate is signed by an authority that the MCU trusts, but password-based login is still required to authenticate the client, for HTTPS, API, and other client connections.
Certificate-based authentication allowed	Incoming HTTPS connections are only permitted if the client certificate is signed by an authority that the MCU trusts and, if the certificate's common name matches a stored username, the client logs in as that user. However, if the certificate is trusted and the common name does not match, the client may log in with username and password.
Certificate-based authentication required	Incoming HTTPS connections are only permitted if the client certificate is signed by an authority that the MCU trusts. The common name of the certificate must also match a stored username and password-based client authentication is not allowed. HTTP and FTP logins are blocked. If Require administrator login is checked (on Settings > Security), then console access is restricted to functions that do not require a login. Note: The MCU requires every user account to have a password, even if Certificate-based authentication required is selected and thus clients may not use their passwords. Furthermore, if the MCU is in advanced account security mode, passwords must be replaced every 60 days. Users are not prompted to change their passwords when they log in using certificate-based authentication, so the passwords will expire and generate security warnings. For the purpose of any timed access restrictions that exist on user accounts (typically password change intervals and inactive account expiry rules) any log in using a certificate is treated as a standard password-based login and will reset the timer accordingly. For information about how these options affect the API interface, see the Cisco TelePresence MCU API Reference Guide.

Configuring server certificate security

1. Go to Network > SSL certificates.
2. Go to the HTTPS trust store section.
3. Select one of the options from the Server certificate security field.
4. Click Apply changes.

Server certificate security options
No verification	The MCU does not verify the server's certificate (if one is presented) when it makes an OCSP request or when it sends HTTPS feedback messages.
Verify certificate	The MCU requires a server certificate from the OCSP server or feedback receiver, and must be able to verify that the certificate is trusted by one of the authorities in its HTTPS trust store, before it completes the OCSP request or sends the HTTPS feedback message.

OCSP checks for client certificate revocation

You can optionally configure an external OCSP server, which the MCU will use to check the revocation status of client certificates presented with incoming HTTPS connection requests. The following details describe the MCU's OCSP checking mechanism.

• For chained certificates the OCSP check is performed only against the leaf certificate.
• The MCU supports SHA-1 hashing for OCSP.
• If the response from the OCSP server is anything other than 'good' (that is, the client certificate is invalid, revoked, unknown, timed out, or in some other error condition) the MCU rejects the associated connection request.
• No further OCSP checking takes place after the connection is established. An active session will continue if a certificate is revoked during that session, but any subsequent connection attempts with the revoked certificate will be rejected.

CAUTION: If you enable OCSP checking for the MCU it is possible inadvertently to block all login access (including administrators) to the MCU. If you want to enable OCSP checking, we strongly recommend that you first review the option descriptions below and then follow the process in Transitioning to certificate-based security.

Configuring the OCSP connection

1. Go to Network > SSL certificates.
2. Go to the Online certificate status protocol (OCSP) section.
3. Select HTTPS certificates in the Certificates to check field.

   When you click Apply changes, the OCSP check for HTTPS certificates will be enabled; if you select None you will disable the check.

4. Enter the server address in the OCSP server field.
5. Check the Require nonce checkbox if the server requires this extra level of security.
6. Enter the Maximum clock skew of OCSP server, in seconds.
7. Enter the Maximum age of OCSP server records, in days.
8. Click Apply changes.

OCSP details reference

Online certificate status protocol (OCSP) field descriptions
Certificates to check	None to disable OCSP checks or HTTPS client certificates to enable OCSP checks of HTTPS client certificates' revocation status.
OCSP server	The URL of the external OCSP server. If the default port allocation is sufficient (port 80 for HTTP and port 443 for HTTPS) use one of these formats, as appropriate: http://example.com; https://example.com; http://example.com/examplepath; https://example.com/examplepath To send to a non-standard port number (port 88 is used in the examples here) use one of these formats, as appropriate: http://example.com:88; https://example.com:88; http://example.com:88/examplepath; https://example.com:88/examplepath
Require nonce	Determines whether OCSP queries must include a nonce extension (to prevent replay attacks). If enabled, the MCU includes a nonce in each OCSP request, and requires the nonce to be returned in the corresponding response. If the nonce is not returned, the associated connection request is rejected. If disabled, the MCU does not send a nonce in OCSP requests.
Maximum clock skew of OCSP server	Specifies the maximum acceptable time (in seconds) for clock skew in OCSP responses. In this context the skew is the divergence between the respective system clocks on the MCU and on the OCSP server. If the skew exceeds this setting, then the OCSP responses may be treated as invalid.
Maximum age of OCSP server records	Specifies the maximum acceptable age (in days) for certificates. The certificate age is derived from the response field 'thisUpdate' which indicates when the returned status was last known to be correct. How this value is determined depends on the OCSP server configuration (often it is the last time the server was updated with a new Certificate Revocation List). The MCU rejects any response where the value of 'thisUpdate' is later in the past than the time derived by counting back from current time by the number of days specified here (after accounting for clock skew).

Certificate details reference

Field	Description
Subject	The business to which the certificate has been issued: C Country where the business is registered ST State or province where the business is located L Locality or city where the business is located O Legal name of the business OU Organizational unit or department CN Certificate common name, or the domain name
Issuer	The issuer of the certificate. Where the certificate has been self-issued, these details are the same as for Subject.
Issued	Date on which the certificate was issued.
Expires	Date on which the certificate will expire.
Private key	Your web browser uses the SSL certificate public key to encrypt the data that it sends back to the MCU. The private key is used by the MCU to decrypt that data. The private key field is only present for the local certificate.

Related topics

• Configuring security settings
• Configuring IP services
• Transitioning to certificate-based security