How to Deal with SSL Requirements for Exchange when Certificate Authorities Won’t Issue You a Certificate

I’ve been receiving more and more questions about SSL certificates from people who find themselves in a situation where they can’t get the certificates they need from a public certificate authority.

The scenarios tend to be either:

  • they are using a DNS namespace that they do not actually own the domain name for
  • they are using names that are no longer accepted by commercial certificate authorities due to changes in the rules for issuing certificates

Let’s take a quick look at an example of each of those scenarios.

Using a DNS Namespace You Do Not Own

I’ve seen this scenario occur a few different ways. In some cases the company uses something they thought was harmless and generic for their internal namespace, such as office.net, and then a public namespace of company.com. However, someone else already owns the office.net domain, so they are not able to register it.

In other cases the company used company.net internally, and company.com externally, but simply forgets to register company.net and someone else came along and registered it afterwards.

In either case because you are not the owner of the domain a public certificate authority will not issue you an SSL certificate for that domain.

Using a Name No Longer Valid Under New Rules

In this scenario a company uses an invalid namespace for their internal domain name, eg company.local, or uses short names such as webmail or even IP addresses for internal access to certain services, and wants to include those invalid names, short names, or IP addresses in their SSL certificate.

In 2012 the rules for SSL certificate issuance have changed. From Digicert:

The CA/Browser Forum, a collaborative effort between Certificate Authorities (companies like DigiCert that issue certificates) and Web Browsers (companies like Mozilla or Microsoft that manage trust on a CA level), has introduced new Baseline Requirements for certificate issuance.

As part of these new requirements, Certificate Authorities must phase out the issuance of certificates issued to either Internal Server Names or a Reserved IP Address by October 2016. Specifically, CAs cannot issue certificates to these internal names with expiration dates after November 1, 2015…

Essentially, this change in SSL standards will make it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as owned by the organization that is requesting the certificate.

Avoiding the Problem at Design Phase

For those who get the opportunity to design new Active Directory and Exchange environments from scratch the best advice is to avoid using an internal namespace that the company doesn’t own.

I recently saw a new AD/Exchange design that proposed a .local namespace and gave them that same advice. Even though it may have been possible for them to be issued an SSL certificate with .local names in it today, when that certificate expires it may not be possible to renew it.

Better to avoid the problem before the first domain controller is even promoted.

Resolving the Problem for Existing Organizations

For those who are already in the situation where they will not meet the new requirements for certificate issuance there are a few approaches that can be taken.

Renaming/Migrating Active Directory Domains

Digicert published some brief guidance on renaming Active Directory to resolve the issue. They also suggest considering a migration to a new domain that has a compliant namespace.

Personally I would not be keen to undertake either of those unless absolutely necessary. This is really a decision for businesses to make based on the number of things in their environment that would be impacted by such a change.

A migration may be less painful that a rename but I would probably lean towards doing that on the next upgrade project rather than rush it through immediately.

Using a Mix of Private and Public Certificate Authorities

More and more organizations are running their own internal PKI these days due to the increasing number of products that use SSL in their communication channels (not just Exchange, but also Lync and the System Centre family).

This makes it possible to meet your SSL requirements for non-compliant names using your private CA. The challenge though is to combine this with public CA certificates so that non-domain members (such as mobile devices) will continue to work correctly for external access.

Example 1

In this example you could use a private CA to issue the SSL certificate for the .local names, and a public CA for the public names (eg webmail.company.com). The public cert is bound to the ISA/TMG for external access, while the private cert is bound to the Exchange server itself. The ISA/TMG bridges the traffic between the two, with external clients unaware of the internal namespace.

Note: this is also a solution for those who don’t want the public-facing cert to have internal server names on it.

Example #2

Another approach is to create a second IIS website on the Exchange server (Client Access server) and create additional virtual directories for the external services such as OWA. You can then bind the public CA issued certificate to that IIS website, and the private CA issued certificate to the Default Website.

When combined with split DNS this allows internal and external clients to connect to services such as OWA by using the same name.

If an ISA/TMG server is also involved it would also have the public CA cert bound to it, and would publish external access to the second IIS website.

Summary

