SSL, the basics:
A SSL certifcate enables secure communication (encryption) between client and server. For this to work, there are 3 checks performed by your client (which can be a computer, pda, smartphone, etc):
- Date of the certificate. Is it valid? Isn’t the certificate expired yet?
- Trusted Authority. In short: which trusted company sold this certificate? e.g. Verisign, Thawte, etc. Your client has a list of well-known and trusted companys. If this company is on the list, this certificate can be trusted also.
- The common name. If the common name on the certificate is www.domain1.com and you want to visit webmail.domain1.com through ssl, check 3 fails.
Exchange 2007 and SSL
After installing Exchange 2007, a self-signed SSL certificate is installed by default. This SSL certificate is used to secure communication between both Internet clients (Exchange ActiveSync, Outlook Web Access, Outlook Anywhere, POP3 and IMAP4) and internal clients (Outlook 2007) to the Client Access server.
Exchange Server 2007 also introduces a new Exchange web service called the Autodiscover service. The autodiscover service is used to configure Outlook 2007 clients. More specifically, the Autodiscover service is used by Outlook 2007 client features such as the Availability service (free/busy), Auto Account Setup (automatic profile creation), Out of Office (OOF), Offline Address Book (OAB), and Unified Messaging (UM). This means that in order for these features to work correctly, the Autodiscover service must be properly configured. Since the Autodiscover service is a web-based service, it’s located on the Client Access server (CAS). And since it’s a webbased service, it needs an SSL certificate that is accepted by all clients, internal but also on the internet.
We now have one problem.
As the common name of the server is different, based on where you reside at that moment, you’ll need a SSL certificate with at least 5 different common names, e.g.
- the netbios name of the computer, lets say: “EXCH2K7SRV02”
- the fully qualified domain name in the local network; EXCH2k7SRV02.domain1.local
- the fully qualified domain name on internet; webmail.domain1.com
- the fully qualified domain name for the autodiscovery in the local network; autodiscover.domain1.local
- the fully qualified domain name for the autodiscovery on internet; autodiscover.domain1.com
SAN certificate
With Exchange Server 2007 a new type of certificate is introduced; it’s called a subject alternative name (SAN) certificate. The interesting thing about a SAN certificate is that it allows us to include multiple FQDNs (aka common names) in one single certificate.
So in case you wondered: this SAN certificate has nothing to do with your SAN storage. It’s something different.
Request a SAN certificate
Start the Exchange 2007 Management Shell
In the Powershell we type:
[PS] C:\Windows\System32> New-ExchangeCertificate -DomainName EXCH2k7SRV02, EXCH2k7SRV02.domain1.local, webmail.domain1.com, autodiscover.domain1.local, autodiscover.domain1.com -FriendlyName Domain1SSLCertificate -GenerateRequest:$True -Keysize 1024 -path c:\certreq.txt -privatekeyExportable:$true -subjectName "c=US, o=My Company, CN=domain1.com" -privatekeyExportable:$true
As you see, with the “-DomainName” parameter, i’m requesting a certificate for 5 Subject Alternative Names which makes it a SAN certificate.
Make the “-FriendlyName” something obvious. And remember it, you’ll need it later!
I mark the private key as exportable (”-privatekeyExportable:$true”) in order to re-use the certificate whenever i want to transfer it to another server. I know this is less secure, but i’ve been in a lot of situations where customers didn’t remember where they bought the certificate or didn’t have the appropriate login info etc. So that’s why.
In the “-subjectName”, specify your country “c=US”, organisation “o=My Company” and the domain you are working with “CN=domain1.com”.
As you see (”-path”) the request is stored in a file called c:\certreq.txt. The content of this file is required to actually request the certificate at your SSL reseller or your own active directory CA.
Import the SAN certificate
Once you’ve got the certificate, save it to c:\certnew.cer.
In the Exchange Management Shell type:
[PS] C:\Windows\System32> Import-ExchangeCertificate -path c:\certnew.cer -friendlyname "Domain1SSLCertificate"
So this is where you’ll need that friendlyname again.
After his command you’ll see a “thumbprint” on your screen. My example: “795E704F73D47F6053A493961CB23DB349731141”
The certificate is now imported.
If you forgot the thumbprint, you can look it up by typing:
[PS] C:\Windows\System32> Get-ExchangeCertificate -DomainName "EXCH2K702"
All you have to do right now is activate the certificate for the required Exchange services. Do this by typing:
[PS] C:\Windows\System32> Enable-ExchangeCertificate -thumbprint 795E704F73D47F6053A493961CB23DB349731141 -services "IIS,POP,IMAP"