Home > Exchange, Exchange 2010, Exchange 2010 AKA E14, Exchange and UC, Lync, Lync 2010, Microsoft > No More local names in the certificate starting November 2015 #MsExchange #Lync #ucoms #lync2010 #Microsoft Part1

No More local names in the certificate starting November 2015 #MsExchange #Lync #ucoms #lync2010 #Microsoft Part1


Starting November 2015 all public domains providers will prohibit the use of invalid domain names, this is because internal servers names are common and could be falsified and end server connection can’t be assured, you can read more about it here

http://www.digicert.com/internal-names.htm

and

http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/

The reason that is given for the change is that the internal server names are not unique and therefore easy to falsify. With common names like server01 or webmail, the end user is never sure if it is actually dealing with the right party or with a malicious.

The changing legislation for SSL Certificates shall start on 1 November 2015. This means, from that date, the invalid Fully-Qualified Domain Names (hereafter called FQDN) will no longer be accepted at the standard of the CA/Browser Forum and after that date such certificates may no longer be issued. All certificates issued after 1 November 2015 and meet this qualification will be revoked upon discovery.

Users who are requesting a certificate on an invalid FQDN with an expiration date after 1 November 2015 should remember that their certificates will be revoked after 1 November 2015. After this date, no SAN SSL Certificate with a reserved IP address or internal server name will be issued either.

you can download the new certificate requirement for the cabforum here http://www.cabforum.org/Baseline_Requirements_V1.pdf

What does that means:

if you are running your domain using an invalid name (.local or .dom) you might face some issues depending on your configuration, the most commonly affected applications by this changes are Microsoft Exchange and Microsoft Lync servers.

for years we have been using the UCC certificate which allowed us to include internal server names along within the public certificate which offered a simplified configuration, I do believe that this change will require massive changes in the Exchange and Lync infrastructure to support this change.

For Microsoft Exchange:

Depending on your configuration you might need to do some changes in your infrastructure to support this change, let us divide the configuration as following:

1- Your Active Directory domain name is domain.com or other valid domain names:

if your Active Directory domain is running domain.com name or other valid domain names, then most probably your changes are minimal, the only catch here if your users are accessing OWA using https://mail or https://Exchange internally for end users simplicity, this will not be supported or working anymore and you will need to work with your end-users to fix that.

2- your Active Directory domain is domain.local (or other invalid name): 

oooh baby, you will have fun, because of how internal and external URLs in Exchange are functioning you will need to do more than just a new certificate request for your servers, but again it depends on how you configured your Exchange servers:

For a single Active Directory site deployment:

 

If your Internal URLs for Exchange Webservices uses External names, then you are fine, but if you are running a single Website for OWA, OAB and other webservices functionality, you will have to consider 2 solutions:

  • Change the internal names of the vDirectories to include public domain names (.com or .net for example) this will require creating the correct DNS zones in Active Directory (domain.<valid domain>) and configure the entries in that DNS zone to map to the correct internal and external IPs (some services will point to internal IPs like Exchange webservices and some will point to External IPs like your website for example), you might also require some changes in the certificate to include the new names or purchase a new certificate to accommodate the new names.
  • Create a new website on the Exchange and split the traffic between the External website and the internal website, for the new website you will need to include the correct names (either internal and External) and configure a new IP for the CAS servers, using host headers with OWA and ECP currently breaks OWA/ECP thus you will need to assign your CAS servers new IP, and configure the websites to listen on its corresponding IPs and configure publishing rules to publish the new configuration (this also depends on your network infrastructure and firewall configuration).
  • External Names and its certificate will need to be revisited to issue the correct names in the certificate, I am not sure whether old certificate will be revoked or kept as-is, but if they will be kept until they are revoked and never re-issues then you can skip this step.
    You might need to check you NLB configuration if it is there to include a new NLB IP for the internal Names.

For a Multi Active Directory site deployment:

again it depends on your configuration, and this might be a little tricky because or redirection and proxying, I have tried to simplify it but I couldn’t as there are various factors and configurations but here are some guidelines:

  • Document how you are doing OWA and webservices right now, also how your are doing your proxy or redirect configuration.
  • External Names and its certificate will need to be revisited to issue the correct names in the certificate, I am not sure whether old certificate will be revoked or kept as-is, but if they will be kept until they are revoked and never re-issues then you can skip this step.
  • Internal Names will need to be checked and either re-mapped to names that includes valid external domains and this will require DNS and certificate changes as I stated above.
  • Internal names that will be kept internal will need to use their own website, new IPs and Certificate which might be re-issued, also you might want to re-visit your NLB configuration, also you will need to check you NLB configuration.
  • you will need to revisit your InternalNLBBypassUrl , the recommendation is not to change it from the internal server name and for the time being I don’t have another recommendations, and until then and if you do Proxy across the sites you might stuck with the new website option
  • in part 2 we will see how the change affects Lync 2010.

  1. MarkD
    November 22, 2012 at 1:38 pm

    When can we expect part 2 of this article?

    • November 29, 2012 at 8:16 am

      Part 2 has been addressed by other MVPs (Paul and Elan Shudnow), you can search for their blogs, this is why I didn’t post part2

  1. July 17, 2012 at 4:59 am
  2. September 1, 2012 at 2:03 pm
  3. March 7, 2013 at 11:30 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: