Monday, June 11, 2012

Renewing the Self-Signed Certificate: Exchange Server 2007

This is another perfectly written article that I have borrowed on this subject.  I got it from Exchangepedia and the author Bharat Suneja deserves all the credit.
Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.
The self-signed certificate meets an important need – securing communication paths for Exchange services by default. Nevertheless, one should treat these certificates as temporary. Although the self-signed certificates work perfectly well for internal SMTP communication between Hub Transport servers, and between Hub Transport and Edge Transport servers, it’s not recommended to use them for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).
Should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these will need to be renewed when they expire — just as you would renew certificates from 3rd-party or in-house CAs.
 1. To renew the certificate for server, a server with CAS and HT roles installed:
Get-ExchangeCertificate -domain “” | fl
Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.
Get a new certificate with a new expiration date:
Get-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F” | New-ExchangeCertificate
To create a new certificate with an exportable private key, use the PrivateKeyExportable parameter. For example:
New-ExchangeCertificate -PrivateKeyExportable $true
If the existing certificate is being used as the default SMTP certificate, you will get the following prompt. The default SMTP certificate is used to encrypt SMTP sessions between transport servers in your organization.
Overwrite existing default SMTP certificate,
‘C5DD5B60949267AD624618D8492C4C5281FDD10F’ (expires 8/22/2008 7:20:34 AM), with certificate ’3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E’ (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is “Y”):
Type y to continue. A new certificate is generated.
Thumbprint   Services   Subject
———-   ——–   ——-
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   …..   CN=E12Postcard
The new certificate is generated and enabled. Examine the new certificate:
Get-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” | fl
2. The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP – IIS is missing.
You can enable the certificate for IIS (in addition to any other services it may already be enabled for — it adds to existing values of the certificate’s Services property).
Note: Once you enable a certificate for a particular Exchange Server service, there’s no way to disable it (for that service). You must remove the certificate (if the certificate is CA-issued, export the certificate along with its private key before you do so), import it again and enable it for the services you need to. This is generally not a concern with self-signed certificates— you can generate additional self-signed certificates and optionally remove the old one, since there’s no CA interaction or costs involved.
Setting the Services parameter to None does not do anything in this case.
To enable the certificate for IIS:
Enable-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” -services IIS
3. Test services are working with the new certificate. If it works as expected, the old certificate can be removed:
Remove-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F”

No comments: