cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
798
Views
2
Helpful
6
Replies

Unable to activate secure connection with TAPI

philicarr
Level 1
Level 1

Hi,

I'm trying to establish a secure connection between CUCM and TSP.

I think i've followed everything in this document correctly: Security Guide for Cisco Unified Communications Manager, Release 12.5(1) - Certificate Authority Proxy Function [Cisco Unified Communications Manager (CallManager)] - Cisco

I have signed and installed both Callmanager and CAPF certificate with a custom CA. I have installed my root certificate for both Callmanager and CAPF. I also installed my root certificate in windows certificate store where the TSP is installed.

I can't manage to establish a secure connection.

I have enabled detailed traces for the TSP and i get this error:

CSSLHelper::SSLConnectThreadEntry() Error error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

I see the certifcate being download via tftp correctly.

Do the TSP check root CA in the windows certificate store or i should put my root CA elsewhere?

I have included the full traces as attachment.

Thanks

1 Accepted Solution

Accepted Solutions

Hi,
I faced the same problem. Issue is, that the CTL does not contain the 3rd party CA. So TSP Client can not verify the CallManager certificate from his own trust store (TSP is checking 3rd Party CA - CSCuc76331). 2 Workarounds are possible:

Workaround #1:
1. Download the Root CA and any intermediary CA files (in pem format) and then re-upload it as "Phone-CTL-trust" file (in the example below there is only a Root CA)
2. Then update the CTL file with the CLI command "utils ctl update CTLFile".
3. At a minimum, you will need to restart the "Cisco TFTP service" so TFTP can serve out the new CTL file.
4. After the update, it will add the Root CA into the CTL as function of GENERIC APPLICATION. Now when TSP downloads the CTL file it will also pull down the root CA files and fully trust the CallManager certificate.

Workaround #2:
1. Download the root/intermediary CA certificates in pem format from the CUCM OS Administration -> Certificate Management web page.
2. Run the following openssl command: "openssl x509 -inform PEM -in <name of the CA certs downloaded>.pem -noout -subject_hash" against each certificate (this assumes the file is in the local directory where you are at within your command line) and you will get a subject hash value returned as seen in the example below:
openssl x509 -inform PEM -in Root_CA.pem -noout -subject_hash
d33178df
3. Then rename the file from "Root_CA.pem" to "d33178df.0" for example based on the output received from the openssl command.
4. Next copy each certificate into the C:\ProgramData\Cisco\certificates\ciscotsp001 directory where each file will have its unique subject hash with the file extension as .0.
Make sure you rename the extension so the file type is a 0 file type and not still a pem document.
5. Repeat steps 2-4 for each CA file and then make sure they are uploaded to the C:\ProgramData\Cisco\certificates\ciscotsp001 directory on the application server (in case of intermediary CAs).
6. Restart the telephony service

For me Workaround 2 was the quickest solution.
Hope that helps.

 

View solution in original post

6 Replies 6

RITT
Level 1
Level 1

Hi,

 Not sure if this is the same problem you are experiencing but version 10.5  needed to check certificate revocation for CTI Connections with JTAPI /TAPI applications, IPSec and LDAP using an OCSP server. Maybe 12.5 (1) is the same?

Have a look at the Chapter: Certificate Monitoring and Revocation in the 12.5(1) Security Guide for Cisco Unified Communications Manager to check.

I notice in your trace the line

16:25:14.871 | CSSLHelper::SSLConnectThreadEntry() Error error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Seems to suggest some sort of certificate verification failure, possibly the OCSP revocation check . Below is a link to the CUCM version 10.5 Security guide which states OCSP checks are required for secure CTI. Good luck.

Security Guide for Cisco Unified Communications Manager, Release 10.5(x) - Certificate Revocation/Expiry Status Verification [Cisco Unified Communications Manager (CallManager)] - Cisco

I will read your documentation about OCSP.

Thanks for your help

Would be interested to know if you have any success with this. Thanks

Hi,
I faced the same problem. Issue is, that the CTL does not contain the 3rd party CA. So TSP Client can not verify the CallManager certificate from his own trust store (TSP is checking 3rd Party CA - CSCuc76331). 2 Workarounds are possible:

