cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10627
Views
30
Helpful
10
Replies

Problem with third paty certificate

astrohmeier
Level 1
Level 1

Hello,

at my CUCM I want to install a signed certificate. Installing the root ceretificate is no problem. If I install the server certificate I always receive thr error: CSR SAN and Certificate SAN does not match. I can check the certificate for the Subject alternative names but you can I check the csr?

 

Thanks Achim

10 Replies 10

George Thomas
Level 10
Level 10

Does the CSR have an internal domain on it? I have seen instances where the 3rd party CA removes SAN for domains that are not public. 

Please rate useful posts.

Just so someone else has this information, we were on 10.5.1 and there's a bug that even though you update your web-security and add the www. (set web-security ?), the CSR created in the GUI will not show that information. We had to build them in the CLI for them to show properly.

(pro-tip for Go-Daddy certs, when you do web-security, you only need the www. entry, as it automatically does your Server Name. Only areas with spaces like a city name require quotes)

CLI:

set web-security PCI Company "City Name" State Country www.CMSUB1.Company.com

admin:set csr gen tomcat

Successfully Generated CSR for tomcat

admin:set csr gen CallManager

Successfully Generated CSR for CallManager

kennyhoorahaf
Level 1
Level 1

We had this same issue.  Turns out Go Daddy was generating our certificate with a SAN (www.server.domain.com) that wasn't in the csr.  The csr was just generated with server.domain.com.  So this was causing the mismatch.  Go Daddy didn't want to help changing the certificate so we just regenrated the csr on the server using www.server.domain.com as the SAN option.  Note: We are running version 10.5.  I hope this helps.

Thank you!

Your workaround, changing the SAN of the CSR works also on my environment. CUCM and CUPS Version = 10.5.

Thanks,

Ulderico

do you know if go daddy generates the SAN with a www.server.domain.com entry for each server in the SAN record or for just the common name?

I know this is a bit of an old post, but I'm running into this exact issue, and was curious how exactly you went about renerating the CSR with the www.server.domain.com as the SAN option? In the Generate CSR page, it doesn't give many options so I'm not quite clear on how you did this. Thanks

Hi Chris,

  1. Navigate to Cisco Unified OS Administration -> Security -> Certificate Management.
  2. Click Generate CSR
  3. For tomcat cert, select "Multi-server (SAN)" distribution
  4. Optional: I typically change the Common Name to match the FQDN of my Pub (so remove the "-ms" from the Common Name). That would save you 1 SAN in the cert, so if you have a 4-node cluster of 2 CUCMs and 2 CUPS, you can get a single 5-SAN cert to cover all 4 FQDNs and your IM domain name (assuming you have only one). 
  5. To add "www" prefix to the FQDN, just type the domain name under "Other Domains" field (see attached screenshot).

Please note that the above workaround for www-prefixed names in SANs is no longer required for CUCM versions 10.5(2) and above. Hope this helps.

Also, check if the version of your CallManager is 10.5(1.10000.7), as you may hit the bug CSCur46416 (Multiserver Certificate CSR Should Not Check Case Sensitivity in SAN). If that's the case, there is a workaround to change your hostnames to lower case or request an ES from TAC that fixes this bug. 

Richard Simmons
Level 3
Level 3

I've just run into this issue and for me it was because they issued a user certificate and not a server certificate. 

To see the additional options on the Microsoft CA web interface you either need to run your browser as administrator or log on to the CA server and do it from there.

Regards,

Richard

Hi Richard,

That seems to be another issue. The discussion is about third-party certificates (issued by GoDaddy, Comodo, VeriSign, etc.). The bug that I mentioned in my previous post is fixed in version 10.5(2) and later (no need to request ES from TAC).