Security, Security, Security!! As you may have noticed, a “big deal” in IT is security, not the least of which is related to email security. Microsoft has made some great strides regarding the out of the box security of Exchange 2007 versus its predecessor. First, you may have noticed that when you access OWA you are presented with a certificate. Don’t remember installing one? Exchange 2007 setup did when you installed it. It creates a self signed certificate to secure OWA, as well as opportunistic TLS for SMTP transmissions, and all the Exchange Web Services.
As you no doubt already know, self signed certificates create a little bit of a problem. They are un-trusted, and do not have the correct subject name for the resource. You’ll find that there are three rules for certificate usage.
- The Certificate Authority has to be trusted. This means that the company or computer that is issuing the certificate, is trusted by your PC and/or browser. Third party certificate authority like Network Solutions and Go Daddy are generally trusted by most browsers.
- The certificate has to be valid. This means the time period, 11/01/2008 – 11/01/2009 must be valid.
- The certificate’s subject name has to be correct. This is where most people get into trouble. We will cover this in the article.
In our domain Ponzeka.test, we have a certificate authority NYDC01.ponzeka.test, that we will use to issue our certificates. Since we will be accessing the Exchange end user environment from outside the domain, we need to get our PC to trust the CA. Do this by installing the CA root certificate into your PC.
We can access our Windows CA by navigating to http://nydc01/certsrv since we installed the web services with our CA. Select “download a CA certificate”
Save the .cer file to your desktop, and then run it, select Install Certificate, select Next all the way through. When you get a warning message regarding installing the certificate, simply hit yes.
Your pc now trusts any certificate issued by this Certificate Authority!
Now, securing our environment. Let’s talk a little about Subject Alternative Name (SAN) certificates.
In a certificate, a Subject Name is the name of the server that the certificate is issued to. This also is the name the server is accessed by. What do I mean? Consider the following diagram:
Here, users on the internet access NYHT01.ponzeka.test as https://ponzeka.selfip.com/owa for OWA access. What is the Subject Name? Ponzeka.selfip.com is. When you request the certificate for this server, you should request this name. That way when users access it, their browser will match up the URL with the subject name that is listed in the certificate. If it is off, your browser will prompt you with a warning.
Now, SAN certificates alleviate a problem. What happens if a user internal to the ponzeka.test network tries to access the OWA page on NYHT01.ponzeka.test as https://nyht01.ponzeka.test/owa? Their browser will return an error, because the subject name is incorrect. This becomes important in Exchange 2007 because there are various web services that are accessed through Https internally, and if the certificates are wrong, users will constantly be prompted in outlook. We will go over more of these later.
SAN certificates allow you to list multiple subject names in the certificate. So you can list the external DNS name, internal DNS name, NetBIOS name, cluster DNS name, alias, and well you get the point.
For instance, remember from my previous post that we have joined NYHT01.ponzeka.test and NYHT02.ponzeka.test into an NLB cluster for the HT and CAS roles. The NLB is accessed as mail.ponzeka.test. We will add this as a subject name to our certificate request. Let’s start with NYHT01.ponzeka.test.
As noted before, when you install exchange, you get a self signed certificate for the server. This is the one that comes with NYHT01:
As you can see it was issued by NYHT01 to NYHT01. If we click details, and navigate to Subject Alternative Name, these are the names that the certificate is valid for:
NYHT01 (the NetBIOS name) and NYHT01.ponzeka.test (the DNS name).
Also, on NYHT01 in the application log, you will find an error under MSExchangeTransport Transport Service Event ID 12014:
This is stating that the system is unable to find a certificate for the domain name “mail.ponzeka.test”, which is the NLB name in this case. Since it cannot find one, it cannot use the STARTTLS command in SMTP usage to encrypt the connection. Let’s go about creating our SAN certificate request!
We need to do this request through the Exchange Management Shell.
You need to run the following command, it’s pretty long:
new-exchangecertificate –generaterequest -domainname ponzeka.selfip.com,nyht01,nyht01.ponzeka.test,mail.ponzeka.test -friendlyname "san certificate" -keysize 1024 -path c:sanrequest.txt -privatekeyexportable:$true
Now the blog format messes with the command, so here is the screen shot:
The –domainname option allows you to specify extra names for the server, as you can see we specified NYHT01, NYHT01.ponzeka.test, mail.ponzeka.test, and ponzeka.selfip.com. It created a request that we can send to a CA at c:request.txt.
Submit this request to the CA page at http://nydc01/certsrv, and select “request certificate”
Select “Advanced Certificate Request” and then “Submit a certificate request by using a …”
Open your request and past all of the data into the box.
Now hit the submit button:
You will get a message stating that you need to way for an approval from an administrator. If you open up the Certificate Services MMC, go to pending approvals, right click yours and hit Issue, you’ll be able to come back here and download your certificate!
Download the certificate to your C drive as certificate.cer.
Now we are ready to import the certificate. Again this has to be done through the Exchange Management Shell. Run the following command:
Import-ExchangeCertificate c:certificate.cer | Enable-ExchangeCertificate –Services IIS,SMTP,POP,IMAP
Okay, what was that!!?!?!? What I did in this command is called “piping”. Since powershell, and thus the Exchange Management Shell is an object oriented language, I can take the output of one command (in this case Import-ExchangeCertificate c:certificate.cer) and make it the input of the next command (in this case Enable-ExchangeCertificate –services IIS,SMTP,POP,IMAP). If I didn’t do this, I would have to run the first command. It would list the thumbprint of the certificate, I would then have to use that in a separate command to enable it, which is quite cumbersome. This way I do it all at once! Also, as you can see I am enabling the certificate for use with IIS for OWA, SMTP, POP and IMAP services. If you were using the Unified Messaging role you could use UM for that as well. Hit return. You may get a warning asking you to overwrite the existing self signed certificate, hit yes.
Okay, we are set, the certificate is installed! Now lets check it out. Check out the details again, go to Subject Alternative Name and you’ll see the names we entered earlier:
There are all the names that it will work for. Now let’s test it out!
What happened here?
Well, remember we have a NLB cluster between NYHT01 and NYHT02. We must have hit NYHT02 during this session and it’s still using the old self signed certificate. Follow the steps above to create a new SAN certificate for NYHT02, and no more warnings!!
In my next article I’ll show you how with certificates we can set up and use some of the exciting new Exchange Web Services with Outlook 2007, as well as go over some TLS over SMTP!!