It is difficult to cover every scenario in an article such as this because there will be a lot of variables depending on the specific environment. Before you deploy any solution I do recommend that you thoroughly test it first in a test environment, or at the very least have a clear rollback plan if something unexpected occurs.

Hopefully though you can see that there are options that exist to allow us to work through these changes to the rules for SSL certificate issuance, without necessarily having to make a major architectural change to our AD/Exchange.

Further reading:

Comments

  1. Ahmed says

    Actually i have learnt that i can use any internal name for my company, and if i want to have public name i have to choose one matches the world rules.
    I mean would it be a problem to have my active directory domain (ABC.local)? , and if i wanted to have a public name i have to choose a name that hasn’t taken before by any company !

    Is that what you meant or you mean to make the internal name like the external name (ABC.com) ?

    If you think about E-mails, i can use hub transport Accepted domains for the external name and make an email address policy to change the E-mail addresses to the new extension (test@abc.com).

    Do you think i am thinking right?

    • says

      The internal/external namespaces can be different.

      The point is that if you choose an internal namespace that doesn’t meet the new rules, or that you don’t own, then you won’t be able to get SSL certificates for those internal names (such as your Exchange server FQDN) from commercial CAs.

  2. Antonino says

    Hello Paul, I have an Italian student and I read with interest your post but I would like to ask you a question that might interest many users.

    I would like to use a registered domain for testing laboratory for a school. You carry the sample data for the domain name, server, etc..
    Can you tell me what names should I take to a CA for a certificate SAN (The CA may issue certificates .local and .it)

    Internal Domain Name: scuola.local
    Public Domain Name: scuola.it
    Name Server Exchange 2010: cas-01
    FQDN Server: cas-01.server.local

    I would like to use the name OWA mail.scuola.it, is it possible? Or should it be cas-01.scuola.it?

    Could you tell me all the names to be included in the certificate request.

    Thanks
    Antonino

  3. JS says

    I thought it was a best practice to have your internal and external namespaces different. Now its suggested that if you are creating a new AD forest/domain to go away from that and make them the same. Or rename your domain to a resolvable one. This makes no sense.

    I assume Lync will be severely impacted by these changes as well.

    • says

      Fewer namespaces are easier to manage, but that doesn’t mean that it is the right solution for all situations.

      The main point is that you should not use namespaces that (a) you don’t own, or (b) are no longer valid under the new rules for SSL certificates.

      Yes this will impact Lync and really any other product or technology where you need to acquire an SSL certificate from a public CA.

  4. Pavan Segal says

    Hi Paul – Currently we have a default self signed server certificate which contains the name of the Exchange Server. However when we use OWA and OutlookAnywhere, unless we use the internal LAN Exchange server name in the OWA URL / Outlook Anywhere Proxy server settings, we get certificate errors eg for OWA the error is that the certificate is not trusted and for Outlook Anywhere the error is that the server name is incorrect…
    And this will of course only work when on the local Domain…
    NOW..I want to create a new Exchange Server Certificate, which contains my resolvable server name (eg the server name which is used in the EXTERNAL Public DNS namespace..)
    In your posts you have said that only one certificate can be used by IIS, and I am wary of creating a certificate that affects my local Outlook clients…
    Can I create a second Exchange certificate solely for OWA and Outlook Anywhere services and leave the IIS,SMTP services on the default server certificate
    We have problems getting a CA issued certificate as there are too many requirements asked for by the Certificate Issuer we have tried so far…Also we would like to use the private CA route if possible…
    Thank you for your feedback/comments on the above

  5. Jan Pages says

    Paul,

    regarding “Using a Mix of Private and Public Certificate Authorities”, you mentioned Microsoft Firewalls ISA/TMG to bind the external certificate to (Example1 and also Example2).
    What if you don’t run an ISA/TMG but an alternative firewall such as pfSense, Astaro or IP-Cop?
    Should it also be configurable, or does the bridge-functionality resp. access chain EXTERNAL CLIENT -> FIREWALL -> CAS require some special Microsoft-only features?

    Thanks in advance!

    • says

      If you want to use a mix of private and public certs then your public facing reverse proxy needs to be able to do the SSL proxying like ISA/TMG. Some do, some don’t. It isn’t a Microsoft-only capability.

  6. Joseph Steely says

    I ran into a similar situation during an Exchange 2003 to 2010 migration.

    Someone thought it would be clever to use domain.AD as the internal namespace.

    The workaround I used was to update the InternalURL properties of all of my CAS services to match the ExternalURL value.

    The only real issue with this setup as it was necessary to maintain a split DNS zone internally for the external namespace to service clients connecting locally.

    But that still seems like less work than maintining an additional CA, or renaming you production AD domain (Yikes!)

    Just thought I’d throw that out as another possible workaround.

    Thanks!

    • Sam says

      This also worked for me. We had a ‘.local’ internal namespace. We also had an internal DNS entry for our mail server’s external (.com) name which pointed to the server’s internal IP address. I used a non-SAN (i.e. basic web server) certificate from a public cert. authority for IIS/HTTPS, and my local certificate authority for everything else. By updating the Web Services Virtual Directory Internal URL and the Autodiscover Service Internal URI from the shell (as well as setting all of the CAS URLs in the GUI) I was able to allow OWA and EAS to function properly both internally and externally, and Outlook clients to connect without getting those pesky certificate popups. Thanks!

  7. says

    Another alternative is to use a Layer 7 load balancer with SSL offloading. It is similar to the TMG example. In this case the virtual directories are configured not to require SSL and the ‘internal’ leg of the connection is transmitted insecurely – however we DO trust our internal network, so that’s not a problem is it?

    It is a complicated topic. An IIS website can only have one certificate bound to it. IF SSL is required, the namespace configured on each virtual directory must be included on that certificate and that certificate must be trusted by the client. Outlook clients will access several virtual directories including Autodiscover, EWS and OAB (and possibly UnifiedMessaging too). If you get just one wrong, you can get a certificate warning message.

  8. gary says

    Can i verify something (as we want to use SSL for activesync):

    We use domain.local – locally.
    External email and website domain used is do-main.co.uk

    How best to proceed with activesync and godaddy cert?

    Thanks

  9. Michael says

    Is reconfiguring Exchange virtual directories to use the external namespace for both InternalURL and ExternalURL, and using split DNS valid for Exchange 2013?

    I know for a fact that it works for 2010. But not sure about 2013.

    Please advise.

  10. Renaldo says

    The best resource I’ve found that addresses this issue is “http://www.it-book.co.uk/2459/how-to-setup-exchange-ucc-or-san-certificate-with-non-standard-domain” works like a charm.

  11. says

    This is a very informative article. I currently have an Exchange 2010 Server with SAN certificate. I use a mix of public DNS and private DNS names.

    Currently I have the following in the SAN Names:

    es1.company.com (used for OWA and Active Sync over the Internet and Outlook over HTTP)
    autodiscover.company.com used for public auto-discovery
    autodiscover.company.wan for private auto-discovery on LAN
    servername.company.wan for network RPC communications

    I use split DNS internally. Would it be a big deal to phase out the use of servername.company.wan and autodiscover.company.wan? Other than to ensure that my Internal DNS is pointing the first two records to my internal IP addresses, what else do I have to do or watch out for?

  12. says

    Hello! I know this iss kinda off topic buut I was wondering which blog plaatform are you using for this website?
    I’m getting sick and tired of WordPress because I’ve had problems with hackers aand I’m looking at options for another platform.
    I would be great if you could point me in the direction of a
    good platform.

  13. says

    Hello Paul,
    great article. I completetly agree with you. Fortunately I have always designed the AD using registered domain name.

    But just today I have an issue on an Exchange 2013 installation on a domain.local AD domain. I have changed all the internal/esternal url to the esternal register domain name, configured the split DNS. Just all the stuff I saw you mentioned on your article “Avoiding Server Names in SSL Certificates for Exchange Server 2013″.

    But configuring Outlook 2013 I always receive the error on the name exchange2013.domain.local. And, as you wrote, adding the .local host name on the SAN certificate is not an option.

    Any ideas?

    Still my compliments. Ciao

  14. zulfiqar says

    Hi Paul,
    Could you help me to find risk in this scenario
    Here’s one for your review… one of the Devs is asking for a certificate for dev environments to validate domains like:

    *.ws01.dev9.com
    *.ws01.dev10.com
    This would allow them to validate any Dev subdomain off our internal CA cert.

    Thanks
    zulfiqar

  15. Martin says

    Hi Paul,

    I find your website very interesting and this post has significance to an error i encountered with my Exchange environment.

    I have 2 CAS servers and 2 Mailbox servers that was implemented from scratch.

    All outlook clients could connect and suddenly on 02/05/2014 my clients keeps prompting for username and password.

    When i delete and recreate the profile it says: “The connection to Microsoft is currently unavailable. Outlook must be online or connected to complete this action”

    All connections through OWA works fine.

  16. DEngland says

    Wasnt MS Best practice to have a domain like contoso.LOCAL internally?
    This new SSL change seems to upend that entirely.

  17. Bill says

    Hi all,

    I am in the same boat as many. I have an internal domain name (xyz.local) and an external domain name (abc.com).

    I have a wildcard cert on my TMG to facilitate external connections to OWA, EAS, etc., but I also have a SAN cert on my CAS box that contains internal server references.

    I utilize split-DNS, so my internal DNS server handles both the xyz.local and abc.com domain for users connecting internally.

    My current SAN certificate will expire soon. I have the new SAN cert ready to go, minus the internal server names (ie. exchange.xyz.local).

    Assuming that I have the correct references setup in my split-DNS zone, isn’t there some configuration changes that need to be done on the CAS and/or active directory to tell the clients (Outlook) to connect using the “external FQDN” as opposed to the internal exchange.xyz.local name?

    Currently, when a user connects via Outlook the connection settings look for the internal server name (ie. exchange.xyz.local). That internal server name is currently on my soon to expire SAN cert, but will not be included on my new cert.

    Will my Outlook clients have a fit when suddenly the internal server name is no longer on the SAN cert?

    I just want to make sure that I don’t disrupt my internal Outlook clients when assigning services to the new certificate.

  18. Jeff says

    Hi Paul,

    Thank you for all of your exchange 2010 to 2013 migration guides they were very helpful in my migration. However, i am having one issue with the certificates and i still can not seem to get it to work.

    I am hoping you can help and here is my setup below.

    We have our main adsite test.corp (no i was not the one that set this up.) We also have subdomains test.fr, test.com etc.

    We are in Co-Exsitance right now and I moved my mailbox to 2013 and I am getting certificate issues. I have a kemp LM2200 with 2 cas servers and 2 mailbox servers. What I am trying to do is use the public cert on the kemp and the internal cert on the cas servers but something is going wrong. The public cert contains autodiscover.test.com and webmail.test.com. The private cert(from our private certificate authority) has the fully qualified domain of the server in it but only the server name for its own server so test-cas-1.test.corp. the 2nd cas server has test.cas-2.test.corp. when i assign these certificates I cannot get through via webmail and my outlook just keeps trying to connect or ask for my password. This is the only thing that is not working. when i just use the public cert on the cas servers i get the cert error about the internal names not existing on the public(makes sense.)

      • Jeff says

        I understand that but the only way right now i can do this that i feel would work with the least amount of impact is either example 1 or example 2 of this current link. our ad site is test.corp which can not be put into the public certificate since it is internal. we our a world wide company so we have .com, .fr, .es, .it etc. we also have exchange servers in .fr. so i was hoping If i understand example 1 correctly we can put the public cert on the kemp loadmaster and than use the inter private cert on the exchange servers for internal. or would i be better off creating 2 iis sites and having the public cert on the kemp and the default of exchange and than the internal cert on the 2nd iis and point internal users to the 2nd iis site.

        thank you,
        Jeff

        • says

          I don’t recommend option 2 for Exchange 2013 environments. That article pre-dates Exchange 2013’s release. The CAS architecture has changed.

          If “webmail.test.com” is what your users type into their browser to connect to OWA, then that is what should be configured on the OWA virtual directory of all the CAS in that site, and that is what should also be on the SSL cert. The same cert should be used on all of the CAS that are configured with that namespace.

          The simplest configuration is to follow the recommended practice, which is to not use server FQDNs on CAS URLs, and not use server FQDNs on SSL certs, and to use the same cert across multiple CAS.

          Everything you’re considering as a way to avoid doing that only adds complexity. Complexity is the enemy of supportability. It complicates troubleshooting, and makes the environment more difficult to manage overall.

Leave a Reply

Your email address will not be published. Required fields are marked *