If you would like to read the other parts in this article series please go to:
Certificates can be used to encrypt the communication flow between two endpoints, which can be both clients and servers. Certificates can also be used by these endpoints to authenticate themselves against each other. There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In the first part of this article I provided you with an overview of the different Exchange components that use certificates and for what purpose. I also went into detail covering the features of the by-default generated self-signed certificate. In the second part of the article I covered the requirements of a certificate you need to keep in mind when getting your certificates. And to end, in part 3 of this article I would like to give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
Exchange Cmdlets for managing certificates
Exchange Management Shell offers you a set of cmdlets you can use to manage certificates in your Exchange environment:
In part 2 of this article series, I described a given Exchange organization, for which we need to get 2 Exchange certificates, as summarized in Table 1 below.
Subject Alternative Names
Required for Services
Table 1: Certificate Requirements
The Exchange Management Shell cmdlet New-ExchangeCertificate can be used to create a new self-signed certificate or can be used to create a new certificate request, which can be forwarded to your Certification Authority and afterwards imported and enabled for SMTP (Transport Layer Security (TLS)) and/or IIS, POP, IMAP, and UM (so-called Secure Sockets Layer (SSL) services).
The key parameter that will cause the cmdlet New-ExchangeCertificate to generate a new self-signed certificate or to generate a request, is called GenerateRequest. If you omit this parameter, a new self-signed certificate will be created by Exchange, as can be seen in Figure 1. If you add this parameter, Exchange will create a certificate request for a PKI certificate (PKCS #10) in the local request store.
Figure 1: Create a new Self-Signed Certificate
When creating a certificate request, the following list of parameters can be added:
SubjectName - entered as a X.500 distinguished name, which contains the most important property of a certificate, the common name. The subject name is the field that is used by DNS-aware services, and will actually reassure the DNS-aware service that the certificate has indeed been issued for the requested server or domain name;
DomainName - used to add any additional Subject Alternative Names to the certificate. You can add multiple domain names separated by a comma, but every domain name itself is limited to 255 characters each;
IncludeAcceptedDomains - will add all accepted domains configured in the Exchange organization as subject alternative name (when names are defined both using the DomainName parameter, and using this switch parameter IncludeAcceptedDomains, they will only appears once in the certificate request)
IncludeAutoDiscover - will add for every domain name the subject alternative name autodiscover.domainname. Two side notes here:
- When names are defined both using the DomainName parameter, and using this switch parameter IncludeAutodiscover, they will only appears once in the certificate request
- This parameter can only be added when running the cmdlet on an Exchange Client Access server
Keysize - can be used if you want to specify a different size of the RSA public key associated with the certificate you are creating. If omitted, a default value of 2048 bits will be taken, but you can add the parameter and set the value to 1024 bits, 2048 bits, or 4096 bits;
Path - where you want the certificate request to be stored. You need to specify both the path and a filename (file type .req);
PrivateKeyExportable - can be used to generate a certificate (and/or request) with an exportable private key. If omitted, the private key will not be exportable. By adding this parameter and setting its value to True, you will be able to export the certificate and import it on another Exchange server and/or ISA box;
BinaryEncoded - can be used to change the by default via Base64 encoded export file to a DER-encoded file;
Services - can only be used when generating a new self-signed certificate to define which services (IIS,SMTP,POP,IMAP,UM) will use the new self-signed certificate. Default value for this parameter is set to SMTP (as can be seen in Figure 1), by setting its value to None you can generate a new self-signed certificate without enabling it for any service;
FriendlyName - can be used to give your certificate another name than the default "Microsoft Exchange", it is limited to 64 characters.
Given our Exchange organization, we need to create two certificate requests. As can be seen in Figure 2, both certificate requests will be generated on our Exchange HUB/CAS/MBX server, called Ex2007EE. One certificate request, called secure_smtp.req will be used for SMTP, and the other one, called secure_client.req will be used for IIS, and UM. To make sure both certificates can be exported and shared, the private key will be set to be exportable.
Figure 2: New-ExchangeCertificate
These two certificate requests can now be delivered to the certification authority of choice, and after receiving the certificates, they can then be imported and enabled for the required services.
Enabling EdgeSync, check the following TechNet article
When enabling EdgeSync you need to keep the following TechNet article in mind, entitled "EdgeSync Fails with Event ID 10104", which clearly states that the Hub and Edge Transport servers do not support the use of the same certificate!
The Import-ExchangeCertificate cmdlet allows you to import a certificate, which can be useful when:
you want to import a previously exported certificate
you want to import a certificate file generated by a certification authority
There are two important parameters which you should remember when running the cmdlet Import-ExchangeCertificate:
Password - to enter the password that was used to encrypt the private key when exporting the certificate
Path - to specify the location where you stored the certificate file received from a CA
Once the certificate has been imported, you need to enable it for a service, by running the cmdlet Enable-ExchangeCertificate.
By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.
Every service has different metadata requirements, and will have different properties updated:
POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
IIS: Default Web Site will be updated;
SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
UM: certificate property will be updated to include Unified Messaging.
After receiving our two requested certificates, you can see in Figure 3 that they are imported, and in the same line, enabled for their required services.
Figure 3: Import-ExchangeCertificate
To get a list of all certificates that are available in your local certificate store, you can run the cmdlet Get-ExchangeCertificate. You can use this cmdlet to review the certificate fields that are used by the Exchange services (Figure 4) like:
Issuer: who issued the certificate
Subject: Common Name of the certificate
CertificateDomains: Subject Alternative Names defined on the certificate
NotBefore: defines the date and time from when the certificate can be used
NotAfter: defines the date and time when the certificate expires
IsSelfSigned: to see if the certificate is a self-signed certificate or not
RootCAType: defines the kind of CA that issued the certificate
Services: for which services the certificate is enabled for
Status: defines if the certificate is valid or not
Thumbprint: a digest of the certificate data
Figure 4: Get-ExchangeCertificate (SMTP)
Figure 5: Get-ExchangeCertificate (IIS,POP,IMAP)
In order to export a certificate (whether for backup purposes, or for using it on multiple servers), you can use the cmdlet Export-ExchangeCertificate. Running the cmdlet will export an exchange certificate and its private key by default.
It is also possible to use this cmdlet as well to export a certificate request. When running the cmdlet, Exchange will investigate the certificate to export (by using its thumbprint), and if it is a certificate request export it as a PKCS #10 file. If it is a certificate, the certificate will be exported to a PKCS #12 file.
There are two parameters to be kept in mind when running the cmdlet Export-ExchangeCertificate:
Path: to define a target location and file name to store the exported file, remember to enter a .req file extension for exporting a certificate request, and .pfx or .p12 for exporting a certificate;
Password: to protect the private key, has to be entered as a secure string (different methods can be used to set the password, as can be seen in Figure 6 and 7).
In our Exchange organization, I need to export both certificates to make sure they can be used multiple times. First I will export the one used for providing TLS, and import it on the Edge server role and enable it for SMTP, as shown in Figure 6. Then I will export the one used for IIS, POP, and IMAP, and import it on my Unified Messaging Server role, to enable it for UM, as shown in Figure 7 and 8, and I will import it and configure ISA to use it for publishing Outlook Web Access, and Outlook Anywhere.
Figure 6: Export-ExchangeCertificate (SMTP)
Figure 7: Export-ExchangeCertificate (IIS,POP,IMAP)
Figure 8: Import-ExchangeCertificate (UM)
Once you have enabled the required certificates for every service, you can choose to remove any un-needed certificate from Exchange server and the local certificate store by running the cmdlet Remove-ExchangeCertificate. If the certificate that you are removing is stored in Active Directory directory service, this instance will be removed as well.
Figure 9 shows you how you can remove all self-signed certificates at once.
Figure 9: Remove-ExchangeCertificate (Self-Signed)
Validate your Certificate configuration
After getting the required certificates, and configuring your Exchange services to use them, it is time to test if everything is working as planned.
Figure 10 shows you that Outlook Web Access and Outlook Anywhere work fine, using the required certificate.
Figure 10: Certificate properties
And the desired Domain Security feature with organization Sunshine.Edu, is configured as planned, as can be seen in Figure 11 and 12.
Figure 11: Domain Security
Figure 12: Domain Security
In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate has in stall. In this second part of the article I have shown you how you can trust the self-signed certificate and which names your Exchange certificate needs to have before you can successfully use it. In part 3 of this article I have given you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
If you would like to read the other parts in this article series please go to: