I’m currently heading an Exchange 2007 to Exchange 2013 migration at work and I’m going to share the thoughts and notes that I’ve made on the process so far.
The actual install process was fairly painless to be fair, with one CAS and two Mailbox servers currently configured, but I have encountered one problem with certificates that I thought I would share:
We required a new Unified Comms certificate as part of the rollout, so I used the Exchange Admin Centre (EAC/ECP) to generate a Certificate Signing Request on the CAS server. This generates a CSR on one of your servers which you can then submit to your signing authority.
Once the certificate arrived, I used the Exchange EAC gui to import it onto all our exchange servers, and was told this had completed successfully.
This is when I run into problems. The certificate was visible on the CAS, where the CSR was generated from, but not on the two Mailbox servers. No errors were shown in the CAS or visible in the logs on any of the servers, and an attempt to import the certificate directly onto either of the servers where it wasn’t showing up failed, reporting that the certificate was already installed. This continued even after exporting and removing the certificate from the CAS and starting the import process again.
This is where it gets interesting. I fired up the certificate MMC snapin on one of the mailbox servers and can see the certificate I had just imported. On closer inspection, however, it didn’t have the private key installed, which makes the certificate useless.
With this in mind, I removed the certificate from both mailbox servers, exported a new copy from the CAS, ensuring that the private key was present. I then decided that I would import the certificate using powershell, to make sure I had better feedback on what was happening.
So the steps to import a certificate into Exchange 2013 and make sure it’s set up correctly:
Ensure you’ve already removed the certificate if you’re trying to import it again to troubleshoot a problem.
Import the certificate using the import-ExchangeCertificate powershell command – Example:
Import-ExchangeCertificate -Filedata([Byte]$(Get-Content -path \\exchangeserver\share\e2013-cert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password
This imports a certificate from the file e2013-cert.pfx from the file share \\exchangeserver\share (note that you need to use a UNC path here). You will need to type in a password during this import process as one is required for a file storing both a certificate and its private key.
Use get-Exchange-Certificate to list the installed certificates. Verify that your certificate is in the list and make a note of its thumbprint.
Use enable-ExchangeCertificate to assign a certificate to secure a particular role or roles as needed – Example:
Enable-ExchangeCertificate -Services IMAP,POP,IIS,SMTP -Thumbprint YOUR_THUMBPRINT_GOES_HERE
This will enable the certificate with the thumbprint you specify to secure comms over IMAP, POP3, IIS and SMTP.
You’re now nearly ready to go. You should now be able to refresh the view in the Exchange EAC and see the certificate you’ve just installed listed. There’s just one problem… it’s listed with a blank name because importing a certificate into Exchange, whether via powershell or EAC, doesn’t seem to allow you to set the friendly name.
This is especially problematic if you’re setting up a hybrid exchange/office365 deployment, as you will need to select the right certificate by friendly name if doing so via the EAC.
Luckily this can be done easily in powershell… much easier than using the certutil command line.
To edit certificates in the personal store of the server itself run the following powershell commands:
You’ll need the thumbprint of the certificate, but luckily you have that handy from following the steps above right? The two lines below will select the correct certificate by thumbprint (stored in the $cert variable) and change the friendly name to one you specify:
$cert = GCI YOUR_THUMBPRINT_GOES_HERE
$cert.FriendlyName = “My.Server.Com”