Maintenance Manual

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.
CAUTION: If you transition from solely password-based client authentication to any level of certificate-based client
authentication (including those that permit but do not require certificates), it is possible inadvertently to block client
access to the MCU. This can happen if HTTP is disabled or if HTTP to HTTPS redirection is enabled. In such cases, a
certificate that is trusted by the MCU must be presented by the client side (typically you the administrator) in order to
log in. If no such client certificate exists then no one can log in.
We strongly recommend that you first review the option descriptions below and then follow the process in
Transitioning to certificate-based security.
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.
227
Cisco TelePresence MCU Series Online Printable Help