Exchange 2007 presents new challenges on the front of SSL certificates - we know now that we need to include multiple names into our certificates to make all the features of this great new server system work. We also know its certainly never a best practice to keep the self signed exchange certificates which are deployed with the exchange installation.

So how to we generate the new Certificate Requests & who do we submit them to?

Well the easiest way to generate the certreq with multiple Subject Alternative Names is from within the Exchange Management Shell. As for the names to include, well that's entirely upto your deployment & environment.

The commandlet used is New-ExchangeCertificate and the syntax is something like this:

New-ExchangeCertificate -DomainName webmail.fjdent.com, webmail.fjd.local, mbxhubcas.fjd.local -FriendlyName "F J D Enterprises" -GenerateRequest:$True -Keysize 1024 -IncludeAutoDiscover -path c:\fjdent.req -privatekeyExportable:$true -subjectName "c=ae, o=Johan Dreyer, CN=webmail.fjdent.com"

Now the above commandlet will generate a certreq for a certificate to be issued to the server named webmail.fjdent.com (public CAS Access) with Subject Alternative Names included for webmail.fjd.local (internal CAS access), mbxhubcas.fjd.local (Exchange 2007 Server Internal FQDN), autodiscover.fjdent.com, autodiscover.fjd.local & autodiscover.AnyOtherExchangeAutoritativeDomain.com

* Note that should you can use the -Force switch to force the commandlet to overwrite existing files with the same name in the path specified.

So now you have the Certificate Request file, what do you do with it? Well you have 2 options here, you can either submit it to a Public Trusted Certification Authority which supports issuing certificates with Subject Alternative Names, one such CA is EnTrust, or you could submit it to your internal MS Certificate Server.

Now if you go the public CA Route then you have not much to worry about, except meeting their verification criteria to get the certificate/s issued.

However, if you plan on using your internal CA to issue the certificate you would need to enable this functionality on that server first. This is because MS Certificate Services is not configured by default to issue certificates with multiple SAN's.

The good news is its pretty easy to do, on your Certificate Server just run the following commands:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Since I do this for multiple clients / lab environments I have copied these commands to notepad & saved the batch file on my USB Memory stick - now I just plug my memory stick into the CS & run the batch.

Once you have done this you can now submit your certificate request to the internal CA & have it issue your Exchange Compliant SAN Certificate.

Note that the clients would need to have the CA Root Certificate installed in the Trusted Root Certification Authorities store of their local computer to avoid getting the untrusted certificate error in their browser- Outlook does not check the trust status of a certificate, only the availability & validity there of. 

To use an internal certificate with Windows Mobile based devices, you should export the CA Root Certificate in DER format, copy it onto the device & install it. WM  Devices will NOT connect to any server which is using a certificate that it does not trust!