Solutions to the problem of prohibiting the use of internal local names in SSL-certificates

As it stands, and according to the latest requirements of the CA/B Forum, all certificates containing internal local names in the CN or SAN fields will be cancelled on 1 October 2016. Already many certification authorities have ceased issuing certificates with local names, the expiry date of which is 31 October 2015 and later.

For those who create the Exchange and Active Directory architecture from scratch, the right solution is to anticipate the use of external names in advance and take care of their registration.

But what to do to those whose infrastructure has long been functioning and successfully established?

Let's look at some of the ways to solve this situation:

1. The first solution is to use certificates issued by your own internal certification authority.

For those local names that were banned, you just issue certificates from your own certification authority. For other names, you continue to use public certificates from official CAs.

The public certificate in this case is attached to the ISA/TMG for external access while the internal certificate is attached to the Exchange server.

2. The second solution also involves using your own internal certification authority.

You need to create a second IIS site on the Exchange server with the Client Access server role and create additional virtual directories for external services (for example, OWA).

In this case, you bind the public certificates to this IIS site, and your internal certificates you bind to the default website.

If the ISA / TMG server is involved in the scheme, a public certificate is assigned to it.

3. The third solution is to transfer or rename Active Directory domains.

If you choose between ways to transfer or rename domains, it is likely that the first one will be the least painful for the entire structure as a whole. However, it is recommended to make these changes on the planned server update and take in to account the specific features of your environment.

In any case, no matter what option you choose, you should proceed in a way that will give the least amount of loss for your system.

It is recommended that changes are made in a test environment first and then transferred to a real server. Or, it is advised that you plan a reliable way to rollback the system in the case of unforeseen difficulties.