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