The Coming Certificate SAN Nightmare – How it Affects Jabber and Cisco UC

The coming storm is here:

The public CAs are no longer signing certificates with subject alternative names (SAN) for internal server names — (

An excerpt:

An internal name is a domain or IP address that is part of a private network. Common examples of internal names are:

  • Any server name with a non-public domain name suffix. For example, http://www.contoso.local or server1.contoso.internal.
  • NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
  • Any IPv4 address in the RFC 1918 range.
  • Any IPv6 address in the RFC 4193 range.

Why do we care? 

Jabber authenticates TLS encryption using certificates for services from CUCM, CUC, IM&P, etc.   Historically these have typically been deployed with IP addresses only, or internal domains (e.g. domain.local, etc.).  Because of this you can no longer get a certificate for the Expressway-C box that has SANs with IPs or internal names.  Jabber requires valid certificates for login now.

See the Expressway Certificate guide p.7 for Expressway-C here –

Without a certificate with proper SANs, Jabber will either throw an invalid cert error, or will completely deny login to UC services.

Using Collab Edge MRA,  Jabber authenticates to the Expressway-E server and uses it’s certifciate.  Internally Jabber communicates directly with each component.

Dealing with the issue for Collab Edge MRA

Basically we have two options to work around the SAN issue:

1) Change the domain name of the UC components to a valid public domain name that the public CA will sign for.  This doesn’t mean the server has to be accessible from the internet by any means or that it is an existing domain name your company is using.

Option 1a:  Deploy a new public domain name for UC services internally.  For example if your domain name was you might see if or or something similar is available to register and use as the internal UC domain name.  The domain wouldn’t need to resolve externally at all.

If you do this, then you need to take in to consideration that the MRA deployment becomes a multi-domain (or split-domain) deployment which requires some special treatment like the VoiceServicesDomain option.  (See my previous post about multi-domain deployments.)

Configuration example here –

Options 1b:  The seemingly easier deployment would be to just match your public domain name that you use for email (e.g. for your UC components (not suggesting all internal servers — file, print or otherwise, need to be in this domain).  This makes services discovery nice and clean.

The challenge to this method is usually the need to deploy a split DNS for internal and external name resolution.  (The internal DNS server also serving the zone and having the A records for internal services, where the external DNS server have A records for external services.)

2) Create certs using your own internal CA, like Microsoft AD Certificate Services, or OpenSSL, etc.  There are no restrictions on SANs with your own certificate server.  I detail how to use OpenSSL to sign certs in an earlier post.

The major constraint to this deployment option is the need to get the trusted cert from your CA server on to all devices that will use MRA.  AD does it for your Windows machines automatically, but mobile devices will need to have this certificate installed.  Using an MDM like Meraki MDM (freemium service) or others to push the certificates would be the way I’d attempt to deploy the certificates

The Implications of changing the domain name of CUCM/CUC/IM&P

Anyone who’s attempted to change the hostname of a CallManager knows the trainwreck and ensuing TAC calls that will ensue.

I’ve personally not tried to change the domain name of a CallManager or CUC in recent memory, but doing so for IM&P/CUP is relatively straightforward.

The hostname/domain name change procedure is here for CUCM/IM&P –

The name change procedure is here for CUC –

I’d do this with a healthy amount of trepidation.  🙂

9 thoughts on “The Coming Certificate SAN Nightmare – How it Affects Jabber and Cisco UC

  1. A similar problem exists with WebEx Meetings Server, the Admin & IRP servers share a certificate, with the admin server’s host name as a SAN. If you’ve got a private domain internally, then there’s always going to be a SAN that references it & then a public CA won’t issue the certificate.

  2. I remember a client mentioned this to me not too long ago, and shared the same information, since then I’m only using Public valid domains. I have to tell you that changing the Domain on every UC-Collab application is a nightmare and, yes you will need to engage TAC multiple times because every application will do its own thing when re-creating their self-signed certificates after the change.

  3. Changing the domain in CUPS is actually a problem. There’s a bug against this for CUPS 9: CSCuq16135 I hit this and TAC had to remote in and fix the underlying database.

  4. Pingback: A problem we’re going to face here shortly in the Cisco UC world. Time to prepare…The Coming Certificate SAN Nightmare – How it Affects Jabber and Cisco UC | Lewan IT Solutions Technical Blog
  5. Pingback: A problem we’re going to face here shortly in the Cisco UC world. Time to prepare…The Coming Certificate SAN Nightmare – How it Affects Jabber and Cisco UC | Lewan IT Solutions Technical Blog
  6. Mike,

    This is a great post and I think I have hit this issue. I am in the process of building and launching the whole cucm suite of toys. I have requested to have the ‘cup-xmpp’ cert signed by our server guys. When generating the csr our root domain is in the ‘san’. So our server guys strp the ‘san’ out of the csr and then sign the csr and I get a cert for the server. The issue is that when uploading the cert into the server it barks saying the san’s don’t match. Shocker…

    So I have been in a uphill battle with our server guys on why we need the root domain in the san of the cert. All i get is “no its a security issue”

    I have opened a tac case, contacted my SE and my VAR to get help and more documentation on why the root san needs to be there.

    If the field of ‘san’ was editable during the csr generation process of the ‘cup-xmpp’ cert, life would be much easier.

    Can you provide any guidance or advice?


    Michael Voity
    University of Vermont

    • Michael,

      Not sure if you’ve resolved this yet, but I had been experiencing the same thing for CUCM certs. I was getting a SAN mismatch error as well. I think the CSR and Cert upload screens are different among versions, so your situation may be different. I ended up having to generate a CSR with no value in the parent domain field (because it was being added as a SAN) for one CA (Digicert). For another (Go Daddy) I had to add www to the parent domain value in order for the cert and CSR SANs to jive ( Might be slightly different with CUPS too, but thought I’d pass this along.


  7. Hi Mike, FYI your link to Create an AXL user is not valid anymore. Great document though and thanks for the info!

  8. Hi Mike,
    Great post.
    I was looking for official/unofficial response from Cisco regarding this issue but there is silence about it from our local Cisco SE and the support forums.
    Were you able to get any response?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s