Workaround #1:
1. Download the Root CA and any intermediary CA files (in pem format) and then re-upload it as "Phone-CTL-trust" file (in the example below there is only a Root CA)
2. Then update the CTL file with the CLI command "utils ctl update CTLFile".
3. At a minimum, you will need to restart the "Cisco TFTP service" so TFTP can serve out the new CTL file.
4. After the update, it will add the Root CA into the CTL as function of GENERIC APPLICATION. Now when TSP downloads the CTL file it will also pull down the root CA files and fully trust the CallManager certificate.

Workaround #2:
1. Download the root/intermediary CA certificates in pem format from the CUCM OS Administration -> Certificate Management web page.
2. Run the following openssl command: "openssl x509 -inform PEM -in <name of the CA certs downloaded>.pem -noout -subject_hash" against each certificate (this assumes the file is in the local directory where you are at within your command line) and you will get a subject hash value returned as seen in the example below:
openssl x509 -inform PEM -in Root_CA.pem -noout -subject_hash
d33178df
3. Then rename the file from "Root_CA.pem" to "d33178df.0" for example based on the output received from the openssl command.
4. Next copy each certificate into the C:\ProgramData\Cisco\certificates\ciscotsp001 directory where each file will have its unique subject hash with the file extension as .0.
Make sure you rename the extension so the file type is a 0 file type and not still a pem document.
5. Repeat steps 2-4 for each CA file and then make sure they are uploaded to the C:\ProgramData\Cisco\certificates\ciscotsp001 directory on the application server (in case of intermediary CAs).
6. Restart the telephony service

For me Workaround 2 was the quickest solution.
Hope that helps.

 

Hi Gunnar,

I tried your Workaround #1 and it did work! I wasn't aware about "Phone-CTL-trust" certificate category. I didn't know that the TSP had it's own certificate store. I tought it was using the Windows store.

Thanks for your help.

RITT
Level 1
Level 1

@Gunnar Reiser , @philicarr '

I had a similar problem to this but using JTAPI rather than TAPI. Just including my findings here in the hope it helps anyone using JTAPI. I followed this great guide for setting up a secure CTI connection.

https://community.cisco.com/t5/collaboration-knowledge-base/configuring-and-troubleshooting-secure-jtapi-cti/ta-p/3125041

Everything worked as per the guide but I could not achieve a secure connection from the pc CTI Java application to CUCM. Logs were showing "Unable to create provider - OCSP verification fails".

What I believe was happening is that during the setup (see linked guide above) the Cisco JTAPI client creates a server keystore (derived from the CUCM CTL file) and a client keystore. In my development environment the CUCM certificates are signed by a CA. The CA root certificate was not present in the CTL file (which is downloaded to the application pc from CUCM and used to create the server keystore).

I imagine that the absence of the CA root certificate from the CTL file, and subsequent server keystore, caused the pc application to try and verify the CUCM certificate trust chain using OCSP. My development infrastructure doesn’t have an OCSP server, hence the error and the failure of the secure connection as the certificate trust chain could not be verified.

If this were a Cisco phone rather than a pc CTI Java application, I guess the CUCM signed cert chain could be verified by the Trust Verification Service (TVS) that runs on CUCM?

Workaround #1:
Follow @Gunnar Reiser Workaround #1 above. This will add your Root CA cert to the CTL file.

Workaround #2:
1.Carry out the process detailed in this link

https://community.cisco.com/t5/collaboration-knowledge-base/configuring-and-troubleshooting-secure-jtapi-cti/ta-p/3125041

2.Once you have a server and client certificate store, download your CA root certificate to the pc running your CTI Java application.
3.Insert the CA root certificate (and any intermediary’s) into the server certificate store. You can use the Java command line tool "keytool" to do this.

> keytool -import -trustcacerts -alias rootCA -file ca_root.cer -keystore JtapiServerKeyStore

If anyone reading this has any documentation referring to adding CA certs to the CTL (best practise) I would love to see it!
Hope this helps someone