Cisco Support Community

CUCM Uploading CCMAdmin Web GUI Certificates


    1.  Verify Hostname and Settings


    Certificates are based on names. Make sure the names are correct before starting.


    From SSH CLI
    admin: show web-security
    Subject: CN=CUCM7-PUB.bbbburns.lab, OU=TAC, O=Cisco, L=RTP, ST=North Carolina, C=US
    X509v3 Subject Alternative Name:
                DNS:CUCM7-PUB.bbbburns.lab, DNS:CUCM7-Pub


    Use CLI to change these settings if desired
        In the next example we move to BXB, and set an Alternate name of “ThePub” so we can type that into our browser
    admin: set web-security TAC Cisco BXB Massachusetts US ThePub


    After running "set web-security" Tomcat must be restarted for the new certificate to be used when accessing CCMAdmin and CCMUser.


    admin: utils service restart Cisco Tomcat

    2.  Generate and Download CSR

    OS Admin > Security > Certificate Management > tomcat.pem > Generate CSR
    Download CSR (CUCM7-Pub.csr)




    Note: Prior to CUCM 8.0(3), these Tomcat CSRs were generated with 1024 bit RSA keys. With the resolution of defect


    CSCso62711 Cert Manager should generates Tomcat CSR using RSA 2048 instead of 1024


    CUCM in versions 8.0(3) and later will generate a 2048 bit key / CSR for Tomcat. This defect currently only addresses Tomcat in 8.0(3). Other types of CSRs (like CallManager) will be addressed in future versions. Follow defect CSCtn01236 for 2048 bit updates.

    3.  Submit CSR to CA


    Open the CSR file downloaded from the previous step (CUCM7-Pub.csr in this example) in Notepad and copy the entire contents including the ---BEGIN CERTIFICATE REQUEST--- and ---END CERTIFICATE REQUEST-- lines.


    If your CA is Windows 2k3
    https://<CA Server Name: In my example JASBURNS-AD>/certsrv > Advanced Certificate Request


    Paste the contents into this window to submit the request.



    4.  CA Approves CSR


    This is where the magic happens.
    The CA inspects the CSR and determines if the person submitting the CSR really owns CUCM7-PUB.bbbburns.lab
    With Verisign or GoDaddy this step will require payment, and email or maybe even human verification




    5.  Server Admin Downloads Issued Cert

    With Win2k3 go to CA MMC > Issued Certificates > Copy to file > Base-64 > (CUCM7-Pub.bbbburns.lab.cer)



    6.  Server Admin downloads CA Cert


    The Server Admin must build a complete chain of certs, so needs to download the root CA cert
    https://<CA Server Name: In my example JASBURNS-AD>/certsrv > Download CA Cert > Base-64 > (jasburns-ad_PEM.cer)




    7. Server Admin Uploads Root Certificate(s) as tomcat-trust


    CUCM Server needs to have all certificates in the chain uploaded, starting at the top (root).




    Note that the name of the file uploaded is jasburns-ad_PEM.cer. This is a Base64 encoded PEM file. Once it gets uploaded to CUCM though it will show up with filename JASBURNS-AD.pem. CUCM changes the name of the file to <SUBJECT CN>.pem.


    7b.  Uploading an intermediate certificate

    This step is only necessary if the Certficate Authority (CA) has provided a signed certificate with multiple certificates in the certificate chain as shown.

    multi-tier cert.png

    After uploading the root certificate in Step 7, export the intermedia certificate and upload it as a Tomcat-trust also while specifying the filename (minus the extension) of the root certificate in the "Root Certificate" field.


    multi-tier cert2.png


    If there are more intermediate certificates in the chain, each one will need to be uploaded in order until finally uploading the signed certificate as shown in Step 8.


    The purpose here is to build a chain of certificates. We upload the root certificate and leave the root cert field blank. When we upload the 1st intermediate certificate we put the file name of the root certificate in the root cert field. If there is 2nd intermediate, we put the name of the 1st intermediate in the root cert field. This builds the chain of trust that can be followed from the identity certificate to the root certificate.

    8.  Server Admin Uploads Identity Certificate as tomcat


    This is the identity certificate issued by the CA.
    Complete the cert chain by specifying .pem root cert. Note that the name below is JASBURNS-AD.pem. That's because I went to the OS Admin Certificate page to get the name of the newly uploaded tomcat-trust certificate from the last step. This is VERY important.




    The root certificate you specify here could be the name of the root cert, or the name of some intermediate cert. The purpose is to find the certificate that signed the identity certificate, and use that certificate file name in this root cert field.


    9.  Restart Tomcat

    This one is pretty simple. Just restart Tomcat from the SSH CLI


    admin: utils service restart Cisco Tomcat


    When Tomcat comes back up you can access the CCMAdmin or CCMUser GUI to verify your newly added certificates in use.

    Community Member

    As far as I can see I have followed this exact procedure on CUCM 7.1.3(b) but after restarting the Tomcat service the original self-signed cert is still in use. I can see the new cert and root cert in the list but it is just not in use.

    Am I missing something, is there anything else I can check?


    Cisco Employee

    If you have modified any details using 'Set Web-security ..' make sure you regenerate tomcat certificate before generating CSR.

    It can be done going to CLI

    'set cert regen tomcat'

    or GUI,

    OS Admin > Security > Certificate Management > Generate New >Tomcat

    Rest details remains same.

    Good document, informative !

    Community Member

    Excellent document! It might be useful to summarize how to test the newly added CERT's. Typically its by browsing to the Fully Qualified Domain Name (FQDN) and not the ip address or hostname!

    Also not sure if its worth mentioning that usually the chain of cert's from CA required will be in the DER encoded binary X.509 format.

    Community Member

    Can CUCM support wildcard certificates using these same procedural steps?

    CUCM does not currently support wildcard certificates.  There is an enhancement request opened for it,


    Community Member


    I following this link.

    I need to do for SIP TLS between CUCM and UM Exchange. what is diferent in the procedure?. If you  know at leat one question please tell me any thing is help.

    1) what is the service i need to restart?

    2) in step 5 and 6 I dont know if is base 64 or DER?.

    3) I think the step 7 we need to choose "certificate name = calmanger-trust"

    4) I think the step 7 we need to choose "certificate name = calmanger"

    thanks very much.


    The procedure is very similar and uses the same basic concepts.

    1. You need to restart the CallManager service after completing all of the steps.

    2.  Open the certificate file with notepad.exe. If you can read the "begin  certificate" and "end certificate" lines you have a base64 PEM file. If  the file is just binary special characters then you probably have a DER  encoded file. Note that if you have a pkcs7 or pkcs12 file then you need  to follow a different procedure to extract the individual certs from  the file and save them as base64 PEM files. You can tell if you have the  pkcs7 or 12 files because they will end with a file extension  containing, 7, 12, of pfx.

    3. Yes.

    4. Correct.

    Community Member


    I'm tring to upload certificate to Unity Connection 8.6(2a)SU1

    Tried to follow the steps above, problem is that there is no Roote Cetrificate field under Certificate  management > Upload Certificate / Certificate chain??

    Any idea?

    Community Member

    Hi Jason,

    One of my client's CA root certitficate has expired, you can see the same in the screenshot.

    I understand that we will have to regenrate the certitifcate and get it signed from CA and then upload it the CUCM box.

    What I am trying to understand is what is the significance of these certificates and what will happen if I keep ignoring the expired certitifcate and do not regenrate it.

    What impact does the exipred certitifcate has on producation envirenment?

    Certificate was valid from: 8/10/2007 till 8/8/2012.

    Please explain.

    CUCM Certificate Issue.JPG



    Functionally there is no impact of this expired certificate. The session is still HTTPS / SSL encrypted. The only problem is that you will keep getting that warning, and might not notice if a REAL warning shows up about the site's authenticity.

    Hope this helps!


    Community Member

    Am I correct in saying that there is no impact to phones when changing certs?

    Thank you


    You can change the Tomcat certificate with no impact to the phones.

    This gets a little more complicated if you're using CUCM 8.X and above. You can still change the Tomcat certificate with no problem, but you have to make sure you restart TVS and TFTP afterward because the new HTTPS and TVS services are going to rely on the Tomcat certificate when the phone goes to a secure service URL.

    If you start talking about changing certs OTHER than Tomcat I'd recommend caution and searching for my other document on Security By Default.

    Community Member

    Hi Jason

    As indicated by tdudas, there is no option to specify Root Certificate field in the Upload window.

    Can we just upload the 3 certificates the same way, without specifying the root certificate? Or is the procedure different for CUCM 8.X? It's not explained in details in the OS Admin Guide.

    You said that TFTP and TVS should be restarted as well for the Secure Service URL. I suppose that means that we have to add the hostnames/fqdn of external servers or load balancers which are used for CUCM services to the certificates?

    Also, if the cluster is in secure mode, does this mean we have to update the CTL with the new tomcat certificates?




    In later versions the root certificate field has been removed.   Perform the procedure the same way without specifying a root certificate, the CUCM will 'detect' which is the appropriate root certificate.

    For 7.x and earlier mixed mode clusters, the phones will still use HTTP so they do not need to validate any HTTPS certs.

    For 8.x and later clusters, phones which support SBD will validate the HTTPS cert by way of TVS, so the CTL Client does not need to be rerun.   Jason's other doc covers this in some depth:



    Community Member


    CUCM 10

    We are using 3rd party CA and we can only create 1 certificate per subject

    I created CSR, generated a certificate and installed it for tomcat service as well as root cetificate for tomcat-trust. Everything working fine for that service.

    I added root cetificate from our CA provider to Callmanager-trust

    Can I somehow export existing certificate with private key from tomcat service and re-use it for CallManager service or any other service on the server?  



    Community Member

    In your example you show a cert with multiple alternative names, however the set web-security command won't accept multiple alternative names -- or perhaps I don't know what the correct syntax is.  I tried commas, quotes, and various combinations.  What I'd like is a FQDN for the cert such as, an alternate name of (which via DNS would resolve to any server in the cluster), and a "friendly" name such as CALLMANAGER (without the domain name).  To do this I need to be able to enter two Alternate Names however as I said the CLI on my 8.5 system does not seem to allow it, nor do the docs say it can be done.  But your example above seems to indicate it is possible:

    admin: show web-security
    Subject: CN=CUCM7-PUB.bbbburns.lab, OU=TAC, O=Cisco, L=RTP, ST=North Carolina, C=US
    X509v3 Subject Alternative Name:
                DNS:CUCM7-PUB.bbbburns.lab, DNS:CUCM7-Pub

    Community Member

    CUCM 10.5

    When I generate CSR , there is a field there called Domain name and usually shows the

    I was told that in 10.5 this is needed as in this version, the pub propagates the certs to all the other servers in the cluster.

    Also, in the CSR generation, I choose CallManager.  My goal is to encrypt the call. Am I missing something?  thanks

    Community Member

    I'm interested in doing this too on CUCM 10.1.  I'd like to have 3 SANs.  I cannot find a way of doing this via the CLI.

    Any suggestions?

    In 10.x, specifying a SAN  has changed a bit.  You can now specify multiple SAN's when generating the CSR from the OS Admin page.


    Community Member

    I think it's specifically 10.5 onwards as I cannot see an option in 10.0 to have multiple SANs.

    Correct.  Prior to 10.5, you'll only be able to set a single SAN -- with the CLI. 

    Community Member

    Thank you very much for this procedure.

    I wish I had this file back in September when I was first attempting to install certificates.  This made it relatively painless.  Can you do one for CUPS (IM & Presence) as they have 2 certs one for Tomcat and one for XMPP?

    Also with CUCM9 adding the intermediate certificate does not require to point back to the root certificate.

    Community Member

    Hi All,

    I'm conscious that im replying to a 4 year + old post, However believe people still use this information as its a good guide to follow when executing CCMAdmin Tomcat Certs.

    So my issue.

    I recently renewed my certificate by basically generating a new CSR and having them signed. Uploaded in the normal fashion and restarted the Tomcat Service..... All good for another couple of years.

    However I'm still getting these RTMT alerts (Below) any idea how to make them stop?

    Been getting them for

    (I've replaced the CUCM Name with XXXXXX)


    SeverityMatch : Critical
    MatchedEvent : Mar  5 00:00:07 XXXXXX local7 2 : 207: XXXXXX : Mar 05 2015 00:00:07.473 UTC :  %UC_CERT-2-CertValidfor7days: %[Message=Certificate expiration Notification. Certificate name:XXXXXX.der Unit:tomcat-trust Type:own-cert Expira][AppID=Cisco Certificate Monitor][ClusterID=][NodeID=XXXXXX]: Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent ClusterID : 
    NodeID : XXXXXX
     TimeStamp : Thu Mar 05 00:00:07 GMT 2015


    Any assistance will be great.



    Hi Jon,

    This is the remaining tomcat-trust cert automatically propagated from your previous certificate.   To effectively remove this you will need to stop the Certificate Notification Service on all nodes from the Unified Serviceability page, delete the cert from the OS Admin page on every node, then start the service back up.


    Community Member

    Hi all,


    thanks for posting that guide.

    One question, is it the same logic if I woul like to use CA Trusted Callmanager certs ?




    Community Member

    I have expired certs that are no longer being used so is it safe to delete all certs in the cahin without reprecutions after stopping the services noted and do I need to restart tomcat?

    i.e. CallManager-trust Type:own-cert

    Unit:tomcat-trust Type:own-cert

    Message=Certificate expiration Notification. Certificate name:servername.der Unit:tomcat-trust Type:own-cert Expiration:Wed Nov 4 16:09][AppID=Cisco Certificate Monitor][ClusterID=][NodeID=servername]:

    SeverityMatch : Critical
    MatchedEvent : Nov 2 18:00:09 servername local7 2 : 73: servername.domain: Nov 03 2015 00:00:09.842 UTC : %UC_CERT-2-CertValidfor7days: %[Message=Certificate expiration Notification. Certificate name:CAPF-700d51b4.der Unit:CallManager-trust Type:own-cert Expiration:Wed Nov 4][AppID=Cisco Certificate Monitor][ClusterID=][NodeID=servername]: Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent ClusterID :
    NodeID : servername
    TimeStamp : Mon Nov 02 18:00:10 CST 2015

    SeverityMatch : Critical
    MatchedEvent : Nov 2 18:00:09 servername local7 2 : 74: servername.domain: Nov 03 2015 00:00:09.844 UTC : %UC_CERT-2-CertValidfor7days: %[Message=Certificate expiration Notification. Certificate name:servername.der Unit:CallManager-trust Type:own-cert Expiration:Wed Nov 4 ][AppID=Cisco Certificate Monitor][ClusterID=][NodeID=servername]: Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent ClusterID :
    NodeID : servername
    TimeStamp : Mon Nov 02 18:00:11 CST 2015

    SeverityMatch : Critical
    MatchedEvent : Nov 2 18:00:09 servername local7 2 : 75: servername.domain: Nov 03 2015 00:00:09.846 UTC : %UC_CERT-2-CertValidfor7days: %[Message=Certificate expiration Notification. Certificate name:publisher.der Unit:CallManager-trust Type:own-cert Expiration:Wed Nov 4 ][AppID=Cisco Certificate Monitor][ClusterID=][NodeID=servername]: Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent ClusterID :
    NodeID : servername
    TimeStamp : Mon Nov 02 18:00:12 CST 2015

    Community Member

    QUALITY POST:   ONLY issues I have with it is that there isn't direct specification of process with reguards to Unity and IM/P.

    I'm dealing with a 9.1.2 environment:  and I'm checking my self against this and TAC to confirm.

    SHOULD Subs'  certs be imported through the Pub,  or on the CM Sub directly?

    You have to import the CUC cert chain on the CUC directly...(in 9).

    I see the date here : so I know I'm late to the party on this conversation.

    I note changes from 7 to 8 in this specific arena.

    I'd LIKE to see a follow up / repost of the above with a brief run down of major diff from 7, 8, 9, 10 and 11 so that this one doc could be a one-stop-shop answer for the whole of the process.

    Community Member

    These procedures worked in version 6,7 and 8 ... we recently upgraded to version 10.5, and they no longer work.

    how do you down load the new CSR after it is generated?  the icon to "download CSR" no longer appears.

    If I understand correctly,  we no longer have to have to do this for all the servers in the cluster ... how is it done now ?



    Community Member

    Hi Jose,

    Just a quick one did you find solution for version 10.5? If yes, can you please share it with us. Currently I am updating all our certificates. We are using CA LSC CAPF. Can you please advice if your outcome is any different?

    Another question, When you upload the certificates to CUCM do you need to also upload it in subscriber or is it just Pub. Reason for this question is I downloaded 5 CSR certificates from each server.

    Please Advice


    Cisco Employee

    The button to download a CSR is there in 10.5 just as it is shown in the screenshots above.

    If you are using a CA to sign endpoint LSC certificates then you have to get the CSRs from the CLI. Follow the steps in the UCM Security Guide

    For your second question Trust certs are propagated to the entire cluster by the Cisco Certificate Change Notification service. Multi-server certificates are only uploaded to the publisher. Single-server identity certs must be uploaded to the server that generated the CSR.

    Community Member

    Hi Phillip,

    Thanks for the quick respond "Much Appreciated"

    In a nutshell,

    If you upload Tomcat.pem CAPF.pem CallManager.pem and TVS.pem in CUCM pub that will be propagated to the rest of Subscribers? Am right here? No need to upload Sub certificates in Sub CUCM. Remember every each CUCM server got unique certificates.

    As for CAPF LSC this will be signed locally using Microsoft windows. So the only way to upload is by CLI? 

    Last one my customer wants SHA2 and as you know SHA1 is only supported in ver 9.1.x, where SHA2 is supported in 10.5. What advice are you giving me in terms of upgrade. Do you think I should do the upgrade first then follow it up with certificate? Currently I am running 9.1.X

    Please advice,

    Many Thanks 

    Cisco Employee

    The identity certs you upload for the publisher will be propagated to the subs as trust certs. The intermediate and root certs you upload (as trust certs) to the pub will also be distributed to the subs as well. You will know if this isn't the case when you try to upload the sub's signed cert and it fails because the root cert isn't present.

    For LSCs as the document indicates you set the CAPF service parameter to external then tell all your phones to install/update an LSC. You use the CLI on the publisher to get a list and download the CSRs, they will not appear anywhere in Certificate Management.

    With regards to SHA2 if that's a requirement you must upgrade or you will just have to generate your certs again.  One thing to consider with 10.5 is the multi-server certificates, particularly for Tomcat. This will make your life much easier since all the nodes in the cluster share the same certificate.

    When going to 10.5 make sure you are on the latest SU available before doing anything with multi-server certificates. 

    Finally, be prepared for several things to happen when uploading new certs. For starters your phones will reset on each cert change. This is done so the phones will get an updated ITL. Next in later versions you will have to wait 5 mins between uploading different certs. This is so the phones that got reset with the last cert you uploaded have a chance to all get their new ITL. 

    If you are going to CA-sign all of your UCM certs then make sure you do them one server at a time, and verify all the phones come back and have updated ITLs before you move to the next server.

    Community Member

    Hi Phillip,

    Can you please break it down since I am not an expert in Certificates. When you say Identity cert how does it look like? Intermediate and Root Cert as well? There are many cert on my CUCM server, can you give me an example on each one of them. As far I know Cisco says I need to worry about are the following;

    Tomcat.pem CAPF.pem CallManager.pem and TVS.pem

    Add them as trusted. 

    LSC CAPF will be signed by third-party Microsoft CA and will be uploaded part of the above certificates CAPF.pem. I will be using IEEE802.1X as method of Authentication through Cisco ISE. Also please remember we are currently using CUCM, CUC, UXXC, and IMP version 9.1X. Signed certificate will it be the same upload as CUC, UCCX and IMP.

    IMP >>> CUP.pem IPSec.pem, Tomcat.pem I generated CSR for each one of them

    CUC >>> Tomcat.pem IPSec.pem  generated CSR for each one of them

    UCCX >> Tomcat.pem IPSec.pem  generated CSR for each one of them and will be giving them all to CA to sign it.

    When you say do it server by server you mean the following 


    Tomcat.pem tomcat-trusted CAPF.pem capf-trusted CallManager.pem CallManager-trusted ipsec-trusted and TVS.pem tvs-trusted

    3X Sub-Upload

    Tomcat.pem tomcat-trusted CAPF.pem capf-trusted CallManager.pem CallManager-trusted ipsec-trusted and TVS.pem tvs-trusted

    Please correct me if I am going the wrong direction. 

    You help and knowledge would be appreciated,

    Thanks Phillip

    Community Member

    Hi Phillip, would you say that deleting "phone-SAST-trust" certs would also trigger a cluster-wide phone reboot? If yes, can you give a quick explanation of why?

    I started deleting a bunch of them and all the phones rebooted but there was also a number of service crashes and core dumps generated so I'm not sure if the phone reboots were because of the cert deletion or the server crash.

    Thanks in advance!

    Cisco Employee

    Anything that is in an ITL should trigger phone resets. I just tested in and when I deleted a remote cluster's phone-sast-trust cert it did not trigger any phone resets.

    If your ccm service cored then yes your phones (registered to that node) would have been reset.

    Community Member

    You mentioned you deleted the remote cluster's phone-sast-trust cert...what about if you delete all of the phone-sast-trust certs including the ones pointing to nodes within the cluster you're deleting from? Also, I only got a ccm core on the TFTP server with no phones registered to it (yes ccm was running on the TFTP server even though best practices say not to run ccm on the TFTP server).

    Thoughts? And many thanks for responding so quickly... I have a problem management meeting tomorrow where I will be grilled on this incident :)

    Cisco Employee

    To quickly define the terms an identity cert is the cert used by the local CUCM/CUC/UCCX service for TLS connections. CallManager.pem, Tomcat.pem, etc are all identity certs.

    Intermediate and Root certs the certs that "issue" (sign) other certs. In your workflow they come from your CA and you have to upload them as trust certs BEFORE the CA-signed cert from your CSR can be uploaded. 

    If you are having the same CA sign a CallManager cert on a 4-node cluster you would upload (in this order):

    Pub: CallManager-Trust (root), CallManager-Trust (intermediate), CallManager.pem (for pub)

    Sub1-3: CallManager.pem (for the local server).

    For a multi-server cert you upload everything only on the pub. 

    I hope this clarifies things for you.

    Cisco Employee

    Were those old certs you were deleting or the current ones? The phone-sast-trust certs are there for TVS to validate ITL files signed by those certs, so you shouldn't really be deleting them. 

    If you did happen to delete one of the active certs from a subscriber (the cert will have the same serial number as an active CallManager-trust) then yes it very well could cause phones to reset. Those certs aren't in the ITL until UCM 11.0 

    I'd recommend you download all your CallManager-Trust certs for subs and re-upload them as phone-SAST-trust and figure out a plan going forward.

    Community Member

    Hi Philip,

    This was on a 9.1(2) cluster with 8 nodes. I got through deleting all the phone-sast-trust certs on the pub and was starting on the TFTP server when a bunch of people started mentioning the phones I stopped deleting them. They are the current and valid certs.

    When I turned the Cisco Cert Change Notification service back on they were all restored on the pub and TFTP server and another core happened and phones rebooted again.

    I was under the impression that they were related to EMCC and we recently consolidated clusters so didn't need that feature anymore. Am I safe to at least delete phone-sast-trust certs from decommissioned remote clusters without a phone reboot?

    Needless to say, I won't be deleting any more of these until I know for sure :)

    Cisco Employee

    Those certs are used by TVS to validate files and TLS connections from phones that encounter them and don't have the cert in an ITL or CTL. They are used in EMCC but also could be used just by a phone failing over to a backup TFTP server before 11.0.

    I'm not surprised at all the phones reset because you changed a cert that is involved in the Security By Default feature. I still can't get phones to reset on my 10.5 cluster even by deleting the local server's phone-SAST-trust cert. It's likely this is behavior that's changed since 9.1.2.

    The ccm process should not have cored, and you could open a TAC case to get a defect for it. 

    Community Member

    Hi Phillip,

    Thanks for taking the time and sharing your knowledge with me. This has really helped me now. 

    To break it down and to illustrate that I have understood you fully.

    CallManager, Tomcat, IPSec, TVS and CAPF.pem All are identity certificate. These all certficates needs to be uploaded in all CUCM nodes Pub first and then Sub 1-3.

    CallManager-Trust (root) is uploaded in CUCM Pub first then Sub 1-3 as Trust from cisco dialog box. This also includes Tomcat-trust, TVS-trust, IPSec-trust and CAPF-trust. Upload them on all nodes in the order you've mentioned. 

    Intermediate CallManager, Tomcat, IPSec, CAPF and TVS certificate all will be uploaded as Trust; only upload if (CA) has provided a signed certificate with multiple certificates in the certificate chain. DO I NEED TO UPLOAD THEM IN ALL NODES? Pub >>>> Sub1 >>>> Sub2,3.

    Where does the application certificate fit then?

    On Cisco Web is say >>>> you must obtain both the signed application certificate and the CA root certificate from the CA. 

    Last question does the procedure apply to CUC, UCCX, IMP.

    Thanks for taking time to read this. 

    Cisco Employee

    In the text you quoted the term application certificate is the same thing as an identity certificate. 

    Yes this procedure does apply for CUC, UCCX, and IMP as they all share the same platform. I can't guarantee that UCCX or CUC will share trust certs among multiple servers though. You will want to validate that for yourself.

    Community Member

    Hi Phillip,

    I hope you doing well,

    Just to update you from our last conversation we had. I have uploaded the certificate on our lab before we take it to the production.


    >>I have truned ITL to TRUE from Enterprise Parameter >> Save & Apply >> Reset

    >>Uploaded new certificate and it went fine with no issues

    >>I used CTL eToken to validate my certificate that also came back with pass

    Cisco says in their documents that I need to restart TFTP and then reload ALL CUCM nodes if I am using CTL eToken. What are they talking about here!! If I reload the CUCM it means TFTP, CTL Provider, TV, Tomcat and the rest will restart by doing this way.

    Cisco Doc

    The recommended procedure is to restart all TFTP servers, followed by all servers running the CallManager process. Restarting the TFTP servers allows the TFTP process to load in the newly generated CTLFile.tlv. Restarting the nodes running CallManager causes the phones to reset and download the new CTL file from the configured TFTP server. admin:utils system restart

    Do you really want to restart ? Enter (yes/no)?

    I did follow it as it says in their document, but however once the CUCM came back , on the screen of the phone it says Registering, without full registered.

    If you soft reset the phones do pickup the new CTL/CAPF files. Remember I am dealing with 5000 phones on the customer site and of course this is not possible to do soft rest on all 5000 phones.

    Can you please advise me if I am doing something wrong here?

    I hope to hear from you soon;

    Community Member

    Hi Phillip and All,

    I would like to ask regarding the downloading and uploading of certificate for CUCM and CUC. If we have 5 CUCM nodes (1 CUCM Pub and 4 CUCM Sub), do we need to download the certificate for every nodes and give them to the authority/person who will sign the certificates? Then we just need to follow the procedures from below link? 

    This procedures is also applicable to CUC, right?

    Another question is that, is it ok to upload the certificate with different name? Or this will be automatically change by the cucm? When we downloaded the CSR, the filename is tomcat.csr and we already them to the person to signed them. Then, they provided to us this cer files below:

    Lastly, if the cer file are not correct or they are were not properly uploaded, what are the impact or effect of this on the CUCM operation?

    Thank you so much guys,


    Community Member

    Hi Jason,

    I followed the above procedure and have some query related to same.

    CUCM version is 8.6.2.

    Before generating CSR, I checked show web-security and the CN appeared as below -

    Subject Name: L=Singapore, ST=NA,, OU=APAC, O=companyname, C=SG

    The existing tomcat trust certificate self signed  when checked is giving the CN as below

    Subject Name: L=Singapore, ST=NA, CN=APAC-CUCMP, OU=APAC, O=companyname, C=SG

    I generated CSR and got the CA certificate ,uploaded to CUCM and restarted the Tomcat. 

    I was unable to browse the cucm with https://APAC-CUCMP/ but when done with it works.

    End user browse the ccmuser page with https://APAC-CUCMP/ will changing the CN name in web-security will help. 

    1) Changing the CN will have any effect on  hostname change or licensing, or anything else.

    2) After changing the CN in web-security do I need to again generate CSR and follow the upload of new CA certificate.

    3) DO I need to perform this on every node of CUCM cluster ?

    4) Is this command correct with reference to above - 

    set web-security APAC companyname Singapore NA SG APAC-CUCMP

    5) the default self sign certificate generated in CUCM during installation dose that do not include domain name in CN.


    Community Member

    Hi Great article thanks.

    Quick question/problem if I can. Generated CSR and completed certificate request without issue from our internal CA, we already had the root/Chain on there so no problems there, after uploading the cert to CUCM 10.5 as tomcat trust type it displays and looks valid with a date in the future. However there is a self signed certificate "generated by system" with a expiry date of several years in the future which after restarting the tomcat service assigned itself as the web cert, is there a way to either remove this cert or assign the CA cert to the tomcat service? As a side note after restarting the tomcat service the CA cert is removed from the list as if the CUCM believes its not needed, I can simply re-add it again without a problem, thanks for any help.

    Cisco Employee

    After generating a CSR for tomcat and getting it signed by your CA the resulting certificate should be uploaded as a tomcat certificate, not tomcat-trust. This is how you replace the self-signed certificate generated by the system with the one that corresponds to the CSR you generated.

    The system will validate the certificate you are uploading against the last CSR that was generated so you cannot inadvertently replace the service certificate.

    Community Member

    Thanks for the reply. upon attempting to upload a tomcat only cert I receive the attached error, " certificate verify failed!" any suggestions to get around this?

    Cisco Employee

    GalaRetail,this issue might come if you have more than one intermediate CA server.Make sure that you have single Intermidiate CA server while generating certificate.