Certificates FAQ

From DocWiki

Jump to: navigation, search

Back to Unified Communications FAQ

I've seen a lot of people struggling with the certificates, in the past we didn't deal with certs so much, it was a rare situation someone wanted to get rid of the message when logging into ccmadmin, your cluster communication with other devices/clusters, etc.

These days, it's becoming more, and more common, and plenty of things rely on them, for example: EMCC, ILS, SIP secure trunks, MRA, ITL, etc.
So, it's harder and harder to try and deal with all them, and particularly for those that have no experience.

DISCLAIMER: I'm only going to talk about MY personal experience with certs, there might be things I'm missing as I usually only deal with my own lab CA. I also might not use the exact terminology, feel free to correct me. This is not going to be the all mighty guide for certs, that's for sure.

So, certificates, what do we use them for?? We use them to authenticate the servers, and to have the other end trust we are, who we say we are.
How does that work?? There's plenty of material on the web about the topic, if you're interested, you only need to google certificates. A 10-mile high overview is:

  • The CA is someone you know you trust, he uses a CA certificate from which ALL other certificates it issues, is based on. They will also use a hash algorithm of their selection (SHA1, SHA2, SHA256, SHA512 are examples)
  • You will generate a CSR (certificate sign request) on your server, this is going to be created using private key (to authenticate what you get back is the same you produced), the CA will take the raw data from the CSR, and will sign it, and it will give it some key, and enhanced key usage properties (we'll get to that later)
  • You will get back a .cer (or.pem, there are actually many kinds of certs), along with the root CA certificate, and intermediate CAs (we'll also get to that)
  • You will go to your server, and upload the root CA, intermediate CAs, and finally the server cert (And there's a logical reason for doing so in that order)
  • Most usually you'll need to reboot the server, restart some service, or something along those lines to make the new certs take effect.
  • You're done

That's the process very simplified, because there are some other things.

So, someone recently asked this at CSC Any way to import private key and certificate? make sure to read it before going on.

You might ask what he's talking about?? If not, you probably know something about CAs, cryptography, openssl, etc.

Most products have a nice way to create the CSR, and as I mentioned before, that CSR has been created with a key. If you have used the vTP server, you'll know it does not have that, and you usually require to use openssl to create the CSR.

Digicert built this nice tool that can help you build the openssl command you need for the CSR: OpenSSL CSR Wizard

So, an example of that for my lab vTP server would be:

openssl req -new -newkey rsa:2048 -nodes -out tp-server.csr -keyout tp-server.key -subj "/C=MX/ST=Mexico City/L=Mexico City/O=Cisco Systems/OU=PDI MX/CN=tp-server.pdimx.cisco.com"

So, what you get out of that process are two files:

  • tp-server.csr This is what you would send your CA to sign
  • tp-server.key This you'll need to upload to vTP once you have the .cer, to authenticate it's the same request.

So, back to the question from CSC, the reason that is not possible, is because CUCM would generate the CSR and the key (as the above command), BUT you don't get they key, nor you can upload your own. Most products will do the key/CSR pairing behind the scenes so you don't worry about that.

So, what if you generate a CSR, send it to sign by your CA, and then happen to click once again on generate a CSR???
The .cer you get back won't be accepted, because there can only be one CSR/key pair at any point in time, and the .csr and .key pair are created to be unique.

Now, back to, say, CUCM. There are plenty of certs in CUCM, most usually people only change that one, but you can change them all if you need/want/require to.
We'll do the Tomcat one, you'll grasp the idea and it's pretty much the same way for all other certs.

So, the very first thing, is to go to your CUCM server, click on your Tomcat certificate, and download it, it'll usually be a .pem file, simply change that to a .cer (Windows will warn you about changing the extension, just click yes to continue). Now open the .cer file you have, go to the details tab, you'll see several important details to keep in mind:

  • Signature algorithm
  • Signature hash algorithm
  • Public key, take note of this, the new cert key cannot be less than what shows there
  • Key Usage, also take good look at what it has, your CA has to try to give the same it shows there.
  • Enhanced Key Usage, your CA needs to give you certs that have the SAME properties, in this example, Tomcat requires Server Authentication, Client Authentication, and IP security end system

So, I'll see if I can add some pictures later, but in the meantime, it'll be all text.

So, I'm using a MS Windows Server 2012 as my CA, I chose SHA256 when I installed the CA on my server. It also works as the DC/GC/LDAP/DNS for my domain, you can have a separate server if you like/want/need to.

I'll assume you have already configured the CA with the MS add/remove features, if you need assistance with that, I'm pretty sure there are plenty of things if you google "how to install CA on MS Windows server"

So, from the Server Manager window, click Tools -> Certificate Authority

It will open the CA window from the server, you can handle all your requests from here.
One of the first things you might want to change, is to adjust the validity period for your certificates, as well as for your CRLs. It's all managed via some keys in the registry, you can find the info here: How to change the expiration date of certificates that are issued by a Windows Server 2003 or a Windows 2000 Server Certificate Authority

This way you won't have to worry of the certs expiring too soon, or too late, depending on what you want. For my lab, I usually set them to 20 years to avoid having to do this very often. Adjust as your policies require. Once you're done with that, you probably want to adjust your templates.

Go to the CA window, and expand your CA tree so you can see the several options, right click on Certificate Templates, and click on Manage. It will open the Certificates Template Console.
The template you want to use as a starting point is Web Server, you might need to create more than one, depending on the cert requirements. Right click on the template, and click Duplicate Template. At this point, you probably want to go back to the original cert from CUCM you want to replace, and review the properties, so, for this example, I'll be working with a CUCM 11 tomcat cert, open up your .cer file and go to the details tab, we'll map those properties over to the CA template.

In the General tab from template manager set the new name for this template, and adjust the Validity period and Renewal period as necessary (it can be different from the registry key settings). In the Request Handling tab, make sure the Purpose shows as: Signature and encryption. Under the Cryptography tab, go over to your cert, and locate the Public key field, for my server, it shows as RSA (2048 bits), you need to match that value in the Minimum key size field, some certs might require a lower value, and a separate template will be required. You might also lower that value to 256 and it should suffice for pretty much all the other certificates, your choice.

Under the Extensions tab, we're going to do the most job here. First, look at your certificate for the Enhanced Key Usage field, mine shows 3 values:

  • IP security end system
  • Server Authentication
  • Client Authentication

The Web server template by default only has Server Authentication, so we need to add the remaining options, choose Application Policies from the box and click Edit..., click Add.. in the Edit Application Policies Extension window, locate the Client Authentication policy and click OK, repeat for IP security end system policy, and click OK, make sure the 3 options show up now.

Go back to the cert, and find Key Usage, for mine, it show:

  • Digital Signature
  • Non-Repudiation
  • Key Encipherment
  • Data Encipherment

Let's go back to the Template to have those in our cert, we're still under the Extension tab, click on Key Usage from the options, and click Edit..., by default only Digital Signature is checked, you also need to check the Signature is proof of origin (nonrepudiation) option under the Signature box options, under the Encryption box you should have the option: Allow key exchange only with the key encryption (key encipherment) and check the option that's just below: Allow encryption of user data.

Now you can finally click on OK to finally create the new template, and it should be listed under the Certificates Templates Console, go back to the CA window you originally opened, and click on Certificate Templates, right click on the blank area on the right area of the window, and choose New -> Certificate Template to Issue, the Enable Certificate Templates window shows up, and you'll see the templates from the Template Manager, but you need to add them here so they're available via the web-page we're going to use to sign the CSRs. Simply find the template you just created, and click OK.

And we're done with the CA config, now we're going to actually generate the CSR on CUCM and get it signed.

You need to browse to: http(s)://x.x.x.x/certsrv/ depending on your web server config it might simply be http, or https.

Once you're in, click on Download a CA certificate, certificate chain, or CRL Assuming you have more than one CA, choose the one you'll be using to sign your certs, choose Base 64 as Encoding method and choose Download CA certificate, if you're working with intermediate certs also get Download CA certificate chain. For some products like VCSs you will also need the CRLs. But for CUCM it won't be necessary.

Go to the OS admin from CUCM and login. Go to Security -> Certificate Management, click on Find. It will list all the current certs, you probably will see them all as signed by the very same server. So, we'll generate the CSR for tomcat:

  1. Click on Generate CSR
  2. The settings should be:
    • Certificate purpose = tomcat
    • Distribution if you want to generate the certificate for only that server, choose the name from the server, if you want a multi-san for ALL the servers in the cluster, change it to Multi-server(SAN)
    • Make sure the Common Name is correct, if you chose the MS option, it will show with an extra -ms after the hostname, and the real FQDN will be in the SANs window, make sure they're all correct
    • Make sure the parent domain is correct
    • Leave the Key Length at 2048
    • Leave the hash algorithm as SHA256
  3. Click Generate

The window will close, and the Certificate List will be updated with a CSR, now, click on Download CSR from the top bar. If you have generated CSRs for other purposes, they will be listed there, choose tomcat from the drop-down menu, and click on Download CSR, you'll get a tomcat.csr file

Open up the file on notepad, or notepad++, it will look like a lot of random letters in between a BEGIN CERTIFICATE REQUEST and a END CERTIFICATE REQUEST tag. That is what you will input in the certsrv page.

  1. Go to http(s)://x.x.x.x/certsrv/
  2. Click on Request a certificate
  3. Click on advanced certificate request.
  4. In the Saved Request: field, you need to copy ALL the contents from the .csr file, do a select all, and copy it into that field
  5. In the Certificate Template: drop down, you need to choose the template you just created.
  6. Click submit
  7. Assuming there were no errors, you'll get your certificate, choose the Base 64 and save your .cer file

Now, we have all the certificate we need to upload them to the CUCM server, let's go back to the OS admin page. Security -> Certificate Management.

We'll need to upload the root/intermediate certs in first place to the tomcat-trust repository

  1. Click on Upload Certificate/Certificate chain
  2. Choose Certificate Purpose as tomcat-trust
  3. If you want, set a friendly name for your cert
  4. Click Choose File and browse to your root CA certificate
  5. Click Upload
  6. If you have intermediate certificates, repeat the above process for all of them.

Once you have all the root/intermediate certs uploaded, we can upload the actual server certificate

  1. Click on Upload Certificate/Certificate chain
  2. Choose Certificate Purpose as tomcat
  3. Click Choose File and browse to the tomcat certificate you just generated.
  4. Click Upload
If everything went fine, you should see a message telling you that you need to restart the Tomcat service in order for changes to take effect, go ahead and restart Tomcat via CLI/console by issuing:
utils service restart Cisco Tomcat

If you don't have the root CA/intermediate certs installed on your computer, now it's a good time to install them, simply open the certs, and you should see a Install Certificate... option, click on it, and follow the wizard, make sure to place them in the Trusted Root Certification Authorities store. If you already have them you can go ahead with the next step.

Once Tomcat comes back, you should be able to browse to
https://< Server FQDN/CN in cert>/ccmadmin
and do not receive any kind of warnings about the certificates, if you're using Chrome, you should see a green lock icon, as well as https in green to the left of the URL. If you use Firefox, you should see a lock icon to the left of the URL.

And that, is the theory of using a MS CA to sign your certificates. It's a lot more time consuming than complicated, but once you get the hang of it, you can do this very quickly and easily for all your UC servers, the theory is pretty much the same for all the other products.

This was an example for the Tomcat certificate, but the same theory is applicable to all the other certificates. I'm not trying to tell you how to do every single certificate, I'm trying to get you to understand the process and theory around this, so you can apply it to other products/certificates.

If you're going to be using a public CA, there might be some additional considerations for them, before the end of this year, the public CAs will only sign certificates that have a domain which can be resolved on the internet.

You might want to review these bugs:

  • CSCup28852 phone reset every 7min due to cert update when using multi-server cert
  • CSCus47235 CUCM 10.5.2 CN not duplicated into SAN for CSR
    This one only applies to 10.5 releases as what they did for the CN for the MS cert, was to add a -ms at the end of the FQDN from the server, and so, a public CA would deem mycucm.mydomain.com-ms as invalid for a CN, this has been fixed in 11.x and it now shows up as mycucm-ms.mydomain.com, as you can see, the -ms is still there, but it has been moved to be appended to the hostname.
  • CSCta14114 Request for support of wildcard certificate in CUCM & private key import
  • CSCuv39341 Jabber for Android prompts Certificate warning
  • CSCuv91020 Jabber iOS Certificate pop-up due to incorrect handling
  • CSCuv92383 Jabber Android Certificate pop-up due to incorrect handling

If you're going to be dealing with ITL /SBD, you also want to take some time to review the following:

NOTE If you're going to be changing the Callmanager.pem and the TVS.pem, make sure to read the last link, as there is a particular order in which you need to do that, failing to follow the right procedure, will mean your phones will not be able to register to the CUCM server, and you will need to bulk delete the ITL files from them.

I recently recorded a video for the above procedure, I just did one certificate as an example, but it should give you the knowledge to replicate as necessary in other certs / products:

Related material

How to regenerate self-signed certificates

Why would you need to do this??
The most likely reasons are that you have always used self-signed certificates and they're about to expire, or that you're moving from a public CA certificate, back to self-signed certificates.

The procedure is very simple, and there are two ways to do this, they both start the same way

  1. Go to the OS Administration page
  2. Security -> Certificate Management

And then it depends on what method you want to use, they both will have the same result

Method 1:

  1. Click Find
  2. Click on the Common Name of the certificate you want to change, for example the CallManager certificate for my server would be: CUCM105PUB.pdimx.cisco.com
    This will open a new window with 4 options (the same) at the top, and at the bottom of the screen: Regenerate, Generate CSR, Download .PEM file and Download .DER file
  3. Click Regenerate
  4. Repeat as necessary for other certificates

Method 2:

  1. Click Generate Self-Signed
    A new window opens, with the following warning message:
    Generating a new certificate will overwrite any existing certificate information. When generating Call Manager, CAPF, or TVS, all devices will be reset automatically.
  2. From the Certificate Purpose drop-down, choose the certificate you want to regenerate as self-signed
  3. Change the Key Length, if necessary
  4. Change the Hash Algorithm, if necessary
  5. Click Generate

The difference between the methods, is that #1 will use the default values for Key Length and Hash Algorithm, and #2 lets you change those as necessary. Depending on the certificate, you might need to restart the associated services for the new cert to take effect. The same recommendations / restrictions I wrote about ITL apply for this.

I recently recorded a video of this procedure:

Back to Unified Communications FAQ

ITL certificates during a PCD migration

We found this behavior during a migration in which we kept the hostname and just changed the IP address, I already had all the certificates signed by my CA on 9.1, and wanted to test if they would be migrated, and they were, however, we found something interesting regarding the ITL files, see below samples from 3 lab clusters, running 9.1, 10.5 and 11:

9.1 cluster

admin:show itl
The checksum value of the ITL file:
e57a5bcc524379799a831ed1b64455fc(MD5)
8147925b8f28ee05c5ed30f7448b1994609402e2(SHA1)


Length of ITL file: 5468
The ITL File was last modified on Mon Dec 07 11:33:38 CST 2015

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   320 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       133
4       SIGNERNAME      93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
5       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
6       CANAME          12      CN=pdimx-CA
7       SIGNATUREINFO   2       15
8       DIGESTALGORTITHM        1
9       SIGNATUREALGOINFO       2       8
10      SIGNATUREALGORTITHM     1
11      SIGNATUREMODULUS        1
12      SIGNATURE       128
                4c  43  26  d9  50  8f  14  f9
                42  1  ef  65  db  c8  a9  d8
                fa  3c  cb  18  e2  c0  ed  e0
                d5  7a  b  56  fd  47  2c  0
                35  af  34  9d  c4  f1  33  fc
                bb  85  c1  41  c  40  80  d0
                30  c  c2  6e  93  49  5  33
                32  94  6c  d8  ea  8d  57  7d
                84  c6  b7  e2  38  71  28  1d
                1  4d  3f  af  8d  4e  6f  1c
                a7  83  10  d0  eb  75  f3  b5
                69  f6  c7  dc  7f  b6  19  8b
                ca  16  46  f6  3d  66  ae  71
                e3  3d  78  b5  22  83  e7  b1
                fe  6b  90  4  39  4e  d2  d8
                7  95  5  f1  ee  58  5c  24
14      FILENAME        12
15      TIMESTAMP       4

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       561
2       DNSNAME         2
3       SUBJECTNAME     77      CN=CAPF-82b79a6d;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       CAPF
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2F:66:BF:E0:48:FE:DD:59:79:00:00:00:00:00:2F
7       PUBLICKEY       140
8       SIGNATURE       256
11      CERTHASH        20      4D 34 EF EE 0A 69 B2 C2 80 8E 1F B8 44 8A 30 B0 A1 DE A2 7D
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       707
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TVS
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2E:89:08:E4:F0:7D:83:2D:8F:00:00:00:00:00:2E
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      8C 43 B1 6E 27 92 BF 6D F8 27 0E 36 B0 A4 1A BA FE BE 41 9E
12      HASH ALGORITHM  1       SHA-1

The ITL file was verified successfully.

10.5 cluster this was not a migration, this was a fresh install, but I want to show the difference in ITL files

admin:show itl
The checksum value of the ITL file:
cb8afe9f0c295776a9ed6d1813f76b1e(MD5)
22d69ec0281ba5b58983d37f1dce451a743cb24e(SHA1)


Length of ITL file: 8191
The ITL File was last modified on Mon Feb 08 08:27:48 CST 2016

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   444 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       130
4       SIGNERNAME      90      CN=CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
5       SERIALNUMBER    19      77:00:00:00:25:61:8D:75:4E:91:73:2E:82:00:00:00:00:00:25
6       CANAME          12      CN=pdimx-CA
7       SIGNATUREINFO   2       15
8       DIGESTALGORTITHM        1
9       SIGNATUREALGOINFO       2       8
10      SIGNATUREALGORTITHM     1
11      SIGNATUREMODULUS        1
12      SIGNATURE       256
                8a  1  47  4a  cd  e4  8e  b4
                10  f7  2b  e5  61  aa  b0  12
                8c  38  d3  8b  9  b8  54  9a
                93  4d  9b  0  d3  b2  ec  24
                c7  f8  2f  53  4e  7b  97  a2
                78  bd  ac  9e  c3  93  4  89
                ad  5c  34  97  83  98  c8  6b
                f3  65  7a  de  4e  57  f3  bd
                68  9b  33  96  bc  70  73  cc
                16  ab  e0  5e  12  b0  f7  a8
                9d  1d  16  28  3b  a9  c8  15
                a4  c1  84  68  36  e9  77  5b
                d1  ae  5  9f  46  2e  b0  10
                8  a9  f6  d8  6b  6e  1  3c
                2e  ac  ca  21  a0  38  3a  d4
                30  d5  31  b6  93  29  ea  a3
                9  46  66  e  39  27  cf  1c
                93  56  84  91  10  c6  95  f7
                c4  a5  e9  90  1c  94  c8  46
                d2  51  3e  12  55  32  e3  7a
                70  50  23  3a  79  93  af  4
                bc  15  f1  49  8c  cc  a9  ee
                b0  3a  b6  c  52  ed  2  3
                de  8e  2  d9  4e  d0  23  7
                54  cd  56  de  4  48  75  2a
                54  38  df  f8  d0  9d  cb  8b
                9b  c4  f8  80  99  c4  13  3d
                eb  d  90  5b  63  40  38  66
                32  bc  18  fb  40  af  61  e6
                d6  1a  5b  17  5d  b2  98  70
                e6  59  38  98  db  e1  b  10
                3  5a  2a  38  56  cb  24  54
14      FILENAME        12
15      TIMESTAMP       4

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       691
2       DNSNAME         2
3       SUBJECTNAME     77      CN=CAPF-4497abe1;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       CAPF
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:24:D8:1D:B6:6A:D4:D4:47:06:00:00:00:00:00:24
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      31 0B 1F 89 70 56 5A 1E EC 22 DE 6A 19 D9 C5 47 A7 44 E3 AA
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       718
2       DNSNAME         16      pdimx.cisco.com
3       SUBJECTNAME     90      CN=CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TVS
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:20:70:75:D1:2B:B4:48:B0:CD:00:00:00:00:00:20
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      B6 C8 97 F2 7F D9 C9 01 2A 47 8E AE 86 93 5A 02 90 67 B0 0E
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1806
2       DNSNAME         2
3       SUBJECTNAME     102     CN=ITLRECOVERY_CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      102     CN=ITLRECOVERY_CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
6       SERIALNUMBER    16      4C:DA:45:88:AA:68:67:86:B1:2B:32:D1:67:40:5A:C1
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1027    CE 04 2C 34 53 3E 03 F7 55 25 93 29 4C 81 EA FF E6 95 C9 D3 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       2266
2       DNSNAME         16      pdimx.cisco.com
3       SUBJECTNAME     90      CN=CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:25:61:8D:75:4E:91:73:2E:82:00:00:00:00:00:25
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1572    CD 2D 6E AC B3 BA 0F E4 33 CB EA D1 F2 1A 6C D6 76 78 BB 07 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

        ITL Record #:5
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       2266
2       DNSNAME         16      pdimx.cisco.com
3       SUBJECTNAME     90      CN=CUCM105PUB.pdimx.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:25:61:8D:75:4E:91:73:2E:82:00:00:00:00:00:25
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1572    CD 2D 6E AC B3 BA 0F E4 33 CB EA D1 F2 1A 6C D6 76 78 BB 07 (SHA1 Hash HEX)

The ITL file was verified successfully.

11.x cluster this one WAS migrated from the above 9.1 cluster

admin:show itl
The checksum value of the ITL file:
47732e5682fd8b00f3f65f1857293932(MD5)
58250130fc999d0fc5c1a59e8774222bbcce840a(SHA1)


The checksum value of the Extended ITL File with EC entries:
c9beb0845118beaa992cc17df02b3fc1(MD5)
b2cc54904287a9936ac06ef375ab635071864e1f(SHA1)


===============================================================================================
Showing Regular ITL File.
===============================================================================================
Length of ITL file: 8493
The ITL File was last modified on Thu Feb 11 11:39:47 CST 2016

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   320 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       133
4       SIGNERNAME      93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
5       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
6       CANAME          12      CN=pdimx-CA
7       SIGNATUREINFO   2       15
8       DIGESTALGORTITHM        1
9       SIGNATUREALGOINFO       2       8
10      SIGNATUREALGORTITHM     1
11      SIGNATUREMODULUS        1
12      SIGNATURE       128
                9  3c  c6  ab  4d  fc  97  27
                60  95  f3  fe  1a  4  87  c3
                d4  f7  e1  ec  fa  5c  15  8d
                a2  11  a3  30  a7  da  c2  c2
                26  b3  6e  74  73  cd  20  b2
                ba  2b  70  64  56  88  69  8
                ec  70  43  e6  e8  bf  8c  60
                9f  9c  33  c  b5  f9  3b  b7
                31  26  f7  f1  d7  a8  97  d5
                f4  cf  53  21  97  27  1b  2c
                f9  38  2f  8f  b1  bd  a  a8
                bb  d1  b4  7f  ff  73  36  98
                92  ab  9e  4d  3d  d5  b1  96
                dd  2f  d1  75  20  de  c0  f3
                4f  49  56  5d  44  50  d5  98
                7  77  64  22  e5  fb  1  45
14      FILENAME        12
15      TIMESTAMP       4

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       561
2       DNSNAME         2
3       SUBJECTNAME     77      CN=CAPF-82b79a6d;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       CAPF
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2F:66:BF:E0:48:FE:DD:59:79:00:00:00:00:00:2F
7       PUBLICKEY       140
8       SIGNATURE       256
11      CERTHASH        20      4D 34 EF EE 0A 69 B2 C2 80 8E 1F B8 44 8A 30 B0 A1 DE A2 7D
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       707
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TVS
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2E:89:08:E4:F0:7D:83:2D:8F:00:00:00:00:00:2E
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      8C 43 B1 6E 27 92 BF 6D F8 27 0E 36 B0 A4 1A BA FE BE 41 9E
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1818
2       DNSNAME         2
3       SUBJECTNAME     105     CN=ITLRECOVERY_cucm91pub.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      105     CN=ITLRECOVERY_cucm91pub.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
6       SERIALNUMBER    16      7D:69:1D:44:6A:CD:FB:15:9C:E0:82:5A:D6:15:60:26
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1033    FB B5 80 3F E6 BF CD 35 44 BF 86 98 D4 D7 30 E9 1C 5A 7A E5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

        ITL Record #:5
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)

        ITL Record #:6
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1207
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
6       SERIALNUMBER    16      7B:57:DB:C5:F6:D9:91:37:4F:B4:2B:F9:9A:2E:25:94
7       PUBLICKEY       140
8       SIGNATURE       128
9       CERTIFICATE     704     47 23 F8 F0 8F 0B C4 B9 45 90 4F 5C 92 F8 54 D4 28 FF 2F D5 (SHA1 Hash HEX)

The ITL file was verified successfully.

===============================================================================================
Showing Extended ITL File. This file contains EC Certificates
===============================================================================================
Length of ITL file: 9795
The ITL File was last modified on Thu Feb 11 11:39:47 CST 2016

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   320 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       133
4       SIGNERNAME      93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
5       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
6       CANAME          12      CN=pdimx-CA
7       SIGNATUREINFO   2       15
8       DIGESTALGORTITHM        1
9       SIGNATUREALGOINFO       2       8
10      SIGNATUREALGORTITHM     1
11      SIGNATUREMODULUS        1
12      SIGNATURE       128
                9f  d4  59  75  f  3e  97  90
                25  c0  78  44  2e  e5  5a  eb
                fc  24  93  d  8a  b8  c6  6e
                73  8d  e6  6d  4f  55  fe  64
                9  f9  23  f3  41  8f  3e  9a
                7c  b7  45  2a  26  a9  e4  eb
                a1  e4  3b  7c  da  ba  bf  31
                a5  74  97  d  73  6d  fc  f7
                39  7b  b6  69  f5  af  5a  63
                a3  6f  a8  10  8b  38  84  91
                e5  e1  f4  7c  36  a1  7f  50
                ac  ea  c6  3c  53  de  5a  54
                4a  6c  a7  48  b5  ed  7d  8b
                ec  96  d8  9b  47  d5  2b  d0
                41  87  7  7  7c  5d  a0  78
                c3  16  8a  9d  8e  38  46  52
14      FILENAME        12
15      TIMESTAMP       4

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1863
2       DNSNAME         2
3       SUBJECTNAME     77      CN=CAPF-82b79a6d;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       CAPF
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2F:66:BF:E0:48:FE:DD:59:79:00:00:00:00:00:2F
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1326    4D 34 EF EE 0A 69 B2 C2 80 8E 1F B8 44 8A 30 B0 A1 DE A2 7D (SHA1 Hash HEX)

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       707
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TVS
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:2E:89:08:E4:F0:7D:83:2D:8F:00:00:00:00:00:2E
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      8C 43 B1 6E 27 92 BF 6D F8 27 0E 36 B0 A4 1A BA FE BE 41 9E
12      HASH ALGORITHM  1       SHA-1

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1818
2       DNSNAME         2
3       SUBJECTNAME     105     CN=ITLRECOVERY_cucm91pub.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      105     CN=ITLRECOVERY_cucm91pub.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
6       SERIALNUMBER    16      7D:69:1D:44:6A:CD:FB:15:9C:E0:82:5A:D6:15:60:26
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1033    FB B5 80 3F E6 BF CD 35 44 BF 86 98 D4 D7 30 E9 1C 5A 7A E5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

        ITL Record #:5
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1940
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      12      CN=pdimx-CA
6       SERIALNUMBER    19      77:00:00:00:30:BF:24:48:95:83:E1:77:33:00:00:00:00:00:30
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1387    24 E0 F2 EE 7B CC F2 FD 31 C6 C0 0F B3 A4 E7 4B AC 66 60 C8 (SHA1 Hash HEX)

        ITL Record #:6
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1207
2       DNSNAME         2
3       SUBJECTNAME     93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
4       FUNCTION        2       TFTP
5       ISSUERNAME      93      CN=CUCM91PUB.gspmexlab.cisco.com;OU=PDI MX;O=Cisco Systems;L=Mexico City;ST=Mexico City;C=MX
6       SERIALNUMBER    16      7B:57:DB:C5:F6:D9:91:37:4F:B4:2B:F9:9A:2E:25:94
7       PUBLICKEY       140
8       SIGNATURE       128
9       CERTIFICATE     704     47 23 F8 F0 8F 0B C4 B9 45 90 4F 5C 92 F8 54 D4 28 FF 2F D5 (SHA1 Hash HEX)

The ITL file was verified successfully.

As you can see, the number of certificates that is used to compose the ITL has changed in between versions, from 4 certs in 9.1, to 5 certs in 10.5, and finally to 6 certs in 11.x.
What does this mean??
That even if the migration manages to transfer your certs from a previous version, as the ITL now requires another cert(s) to be composed, it's going to change. This means that you should still try follow any of the alternatives from How can I bulk remove ITL / CTL files from phones??

In theory, this should be transparent, only if both versions use the same certs to compose the ITL files, as the number of certs is different in all the above, this cannot be tested.

Back to Unified Communications FAQ

Contact:
Any comments, questions, suggestions, contributions, etc. please send them to javalenc@cisco.com. Please make sure the subject is formatted "UC FAQ <anything else>" as I'll have rules in my mail to match them, otherwise, they'll end up in my spam folder.

Rating: 5.0/5 (16 votes cast)

Personal tools