Complex Jabber and MRA Certificates

Unanswered Question
Mar 18th, 2017
User Badges:


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 "" & "".

As and 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 "".

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 -

     - 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,,.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 ""?

- For the Expressway Edge

 - I understand I need the cluster FQDN and the server FQDNs, along with the "", could you confirm if this is correct?

Any input on these would be make a huge difference, thanks in advance.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Jaime Valencia Sat, 03/18/2017 - 16:21
User Badges:
  • Cisco Employee,
  • Hall of Fame,


Have you already reviewed the MRA configuration guide???

There is no such thing as a 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.

oharewhy84 Mon, 03/20/2017 - 02:25
User Badges:

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?

Jaime Valencia Mon, 03/20/2017 - 19:58
User Badges:
  • Cisco Employee,
  • Hall of Fame,


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.

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.

oharewhy84 Tue, 03/21/2017 - 03:27
User Badges:

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.

Jaime Valencia Tue, 03/21/2017 - 12:38
User Badges:
  • Cisco Employee,
  • Hall of Fame,


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)

Dennis Mink Sun, 03/19/2017 - 18:25
User Badges:
  • Blue, 1500 points or more

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.

oharewhy84 Mon, 03/20/2017 - 02:18
User Badges:

Thanks Dennis, I've floated this one to the customer and it's definitely the best way but unfortunately they wont do the build.

Alok Jaiswal Thu, 04/20/2017 - 05:23
User Badges:
  • Bronze, 100 points or more

Hi Karen,

Its not supported by Cisco. 

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



Jerome Wintringer Mon, 07/10/2017 - 04:36
User Badges:


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.



Alok Jaiswal Mon, 07/10/2017 - 05:25
User Badges:
  • Bronze, 100 points or more

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.




This Discussion