- Purpose of this Document
- Purpose of Certificates
- Defining "Trust" from a Certificate's Point of View
- Learning the Basics - How a Browser uses Certificates
- PEM vs DER - What's the difference?
- Certificate Heirarchy
- Self-Signed Certificates vs 3rd Party Certificate Authorities
- Understanding Common Names (CN) and Subject Alternative Names (SAN)
- What about WildCard certificates?
- The Certificates have the same Information in them. How do I know if this is the same certificate?
- What are CSRs and What would I use them for?
- The Process in using Certificates Between End Point - SSL/TLS Handshake
- How CUCM Uses Certificates - Difference between tomcat & tomcat-trust
- Conclusion
Purpose of this Document
To understand the basics of certificates and certificate authorties. This document is to compliment other Cisco documents refering to any encryption or authentication features in CUCM.
Purpose of Certificates
Certificates are used between end points to build a trust/authentication and encryption of data. This is to assure that the endpoints are communicating with the device that was intended and have the option of encrypting the data between the two endpoints.
Defining "Trust" from a Certificate's Point of View
Probably the top priority of certificates is defining what end points can be trusted by your end point. Meaning, how do I know my data is being encrypted and shared with the web site, phone, FTP server, etc. I intended to share with?
By saying that your system "trusts" a certificate means that there is a pre-installed certificate(s) on your system stating that your system is 100% confident it is sharing information with the correct end point. Otherwise, it will terminate the communication between these end points. For example:
Let's say you trust "Person A" (Certificate Authority). You are walking around and find "Person B" (End Point - like a website); you are about to tell "Person B" some secretive information - like where you have hidden your pot of gold. Now, you want to be 100% sure that "Person B" is not someone lying to you about who he is. Otherwise, he would just run off with your pot of gold. "Person B" presents a signed piece of paper (certificate) that is signed by "Person A"; you are able to verify with your own signed paper (certificate) from "Person A" that "Person B"'s signed paper is legitimate. Now you know you can trust "Person B" because he has been verified by "Person A". This has built trust due to this heirarchy.
Now, using the same example, let's say that "Person B"'s signed paper from "Person A" did not match your signed paper from "Person A". Well now you are sure you cannot trust "Person B" and you stop talking to him immediately. Therefore, you no longer trust "Person B" and you pot of gold is safe!
An example of this that is more familiar would be your drivers license. You use this license (Server/Service certificate) to prove you are who you say you are; you got your license from your local DMV branch (Intermediate Certificate) who has been given permission by the Division of Motor Vehicles of your state (Certificate Authority). When you get pulled over by the boys in blue you show your license. The officer knows he can trust the DMV branch and the Division of Motor Vehicles and can verify that this license was issued by them. This has verified your identity to the officer and now he/she trusts that you are who you say you are.
Otherwise, if you gave him a fake license that was not signed by the DMV then he will not trust that you are who you say you are and now you have some explaining to do.
There is a more technical explainantion of certificate heirarchy below.
Learning the Basics - How a Browser uses Certificates
Basics of internet surfing:
1. When going to a site you will use a URL like 'https://www.paypal.com'.
2. DNS will find the IP address of the server hosting that site.
3. The browser will navigate to that site.
But how would you know if you didn't use a rogue DNS server? Or if you were just routed to another server? In my example above, it would be devistating to go to a site you think is your bank's website and enter all kinds of private and sensitive information. Right?
All browsers have different icons they use but normally you will see a picture of a lock like this.
1. Click on that lock and you will see a popup like this.
2. Click on 'View Certificates' and you will see the site's certificate.
The highlighted information is important.
'Issued by:' is the Company or Certificate Authority (CA) that your system already trusts.
'Valid from/to' is the date range that this certificate is usable. (Sometimes you will see a certificate where you know you trust the CA, but you see the certificate is invalid. Always check the date so that you know if it has expired or not.) TIP: Best practice is to put a reminder in your calendar to renew the certificate before it expires. This will save you a lot of headaches.
PEM vs DER - What's the difference?
Simply, PEM is ASCII; DER is binary. Here is what it looks like:
PEM Certificate
 |
DER Certificate
 |
