Verify that a CA-signed X.509 certificate matches the CSR from your Cisco Collaboration server

The use of Certificate Authority (CA)-signed X.509 (aka TLS or SSL) certificates with Cisco's Collaboration products has risen substantially in the last few years since Cisco Jabber began performing certificate validation, the migration to web-based clients such as Cisco Finesse, and the IT industry woke up on the topic of security. The problem is that many of the certificates being purchased are secretly missing important requirements Cisco included in the Certificate Signing Request (CSR). It's important to verify what you asked for in the CSR actually matches what the CA included in the certificate they issued you.

This is an important step to perform before you install the certificate because a CA can omit anything in the signed certificate that it doesn't like from the CSR. If you catch the omission before uploading the signed certificate to the server you can work with the CA to reissue the certificate with the existing CSR after fixing the mistake; however, once you upload the certificate a new CSR will be required. Generating a new CSR may have cost implications from the CA.

Cisco's Platform Administration GUI does not validate that every last bit of the certificate matches exactly what was in the CSR. It seems to only check that the Common Name (CN) and Subject Alternate Name (SAN) attributes are consistent. Two important attributes that it doesn't validate are the Key Usage and Extended Key Usage attributes. Cisco's Operating System Administration Guide dedicates an entire section to these two attributes because they define what the certificate can be used for.

It is worth noting that each product has a separate OS Administration guide but only the CUCM document specifically states that "Tomcat does not require the Key Agreement or IPsec End System key usage" abilities. I have interpreted this as a documentation defect on the other products because all of them - including CUCM - include these abilities in their self-signed certificates and older versions of the OS Administration guide for CUCM prior to version 9.1 did not include this statement. Having said that, I am unaware of an actual defect ID to support this conclusion.

How To Decode the CSR, Certificate, and Identify a Problem

The easiest way to accomplish this is using OpenSSL which is likely to already be installed if you are using GNU/Linux or Apple OS X. For those on Microsoft Windows you can install Cygwin.

Viewing the CSR

The terminal command openssl req -text -noout -verify -in myCsrFilename.csr
will return the following output (shown in graphical and textual form for accessibility):

Figure 1 - OpenSSL Decode of a CSR

Plain Text Output of CSR Decode

[redacted computer name]:Downloads jschulenberg$ openssl req -text -noout -verify -in [redacted filename].csr

verify OK

Certificate Request:

    Data:

        Version: 0 (0x0)

        Subject: C=US, ST=[redacted], L=[redacted], O=[redacted], OU=[redacted], CN=[redacted server's DNS FQDN]/serialNumber=[redacted]

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

            RSA Public Key: (2048 bit)

                Modulus (2048 bit):

                    [redacted hexadecimal text of public key]

                Exponent: 65537 (0x10001)

        Attributes:

        Requested Extensions:

            X509v3 Extended Key Usage: 

                TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System

            X509v3 Key Usage: 

                Digital Signature, Key Encipherment, Data Encipherment, Key Agreement

            X509v3 Subject Alternative Name: 

                DNS:[redacted server's DNS FQDN], DNS:[redacted server's DNS FQDN], DNS:[redacted cluster DNS CNAM], DNS:[redacted organizational TLD], DNS:[redacted cluster DNS CNAM]

    Signature Algorithm: sha256WithRSAEncryption

        [redacted hexadecimal text of signature]

[redacted computer name]:Downloads jschulenberg$ 

Note the details within the Requested Extensions section that has been highlighted red for visibility. In the next section you will see a decoded certificates that is missing some of this detail.

Viewing the CA-Signed Certificate

The terminal command openssl x509 -text -noout -in myCertFilename.crt
will return the following output (shown in graphical and textual form for accessibility):

Figure 2 - OpenSSL Decode of a Certificate

Plain Text Output of Certificate Decode

[redacted computer name]:Downloads jschulenberg$ openssl x509 -text -noout -in [redacted filename].crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            [redacted hexadecimal text of serial number]
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=[redacted], CN=[redacted]
        Validity
            Not Before: [redacted]
            Not After : [redacted]
        Subject: C=US, ST=[redacted], L=[redacted], O=[redacted], CN=[redacted server's DNS FQDN]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    [redacted hexadecimal text of public key]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:[redacted hexadecimal text of key identifier]

            X509v3 Subject Key Identifier: 
                [redacted hexadecimal text of key identifier]
            X509v3 Subject Alternative Name: 
                DNS:[redacted server's DNS FQDN], DNS:[redacted server's DNS FQDN], DNS:[redacted cluster DNS CNAM], DNS:[redacted organizational TLD], DNS:[redacted cluster DNS CNAM]
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 
                URI:http://[redacted]
                URI:http://[redacted]

            X509v3 Certificate Policies: 
                Policy: [redacted OID of CA]
                  CPS: https://[redacted]
                Policy: 2.23.140.1.2.2

            Authority Information Access: 
                OCSP - URI:http://[redacted]
                CA Issuers - URI:http://[redacted]

            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
        [redacted hexadecimal text of signature]
[redacted computer name]:Downloads jschulenberg$ 

The Problem

Compare the Key Usage and Extended Key Usage attributes in the CSR with what the CA chose to include in the signed certificate. In this case, the Key Usage attribute is missing Data Encipherment and Key Agreement while Extended Key Usage is missing IPSec End System. As mentioned above, that Tomcat certificates do not require IPSec End System or Key Agreement but that leaves us without the required Data Encipherment ability.

The Upload Certificate dialog will accept this certificate even though it does not meet Cisco's stated requirements.  If you see this you should stop before uploading the certificate to the server and contact the support team of your CA to ask that they reissue the certificate exactly as the CSR requested it. As is usually the case: extra effort today prevents exasperation and orders of magnitude more effort expenditure later.

Avoid Problems with Subject Alternate Names

Another common pitfall arrises when the CSR includes a Subject Alternate Name (SAN) attribute. This will be present if either the set web-security command was used to add a SAN to an individual server (e.g. a user friendly FQDN such as myphone.domain.tld) or when using the Cluster-wide Multiserver Certificate Support introduced in CUCM and CUC version 10.0.

Some certificate authorities will copy the CN into the SAN when issuing the certificate. Since the Platform Administration GUI validates that both the SAN attribute matches exactly between the CSR and signed certificate, this will cause the uploading of the certificate to fail.

Figure 3 - Upload Certificate Dialog

To avoid this problem you must include the value of the CN as one of the SAN(s) when generating the CSR. The Generate Certificate Signing Request dialog in Platform Administration will allow you to add any Subject Alternate Name you wish after choosing a Distribution type of Multi-server(SAN).

Figure 4 - Generate Certificate Signing Request Dialog