This does not mean you can no longer use SSL certificates for internal use. Internal websites and networks simply need to transition to using delegated domain names or registered IP addresses. For instance, “mynetwork.internal” cannot be reliable verified to be owned by only one company or party. Therefore it is a security risk to have multiple certificates issued out to that same domain. If your internal network is on a similar internal name, it just needs to be transitioned to a registered domain name, such as “mynetwork.com”. That domain does not need to resolve in the public DNS, or go to a publically available page.

The CA/B forums new requirements also disallow internal domain names in the Subject Alternative Name (SAN) extension. If Certificate applications do include a disallowed domain, often times the CA can automatically reject the order or notify the applicant that the use of internal name has been depreciated.

So to summarize, Certificate Authorities shall not issue a certificate with an expiry date later than 1 November 2015. Certificates with validity periods past that date may also be forced to lose their internal names they next time they reissue.

Here is some quick FAQ Answers for Your Basic Questions:

What is SAN/UCC SSL Certificate?

SSL Certificates that you can and can’t use to secure your internal domain names or Internal Server Names likes:

No longer allowed:

Use these instead:

What Is Internal Server Name?
An internal name is a domain or IP address that not actually registered. Common examples of internal names are:

What You Need to Do?

If you have multi server names and want to secure them with trusted SSL Certificates then you need to reconfigure all those servers to use a public name. Some exceptions can be made if you need more time to transition, for these cases please contact us directly. All internal connections that require a publicly-trusted certificate must be done through names that are publically delegated and verifiable (it does not matter if those services are publicly accessible).

How to Redirect Internal Names to use a Registered Domain Names?

If you are using a single SSL Certificate to secure your internal domain names for your Exchanges Server for your internal communication then you will need to make all the internal domain names to public domain names to use SSL Certificates.

To reconfigure your domain to use only the external domain name you have a couple of options. If you are using Active Directory you can migrate an internal Active Directory domain to a registered External name. This will change the internal FQDN of your Exchange Servers so they will reroute to a valid subdomain of your registered external domain(e.g. change from Server01.yourcompany.internal toServer01.yourcompany.com) allowing you to use a SAN certificate or UCC Certificate to secure these names.

Alternatively, you can redirect the internal names to use the external mail URL, but this method will not allow access to mail using the Outlook Anywhere service so users connecting over a VPN would have connection problems.

Redirecting your Exchange Server to use the External DNS Name

To update your Exchange 2007 or Exchange 2010 server you will need to run the following commands from the Exchange Management Shell and replace the Server running the Client Access Role with your external domain name. These commands update the URL for the Auto discover service, Exchange Web Services (EWS) and the OWA Web-based Offline Address book respectively.

Before running these commands you will just need to check make sure a DNS record exists mapping the IP Address to the Exchange Client Access (CAS) server.

Note: Each of these commands below should be run on a single line in the Exchange Management Shell (EMS):

Recycle the IIS Application Pools

Next to make these commands take effect you have to tell IIS to push these changes by recycling the application pools.