Exchange 2007 /2010 installs itself with a self signed certificate. This means it gets you going with ssl, but it’s not something you want to run with in production. Why? Well, workstations accessing OWA will complain with a popup box saying it isn’t trusted, and SMTP attempting TLS won’t work because the receiving side (something on the internet) won’t trust it. It’s self signed.
So the first thing we need to do is generate a certificate request. This is generated using Exchange powershell, not IIS. Why? IIS does not have the ability to generate an SSL request with SANs. SANs?, Subject Alternative Names, are other names within the certificate besides the normal name, which is called the CN (Common Name).
Typically, an exchange server needs three names:
The first one is for Outlook 2007/2010 users to autoconfigure the client when they are external to the network. An outlook client will user this address to read an xml file off the server to configure the client to user outlook anywhere (rpc over https) to connect.
The name “autoconfigure” is hardcoded into outlook. The external domain in this case is the domain that the user would use for their email. So if the person’s email was firstname.lastname@example.org, the name would be autodiscover.whatever.com
The second one is for Outlook Web Access. I typically use this for the Common Name also. Some companies use “webmail”, some use “mail”, and some use “owa”. I like webmail.
The third is the server’s FQDN with “internaldomain.local” referencing the active directory domain name. You need this name or outlook clients will complain every time they connect. Why? Because Outlook 2007/2010 use a secure connection to the Exchange server, whereas Outlook 2003 does not.
Now, how to generate the code for this? It’s really simple if you go to this site for Exchange 2007 and this site for Exchange 2010 and fill out the info . Remember to include your common name in the first san field also. It may seem redundant, but it’s not.
In my example, the code for 2007 is this:
New-ExchangeCertificate -GenerateRequest -Path c:\certs\webmail_externaldomain_com.csr -KeySize 2048 -SubjectName "c=US, s=Wisconsin, l=Madison, o=Company, ou=IT, cn=webmail.externaldomain.com" -DomainName webmail.externaldomain.com, autodiscover.exernaldomain.com, servername.internaldomain.com, servername -PrivateKeyExportable $True
For convenience I make a folder off the C drive called Certs, then i place the above text in a text file called commands-used.txt or something like that. That way I can go back to it.
After you generate the file, c:\certs\webmail_exernaldomain_com.csr, you need to submit it the the certificate authority. I like to use Digicert.com because they have the best price on a 4 name san certificate. BTW, these are also called a “unified communications” certificate.
You will get back another file from digicert.com that is the other half of this certificate.
Download this file, which will end in .cer to the root of the c: drive. Let’s call it newcert.cer for sake of discussion.
Then use the following powershell command to install the certificate.
For Exchange 2007 type:
Import-ExchangeCertificate -Path C:\newcert.cer
You will see it echo back the thumbprint of the certificate, highlight the thumprint and put it in the clipboard.
For Exchange 2010 type:
Import-ExchangeCertificate -FileData ([Byte]$(Get-Content -Path c:\certs\your_domain_name.cer -Encoding byte -ReadCount 0))
For both version of Exchange, the command to enable the certificate is:
Enable-ExchangeCertificate -Thumbprint xyxxyxyxyxy -Services SMTP, IIS
Where the xyx… is the thumbprint you put in clipboard.
Test it by accessing owa, https://servername.internaldns.local/owa on the server and viewing the certificate in the browser.
You can also test it by performing a telnet to the server’s ip address, port 25 and issue a starttls command.
That’s pretty much it for the cert generation. You can delete the private self generated cert if you want. The biggest problem people run into is the powershell code.