There have been a lot of changes to the way that SSL certificates are issued and the impact of those changes are now being particularly felt within the Exchange community.
What has changed?
The CA/Browser forum (made up of the companies that issue the certificates and the browser developers who use them) decided that that all certificates issued with an expiry date after 1st November 2015 will be restricted to internet resolvable FQDN's only.
This means that you cannot have an SSL certificate with:
- Single name hosts - such as intranet, server, exch01
- Internal only domains - such as server.example.local
- Internal IP addresses (both Ipv4 and Ipv6).
This applies to both the common name and any additional names on the certificate.
Furthermore, if you have a certificate that is still in force with an invalid name from the list above, then it will be revoked on 1st October 2016.
How does this affect Exchange?
Exchange 2003 isn't really affected by this, because most people simply purchased standard single name SSL certificates.
Exchange 2007 and later however are being impacted.
During the early life of Exchange 2007 the advice for SSL certificates was to include both the internal and external host names of the Exchange server. This was because the default configuration of Exchange uses the server's real name and therefore did not require additional modification.
However it quickly became apparent that this wasn't the best way to deploy Exchange web services, as end users were entering the same address internally as they were externally. Split DNS was the answer there
http://semb.ee/splitdns
Following the changes to the guidelines for issuing certificates, the changes to Exchange, including setup of a split DNS system is almost mandatory.
Going Forwards
With this change, you can now get away with just two host names on an SSL certificate for full client support:
- host.example.com
- autodiscover.example.com
With our
own certificates coming with five "names" available by default, and unlimited server licence, this means you can use the other slots to secure additional services. Once the certificate has been installed on the Exchange server, export it and then import the certificate in to other servers that need it - along side the required intermediate certificate.
If your DNS provider supports SRV records, then you can even use a standard single name SSL certificate. However mobile devices in particular seem to have some problems with the SRV autodiscover method, so if you are going to deploy mobile devices, stick with a UC (Unified Communications) type certificate. One of the cheapest sources for those is our own site CertificatesforExchange.com
http://semb.ee/certs
If you have a certificate with internal names that expires after 1st October 2016, then you should get it rekeyed with the internal names removed, so the certificate is not revoked.
What else is changing?
From April 2015, the maximum period a certificate can be issued for is being reduced to 39 months. This is to ensure that the names on certificates are checked frequently that they still belong to the original purchaser.
SHA-1 certificates are being phased out very quickly and in 2017 Microsoft will stop trusting them. However a lot of browsers will start showing warning messages on these kinds of certificates in 2016. Therefore to protect yourself, ensure that you are requesting SHA-2 certificates and have replaced any SHA-1 certificates by the end of 2015.
Action Points
What should you do about your own SSL certificates?
- Check whether they are SHA-1 or SHA-2.
To do that, browse to the SSL site, then open the SSL certificate. Click on the Details tab and then look for Signature Hash Algorithm. It should NOT say SHA1.
Do not confuse with Thumbprint Algorithm, which will always say SHA1, no matter the type of the certificate.
If they are SHA1, then get them rekeyed to SHA-2. If your provider doesn't allow that, then change provider. http://semb.ee/certs
- Check your server configuration and start to move everything over to use the same host name internally and externally. This is easily done by setting up a split DNS system, then changing the Exchange configuration. If your certificate still contains the internal names they will continue to work until you change the SSL certificate, providing a time to educate the end users about the names to use.
Remember if you replace a certificate before it has expired, revoke the old one. This will often happen automatically when you get a certificate rekeyed, but it does no harm to do that yourself anyway.
