The death of non-verifiable subject alternate names in certificates…

2017-07-27T00:01:02+00:00 April 23rd, 2014|Uncategorized|

If you’re not aware, 3rd party certificate providers (Verisign, etc.) won’t be allowed to issue certs with non-verifiable Subject Alternative Names (SANs) or Subjects with so-called “internal” server names in the near future.  For example, server.local, servername, server.lan, etc. are *not* valid inclusions in certificates; basically any name that is not verifyable against a public registrar.  Any 3rd party cert with an internal server name that you acquire now will be marked for expiry on November 1, 2015.  Existing certs will be revoked on October 1, 2016 – assuming the provider is following guidelines. 

This can be problematic going forward when it comes to designing Active Directory services for new Forests, since best practices have historically been to try and avoid split-brain/split-horizon DNS, if possible.  Going forward, any new AD designs must include considerations for domains that end in .com or .net, in order to avoid this issue.

And at this very moment, I’m on an engagement that has a non-internet routable AD Forest name; so I am planning for this situation.

If you end up in this situation and you need SANs with internal server names (read: the FQDN of an Exchange Client Access Server), the good news is that DigiCert has a tool and some steps to follow to work around this.  For additional information, please see these great explanations from DigiCert:

Internal Server Names
New gTLDs
DigiCert Internal Name Tool
Redirect Internal Exchange Domains to use External Domains

Microsoft is writing their concerns and tips about this situation into some of their Knowledge Base articles as well (see the “More Information” section in this support guide).  Now hang on…  that doesn’t mean re-work your entire DNS and AD infrastructure.  Instead, they recommend creating an internal DNS zone that matches your external zone and setting up the appropriate Exchange records.  You leave your existing DNS internal namespace alone.  That’s one way to do things if you walk in to *any* environment with a .local (and the like) internal DNS name.

For *new* environments, however, if the customer is using externally, then set up the new AD infrastructure as or and get past this silliness.  Just add the names to the Subject Alternative Name on the cert, set up the internal Exchange URLs appropriately, and you’re done.

This change can have ramifications beyond Exchange, folks.  Short-names are also disallowed, so you can’t even put things like MYWEBSERVER or MYSHAREPOINTSITE as a SAN now.

Yes, this means I feel this is something *very* important for us to keep in mind as we work with AD, Exchange, Sharepoint, etc.  You’re going to find certs that expire Nov 1, 2015… and that’s less than 18 months from this writing.  That’ll be here before you know it, and we all need to be prepared for these situations. 

If you’re in charge of potentially-affected systems, consider yourself warned!  And if you’re someone who doesn’t have time in your busy schedule to handle this, let us know if we can help you…

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113