03-18-2017 02:42 AM - edited 03-19-2019 12:14 PM
Hi,
Please could someone help shed some light on Jabber certificates for me, it would be massively appreciated? I have a more complex setup than I normally deploy, where there is an existing CUCM/CUC 11.5 cluster, but now the customer has requested Jabber and MRA deployment so I've deployed IMP and Expressway servers that are not currently utilised. As they have no internal CA, all the certificates will need to be signed by an external authority, likely to be DigiCert.
The domain that the CUCM/CUC are on is "company.local", which is there internal domain, no external services.
Jabber is set to use Directory URI, where email addresses are used, which are "company.com" & "company.co.uk".
As company.com and company.co.uk have servers externally so we can't host Expressway DNS records for these on the internal DNS servers for these domains, so I believe this means that I will now have to add a subdomain that can be used on internal and external DNS servers. I was going for "cisco-uc.company.com".
So, assuming there are no holes in the above, please could I have some help with what names and domains that need to be in the signed certificates as I'm trying to minimise costs of the certificate signings?
- Multi-SAN Tomcat (CUCM+CUC) & CallManager certificates
- I understand I need to include all the FQDN names of all the servers.
- Do I need to include the the multisan name in the cert? eg for CUCM cluster - ucmpub-ms.company.local
- Do I need to include a dns name for the parent domain? eg company.local
- For the CUP-XMPP certificates
- I understand I again need the FQDN of the IMP servers
- This is the main part I'm stuck with, what domains do I need to include here? Do I really need to have all domains (.local,.co.uk,.com,cisco-uc.company.com) here as the CSR generated suggests? That makes the certificate stupidly expensive. Also what happens if I more users from another domain are added like "company2.com"?
- For the Expressway Edge
- I understand I need the cluster FQDN and the server FQDNs, along with the "collab-edge.cisco-uc.company.com", could you confirm if this is correct?
Any input on these would be make a huge difference, thanks in advance.
03-18-2017 04:21 PM
Have you already reviewed the MRA configuration guide???
http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html
There is no such thing as a collab-edge.something.com FQDN, the that is an SRV record, not an A record.
I suggest you thoroughly review the MRA guide and the doc I provide above in first place.
the ONLY certificate you want to have signed by a public CA, is the one from EXP-E, all other certs can be self signed, not really recommended, you usually use an internal CA to sign all the other servers to make things easier.
03-20-2017 02:25 AM
Thanks Jaime, as ever your input is always so valuable so appreciate you taking the time to reply. I'm now happy with the clarification on the Expressway certificates.
With regards to the CUCM/CUC/IMP certificates, these all need to be signed and not self-signed otherwise upon loading Jabber the certificate exceptions appear on the screen and I can't allow this to happen. Also the self-signed certs can't be rolled out in group policy in this instance to allow them to work, so signed appears to be the best way unless you can correct me.
If this is the case, would you be able to assist with the mutli-san name requirements, especially for CUP-XMPP?
03-20-2017 07:58 PM
With regards to the CUCM/CUC/IMP certificates, these all need to be signed and not self-signed otherwise upon loading Jabber the certificate exceptions appear on the screen and I can't allow this to happen.
No, that's wrong, Jabber doesn't care who signed the certificate, all Jabber cares, is that the server certs are already in the trust store, to prevent the certificate popup. It can be self-signed, private CA or public CA and Jabber will work with any of them
Also the self-signed certs can't be rolled out in group policy in this instance to allow them to work, so signed appears to be the best way unless you can correct me.
Not a GPO guru, but this seems to hint otherwise.
If the certificate is self-signed, and cannot be traced back to a certificate that is in the Trusted Root Certification Authorities certificate store, then you must also copy the certificate to that store. In the navigation pane, click Trusted Root Certification Authorities, and then repeat steps 5 and 6 to install a copy of the certificate to that store.
https://technet.microsoft.com/en-us/library/cc770315(v=ws.10).aspx
Using a private CA or a public CA facilitates all this, because you don't need to do the exchange of the root CA of every single server, to any other server that needs to trust him.
03-21-2017 03:27 AM
Thanks again, totally agree with what you are saying here. It's the fact that there is no way to get these certificates into the users' trust store on their PC/Phone/Tablet without doing it on each computer individually (due to no GPO or CA on this site), therefore I am having to use trusted certificates that are already there (from Microsoft Windows) for external CAs like Verosign and Digicert. Hence having to go to external signed certs.
I believe I have found the answer I'm looking for elsewhere in that when I create signed certificates I don't need the MultiSAN names in any of the CUCM/CUC/IMP certs and only the server domain, not all the actually Directory URI domains in the CUP-XMPP cert.
03-21-2017 12:38 PM
OK, just to be clear, if you assume that because those server certificates are going to be signed by a public CA, you do not need to distribute them to the end devices, that's wrong. That will just avoid you having to deploy the root CA to them.
And no, you need the FQDN of the server to be in the certificate (look at the self-signed cert), there are no wildcard certificates here, you can only use multi-san. How do you expect the certificate to authenticate each server if you only have the domain?????
And the IM&P certs will already try to add all the domains that server is handling, if you haven't, go to your servers and click on the generate CSR option to see yourself what info they will try to have. (nothing will happen if you click on that option, CSR is only generated once you click Generate in the popup window)
03-19-2017 06:25 PM
If you want to minimise the cost of certificate signing; spin up a CA server.
a single cert is around 150 for 3 years (no alternative names) and a wildcard cert is 650 for 3 years.
so public CA's wont let you use multiple subject alternate names, they will let you submit the CSR with multiple SAN;s but the signed cert will only have the CN.
03-20-2017 02:18 AM
Thanks Dennis, I've floated this one to the customer and it's definitely the best way but unfortunately they wont do the build.
04-19-2017 08:09 AM
hi Dennis,
will the wildcard cert work for Jabber MRA?
Thanks,
K
04-20-2017 05:23 AM
Hi Karen,
Its not supported by Cisco.
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-9/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-9.pdf
excerpt from above.
"Wildcard certificates manage multiple subdomains and the services names they support, they can be less secure than SAN (Subject Alternate Name) certificates. Expressway does not support wildcard certificates."
Regards,
Alok
07-10-2017 04:36 AM
Hi,
did you find an answer to all of your questions ?
I was wondering what the parent domain in the CSR creation from is exactly used for ?
Is this always the presence domain ? Or the SRV lookup domain ? My customer does not want to have a domain domain.local as a SAN in the CA signed certificate, except if it is mandatory.
Regards
Jerome
07-10-2017 05:25 AM
Hi Jerome,
Public certificate authorities, if i am not wrong starting from Nov,2015 has stopped generating any certificates for the domain which are not externally available.
So for e.g. customer domain "domain.local" (Considering its an internal domain), can't be part of any SAN entry under the certificate. You have to use public domain for generating the public CA.
So you left with two options:
1) Use public CA on all the servers, CUCM, Unity, IM&P, Expressway etc
2) Internal CA for all the internal nodes and external CA for Public Facing Expressway-Edge.
Regards,
Alok
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide