SIP TLS Trunk between CUCM 10.5 and VCS X7.2 do not accept the certificate

[epicolo]

Hi, here is the scenario:

there is a cluster of two VCS C running X7.2 with MS-Lync integration already running with B2BUA. Certificates already deployed for both VCSs and CA certificate uploaded to both.

A new CUCM 10.5.1 was installed for TX deployments and a SIP trunk was established with success. Unencrypted calls can be completed at both directions. No certificates was generated at this CUCM.

Now, this customer tried to set up a TLS between CUCM and VCS C:

- SIP security profile as indicated on pdf (Encrypted, TLS, 5061, x.509 pointing to subject name, etc)

- CSR generated at OS administration and signed by the corporate CA (the same that signed the VCS server certificate)

- server certificate uploaded at Callmanager-trust and also the CA certificate

- at VCS changed to TLS, 5061, TLS verify Off and pointing to CUCM name (FQDN at the certificate)

The result:

At CUCM, the trunk status is Full Service / up for the two peers

At VCS, it says: TLS negotiation Failure and the VCS Log says

2014-12-22T14:58:38+01:00 vcs1 tvcs: UTCTime="2014-12-22 13:58:38,753" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7fb85c9c1700": TTSSL_continueHandshake: Failed to establish SSL connection
2014-12-22T14:58:38+01:00 vcs1 tvcs: Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="x.x.x.x" Src-port="28361" Dst-ip="x.x.x.x" Dst-port="5061" Detail="sslv3 alert unsupported certificate" Protocol="TLS" Level="1" UTCTime="2014-12-22 13:58:38,753"

Another strange behaviour is that when we try to validate the client certificate selecting the server certificates signed by the company CA (VCS .pem file or the CUCM .pem file), the VCS say: "Invalid. Unable to get issuer certificate", even with the CA certificate uploaded on VCS.

We tried to upload the CA certificate on another VCS running X8.1 and use the client certificate check, and present the same result. (we can see the issuer CN of the verified server certificate and it matches the CA certificate.

PD: The devices was restarted.

Any ideas?

Thanks

[George Thomas]

Did you upload your CA root to CallManager-trust? I believe you need it on tomcat-trust as well. Also, does the certificate have the "Client authentication" attribute in addition to the "Server authentication".

[epicolo]

The problem is that the CUCM do not allow to upload the CUCM server certificate to the Callmanager portion. It shows CSR san name mismatch. There is a bug mentioned in another post.

[George Thomas]

Ah ok, so you didnt sign the CallManager certificate with a 3rd party CA is what you are saying? If that is the case, then you will need to upload the CallManager certificate to the VCS server. 

[Paulo Souza]

Check this sentence from your problem description:

at VCS changed to TLS, 5061, TLS verify Off and pointing to CUCM name (FQDN at the certificate)

Is that correct? I mean, TLS Verify mode should be set to on when using TLS with CUCM. In addition, does your VCS have valid signed certificated that was provided by the the same CA that is trusted by CUCM?

[epicolo]

VCS side is Ok. We tried using TLS verifiy on and off.

The problem is the CUCM that do not accept the certificate, it present this message: “CSR SAN and Certificate SAN does not match” and this can be due to the bug CSCur46416 (the running version is 10.5(1.10000.7)).  Another person said that he uploaded the certificate, but when I checked the certificate wasn´t there and even trying to generate another CSR and certificates, the CUCM always present the same error message.

We´ll open a SR on TAC to point us the best way to fix it.

Regards

[Joshua Warcop]

Are you generating a multi-san certificate for CUCM? If so make sure you're on a fixed release due to CSCup28852.

I haven't tested multi-san with latest release and therefore recommend single label certificates for Callmanager until someone has verified CSCup28852 is fixed.

Make sure your signing CA is issuing X509v3 compliant certificates.