PEM format is normally how most CA companies like VeriSign and Thawt will send the certificates to customers since this format is email friendly. What the customer would need to do is copy the entire string - including '-----BEGIN CERTIFICATE-----' and '-----END CERTIFICATE-----' -, paste it into a text file, and save it with the extension .PEM or .CER.
Windows natively can read DER and CER formats with its own Certificate Management applet and will show the certificate like this:
In some cases a device will require a specific format (ASCII or Binary). The way you would change this would be to either download the certificate from the CA in the needed format or use a conversion tool like this - https://www.sslshopper.com/ssl-converter.html.
Certificate Heirarchy
In order to trust a certificate from an end point there has to be a trust already made with a 3rd party - Certificate Authority (CA). For example, in the image below there is a heiarchy of three certificates.
Verisign - is a Certificate Authority (CA).
Verisign Class 3 Extended Validation SSL CA - is an intermediate or signing server certificate (a server authorized by CA to issue certifiates in its name)
www.paypal.com - is a server or service certificate.
Your end point needs to know that it can trust both the CA and intermediate certificates first before it knows that it can trust the server certificate presented by the SSL Handshake (details below). To better understand how this trust works please review the section above about 'Defining "Trust" from a Certificate's Point of View'.
Self-Signed Certificates vs 3rd Party Certificate Authorities
The main differences between these two certificates at the highest level of understanding comes down to the following: Who signed the certificate & do I trust them?
A self-signed certificate is just a certificate signed by the server that is presenting it - therefore, the server/service certificate and the CA certificate are one and the same.
A 3rd part Certificate Authority is a service provided by either a public CA (like Verisign, Entrust, Digicert) or a server (like Windows 2003, Linux, Unix, IOS) that controls the validity of the server/service certificate.
Each one can be a Certificate Authority. Whether or not your system trusts that Certificate Authority is what matters the most.
Understanding Common Names (CN) and Subject Alternative Names (SAN)
Common Names & Subject Alternative Names are references to the IP address or Fully Qualified Domain Name (FQDN) of the address that is being requested. For instance, if I go to https://www.cisco.com then either the CN or SAN needs to have 'www.cisco.com' in the header.
In this example, the certificate has the CN as www.cisco.com. So the URL request for www.cisco.com from the browser checks the URL FQDN against the what the certificate presents. In this case they match amd the SSL Handshake is successful - this website has been verified to be the correct website and now communications between my desktop and the website are encrypted.
In the same certificate there is a SAN header for three FQDN/DNS addresses.
This certificate can authenticate/verify 'www.cisco.com' (which is also defined in the CN), 'cisco.com', and 'cisco-images.cisco.com' which means I can also type 'cisco.com' and this same certificate can be used to authenticate and encrypt this website.
CUCM can create SAN headers, please review Jason Burn's documentation for more information on this.
What about WildCard certificates?
Wildcard certificates are certificates that use an asterisk (*) to represent any string in a section of a URL. For example, to have a certificate for www.cisco.com, ftp.cisco.com, ssh.cisco.com, etc. an administrator would need to only need to create a certificate for *.cisco.com. This is a way to save money - instead of buying multiple certificates they would only need to buy a single certificates.
Currently, this is not supported by CUCM. But to keep track of this enhancement this defect and be followed - CSCta14114 Request for support of wildcard certificate in CUCM & private key import
The Certificates have the same Information in them. How do I know if this is the same certificate?
All certificates have a unique serial number. You can use this to find if the certificates are the same certificates, regenerated, or counterfeit. Please see the image below for an example.
What are CSRs and What would I use them for?
CSR stands for 'Certificate Signing Request'. If you want to create a 3rd party certificate for a CUCM server you need a CSR to present to the CA. This CSR will look a lot like a PEM (ASCII) certificate. But this is NOT a certificate and cannot be used as one.
CUCM makes these automatically via web GUI. (Cisco Unified Operating System Administration > Security > Certificate Management > Generate CSR > choose service you want to create the certificate for > Generate CSR). Everytime this option is used, a new private key and CSR is generated. (NOTE: a private key is a file that is unique to this server and service. This should NEVER be given to anyone! Providing a private key to someone comprimses the security certificates provides.) Also, do not regenerate a new CSR for the same service if you are using the old CSR to create a certificate because CUCM will delete the old CSR and private key and replace them both - making the old CSR useless.
To understand how to create CSRs please review Jason Burn's documentation on this - CUCM Uploading CCMAdmin Web GUI Certificates
The Process in using Certificates Between End Point - SSL/TLS Handshake
The handshake protocol is a series of sequenced messages that negotiate the security parameters of a data transfer session. The image below illustrates the message sequence in the handshake protocol. (These can be seen in a packet capture (PCAP).)
Client Hello: The client initiates a session by sending a Client Hello message to the server.
Server Hello: The server responds with a Server Hello message.
Server Certificate: The server sends its certificate to the client. The server certificate contains the server’s public key. The client will use this key to authenticate the server and to encrypt the premaster secret.
The client also checks the name of the server in the certificate to verify that it matches the name the client used to connect. If the user typed www.cisco.com as the URL in the browser, the certificate should contain a subject name of www.cisco.com or *.cisco.com. Internet Explorer will warn the user if these names do not match.
Server Key Exchange: This is an optional step in which the server creates and sends a temporary key to the client. This key can be used by the client to encrypt the Client Key Exchange message later in the process. This step is only required when the public key algorithm does not provide the key material necessary to encrypt the Client Key Exchange message, such as when the server’s certificate does not contain a public key.
Client Certificate Request: This is an optional step in which the server requests authentication of the client. This step might be used for Web sites (such as a banking Web site) where the server must confirm the identity of the client before providing sensitive information.
Server Hello Done:. This message indicates that the server is finished and awaiting a response from the client.
Client Response to Server
Client Certificate: If the server sent a Client Certificate Request, the client sends its certificate to the server for client authentication. The client’s certificate contains the client’s public key.
Client Key Exchange: The client sends a Client Key Exchange message after computing the premaster secret using both random values. The premaster secret is encrypted by the public key from the server’s certificate before being transmitted to the server. Both parties will compute the master secret locally and derive the session key from it.
If the server can decrypt this data and complete the protocol, the client is assured that the server has the correct private key. This step is crucial to prove the authenticity of the server. Only the server with the private key that matches the public key in the certificate can decrypt this data and continue the protocol negotiation.
This message will also include the protocol version. The server will verify that it matches the original value sent in the client hello message. This measure guards against rollback attacks. Rollback attacks work by manipulating the message in order to cause the server and the client to use a less secure, earlier version of the protocol.
Certificate Verify: This message is sent only if the client previously sent a Client Certificate message. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with the client’s private key.
Change Cipher Spec: This message notifies the server that all messages that follow the Client Finished message will be encrypted using the keys and algorithms just negotiated.
Client Finished: This message is a hash of the entire conversation to provide further authentication of the client. This message is the first message that the record layer encrypts and hashes.
Server Final Response to Client
Change Cipher Spec Message: This message notifies the client that the server will begin encrypting messages with the keys just negotiated.
Server Finished Message: This message is a hash of the entire exchange to this point using the session key and the MAC secret. If the client is able to successfully decrypt this message and validate the contained hashes, it is assured that the SSL/TLS handshake was successful, and the keys computed on the client machine match those computed on the server.
How CUCM Uses Certificates - Difference between tomcat & tomcat-trust
When uploading certificates to CUCM there are two options for each service. (Cisco Unified Operating System Administration > Security > Certificate Management > Find) The five services that allow you to manage certificates are tomcat, ipsec, callmanager, capf, &, added in CUCM 8.x, tvs. The services that allow you to upload certificates to CUCM is:
tomcat
tomcat-trust
ipsec
ipsec-trust
callmanager
callmanager-trust
capf
capf-trust
And, added in CUCM 8.x:
tvs
tvs-trust
phone-trust
phone-vpn-trust
phone-sast-trust
phone-ctl-trust
To get more details as to what these types of certificates are for, review the CUCM security documentation(s) for the correct version of CUCM. This section is only to explain what the difference is between a service certificate and a trust certificate.
For example, with Tomcat, the tomcat-trusts are for uploading the CA and intermediate certificates so that this CUCM node knows it can trust any certificate signed by the CA and intermediate server. The tomcat certificate is the certificate that would be presented by the tomcat service on this server if an end point makes a HTTP request to this server. To allow 3rd party certificates to be presented by tomcat, the node needs to know it can trust the CA and intermediate server. Therefore, it is a requirement to upload the CA and intermediate certificates first before uploading the tomcat (service) certificiate.
To understand how to upload certificates to CUCM correctly please review Jason Burn's documentation on this - CUCM Uploading CCMAdmin Web GUI Certificates
Each service has their own service certificate and trust certs. They do not work off each other - meaning that a CA and intermediate certificate uploaded as a tomcat-trust cannot be used by the callmanager service.
NOTE: Certificates in CUCM is a per node basis. Therefore, if you need certificates uploaded to the publisher and need the subscribers to have the same certificates you would need to upload them to each individual server/node pre CUCM 8.5. After 8.5 there is a service that will replicate uploaded certificates to the rest of the nodes in the cluster.
ONE MORE THING: Each node will have a different Common Name (CN). Therefore, a CSR will need to be created by each node for the service to present their own certificates.
Conclusion
I hope this document has offered an enjoyable approach to building a high level understanding of certificates. This subject can matter can get much deeper but this document should get you familiar enough to begin working with certificates. Understanding all of CUCM security features can be answered using the security documentation if there are specific questions that you might have. Thank you for your time.