Sole's Blog

Internal server names in publically recognized SSL certificates are about to become just as extinct as Sharks in Chinese waters.

The CA / Browser forum has decided to implement changes to SSL requirements, that will phase out all use of internal server names in public SSL certificates. The CA / Browser forum includes all the major certificate authorities and browser developers, so the change will be forced upon everyone.

The negative impact

It especially hits small to medium businesses with just a few servers. I.e. Exchange, Lync and Small Business Server, where a single SAN certificate including both public and internal server names, will save them both time and resources otherwise needed for reconfiguration, internal PKI solutions and/or reverse proxy and similar systems to allow usage of a separate internal and external SSL certificate on a single website/service.

Exchange 2010 will by default use a single website and configure it self to use its internal FQDN i.e. exchangeserver01.fairssl.local and external FQDN i.e. webmail.fairssl.dk for this one website/SSL certificate. The change will require a change in configuration or systems surrounding the Exchange 2010 environment to continue working without both names in one SSL certificate.

SBS 2011 on the other hand has received the functionality to use split DNS to use the external server name both internally and externally, this not much mentioned change may have something to do with Microsoft being on the CA / Browser forum board, so they would have known about this change for a while.

Larger companies typically have more resources and will have an easier time separating internal and external SSL certificates, without having to buy new solutions like Forefront TMG, SSL offloaders, Internal PKI, etc. But my guess is still that a large number of them will still need to change some configuration to avoid problems with internal server names.

Why?

The reasoning behind this phase out is to secure against Man-in-The-Middle (MTM) attacks, where it is possible to pretend to be an internal server via a publicly recognized SSL certificate. Even thou it is a highly unlikely way to attack most systems, the theoretical possibility is enough to spark the change. I just wish they had been a little more giving on the deadlines.

My personal recommendation to my customers with SSL certificates containing internal server names

• As soon as it is possible, renew all SSL certificates with internal server names, so it expires between 1. November 2015 and 1. October 2016.
  This postpones forced upgrades and/or changes of configuration as long as possible.
  Note expiration dates after October 1, 2016 will probably be lost / wasted. Renewals can usually only be started when there is 90 days or less left on the certificate.
  
• Other solutions include reconfiguration to use non-internal server names, i.e. split DNS or external valid servernames internally (i.e. server01.fairssl.dk).
• Another solution would be an internal certificate authority (CA) to issue internal SSL certificates and technical solutions that split internal and external SSL certificates, i.e. Reverse Proxy/Forefront TMG.

I would expect that very soon the Certificate Authorities will begin closing down on internal server names, even if there is a couple of years left, it is just easier closing it all together.

Important dates

• 1. July 2012 – All CA’s must warn customers that internal server names will be phased out from publicly recognized SSL certificates.
• 1. July 2012 – All CA’s must ensure certificates issued with internal server names expire no later than the 1. November 2015.
• 1. October 2016 – All CA’s must revoke/kill all certificates that is not expired and contain an internal server name.

What is an internal server name?

Below are examples of internal server names. If a certificate contains names like these, it will be subject to the change.:

• Server01
• exch01.fairssl.local
• srv01.domain.lan
• localhost
• 192.168.100.10
• 10.0.0.10

Which CA / browsers is this going to affect?
In short all of them.Regardless of membership, Microsoft, Apple, Google, etc. will force all SSL CA’s to follow this protocol in the future. Examples of members who follow this:

• Symantec Corporation / VeriSign
• GlobalSign
• GeoTrust Inc.
• Comodo CA Ltd.
• Entrust Inc.
• DigiCert Inc.
• DanID A/S / TDC
• GoDaddy
• And 32 other issuers….

More info ..

Full details on this and other requirements can be read directly in the requirements document CA / Browser Forum – Baseline Requirements – v.1.0

Last updated 9th May 2012. This text in danish here.

If you want real live assistance with your SSL certificates, guidance and support is all what blueSSL.com is all about, no matter what SSL product you prefer.

One Response to “Why you can no longer just have one SSL certificate with all the servernames included.”