cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
186690
Views
70
Helpful
50
Comments
Jason Burns
Level 1
Level 1

     

    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)

     

    TomcatCertCSRGenerationDownload.JPG

     

    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.

    CA-CSR-Upload.jpg

     

    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

     

    CA-CSR-ISSUE.jpg

     

    5.  Server Admin Downloads Issued Cert


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

    CA-IdentityCert-Export.jpg

     

    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)

     

    CA-RootCert-Download.jpg

     

    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).

     

    Tomcat-TrustUpload.jpg

     

    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.

     

    tomcat-upload.jpg

     

    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.

    Comments
    Gengad
    Level 1
    Level 1

    Hi Phillip,

    Thanks for the quick respond "Much Appreciated"

    In a nutshell,

    If you upload Tomcat.pem CAPF.pem CallManager.pem IPSec.pm 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 

    Phillip Ratliff
    Cisco Employee
    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.

    Gengad
    Level 1
    Level 1

    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 IPSec.pm 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 

    Pub-Upload

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

    3X Sub-Upload

    Tomcat.pem tomcat-trusted CAPF.pem capf-trusted CallManager.pem CallManager-trusted IPSec.pm 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

    kevin.vines
    Level 1
    Level 1

    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!

    Phillip Ratliff
    Cisco Employee
    Cisco Employee

    Anything that is in an ITL should trigger phone resets. I just tested in 10.5.2.12901-1 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.

    kevin.vines
    Level 1
    Level 1

    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 :)

    Phillip Ratliff
    Cisco Employee
    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.

    Phillip Ratliff
    Cisco Employee
    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.

    kevin.vines
    Level 1
    Level 1

    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 rebooting...so 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 :)

    Phillip Ratliff
    Cisco Employee
    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. 

    Gengad
    Level 1
    Level 1

    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. 

    Phillip Ratliff
    Cisco Employee
    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.

    Gengad
    Level 1
    Level 1

    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.

    Results;

    >>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;

    kiervin.munoz
    Level 1
    Level 1

    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?

    http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-60/112108-sslcert-cucm-00.html 

    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,

    Kier

    geeta.kumari1
    Level 1
    Level 1

    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, CN=APAC-CUCMP.companyname.com, 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 https://APAC-CUCMP.companyname.com 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.

    Regards!!

    Getting Started

    Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: