Posts Tagged ‘Exchange’
Internal server names in publically recognized SSL certificates are about to become just as extinct as Sharks in Chinese waters.
The CA / Browser forum has decided to implement changes to SSL requirements, that will phase out all use of internal server names in public SSL certificates. The CA / Browser forum includes all the major certificate authorities and browser developers, so the change will be forced upon everyone.
The negative impact
It especially hits small to medium businesses with just a few servers. I.e. Exchange, Lync and Small Business Server, where a single SAN certificate including both public and internal server names, will save them both time and resources otherwise needed for reconfiguration, internal PKI solutions and/or reverse proxy and similar systems to allow usage of a separate internal and external SSL certificate on a single website/service.
Exchange 2010 will by default use a single website and configure it self to use its internal FQDN i.e. exchangeserver01.fairssl.local and external FQDN i.e. webmail.fairssl.dk for this one website/SSL certificate. The change will require a change in configuration or systems surrounding the Exchange 2010 environment to continue working without both names in one SSL certificate.
SBS 2011 on the other hand has received the functionality to use split DNS to use the external server name both internally and externally, this not much mentioned change may have something to do with Microsoft being on the CA / Browser forum board, so they would have known about this change for a while.
Larger companies typically have more resources and will have an easier time separating internal and external SSL certificates, without having to buy new solutions like Forefront TMG, SSL offloaders, Internal PKI, etc. But my guess is still that a large number of them will still need to change some configuration to avoid problems with internal server names.
The reasoning behind this phase out is to secure against Man-in-The-Middle (MTM) attacks, where it is possible to pretend to be an internal server via a publicly recognized SSL certificate. Even thou it is a highly unlikely way to attack most systems, the theoretical possibility is enough to spark the change. I just wish they had been a little more giving on the deadlines.
My personal recommendation to my customers with SSL certificates containing internal server names Read the rest of this entry »
The easiest way (I love easy!) to order and install an SSL certificate on Exchange 2007, is to order a SAN (Subject Alternative Name) certificate with AutoCSR meaning you dont have to create a CSR but instead get a certificate backup file (PKCS#12, P12. PFX). You also save time with the SAN because you only use one certificate for all services and can move services from one domain to another in the certificate with no problems.
Make sure you get a SAN certificate including the full domain name(s) you use to access Outlook Web Access, Outlook Anywhere, Autodiscover and any internal servernames using the certificate (usually free).
The Certificate you order should contain something like this:
- mail.sole.dk and/or owa.sole.dk - for Outlook Web Access
- autodiscover.sole.dk and any other e-mail domain you use with Autodiscover/OA.
- MYSERVER01 and MyServer01.domain.local - and any other internal servername that will be using the certificate
Personally I setup servers to respond only to OWA and ActiveSync on the mail./owa. domain, and use all other services like Outlook Anywhere, etc. on the autodiscover. address, this way I can use Forms Based Authentication/Basic with my OWA/ActiveSync website, and NTLM with my other services. You can see more information about this from my previous blogs here. Some people argue for and against having internal server names in the certificate, but I figure if they are free anyways, and might help why not add them - and if security is so much an issue that internal server names must not be revealed, you have other much bigger problems anyway.
How to configure ISA 2006 with FBA for OWA and NTLM for Outlook Anywhere and Autodiscover in Exchange 2007
Configuration of Exchange 2007 with Outlook Web Access (OWA), Outlook Anywhere (OA), ActiveSync and Autodiscover can add grey hair to any system administrator or IT consultant. Then also trying to get different authentication schemes and ISA 2006 to play nice is not making it any easier.
Most Administrators have a wish to configure their environments used externally as securely as possible, including using SSL certificates with HTTPS instead of no encryption with HTTP, and using NTLM authentication instead of Basic authentication. But security is not everything, a userfriendly interface like Forms Based Authentication (FBA) is a must to avoid user iritation and support calls.
However getting FBA and NTLM to work together in ISA with Exchange 2007 can be quite scary, so lets go deeper and find out what we need to be aware of to get it working.