Renew self-signed certificates in Exchange 2010 and Exchange 2007

by Bharat Suneja

In Exchange 2007 and later, Exchange Setup creates a self-signed certificate to protect communication with Exchange services such as SMTP, IMAP, POP, OWA, EAS, EWS and UM.

Exchange’s self-signed certificates meet an important need – securing communication paths for all Exchange services by default.

The self-signed certificate meets an important need – securing communication paths for all Exchange services by default. This is a great development – it ensures that out of the box, Exchange does not transfer any data in the clear and all communication is encrypted.

Nevertheless, one should treat these certificates as temporary. Although 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 purchasng a certificate from a trusted public CA (or perhaps an internal CA in organizations with PKI deployed). See the Certificates and Certification Authorities secton for more info.

Should you decide to leave the self-signed certificate(s) on some servers and continue to use them, you would need to renew them when they expire — just as you would renew certificates from public or private CAs. The good news is that with Exchange 2010, Microsoft raised the validity of Exchange’s self-signed certificates to five years, so most organizations wouldn’t need to renew them frequently. In Exchange 2007, the self-signed certificate is valid for one year.

  1. Copy the thumbprint from existing self-signed certificate: This command retrieves the existing certificate for server postcard.e15labs.com:

    Get-ExchangeCertificate -Domain postcard.e15labs.com | 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.

  2. Generate a new self-signed certificate: This command pipes the existing certificate object to the New-ExchangeCertificate cmdlet, which uses its properties to generate a new self-signed certificate.

    Get-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F” | New-ExchangeCertificate

    Exporting a certificate with its private key

    If you want to be able to export a certificate with its private key for backup or to install it on another server (although this is generally done only for CA-signed certificates), create the new certificate with an exportable private key by using 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.

    Confirm
    Overwrite existing default SMTP certificate,
    ‘C5DD5B60949267AD624618D8492C4C5281FDD10F’ (expires 5/13/2013 7:20:34 AM), with certificate ‘3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E’ (expires 5/13/2018 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=Postcard

  3. The new certificate is generated and enabled. Examine the new certificate:

    Get-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” | fl

  4. Enable the new certificate for IIS: 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).

    Before you enable a certificate for an Exchange service

    Before you enable a certificate for a particular Exchange Server service such as IIS (which enables it for all HTTPS services – Outlook Anywhere (RPC over HTTPS), OWA, EAS, and EWS), know that it’s a one-way street. There’s no way to disable the certificate (for that service). Setting the Services parameter to None does not do anything in this case.

    The workaround: Remove the certificate. If it’s a CA-issued certificate, remember to export it with its private key before you remove it, and then import it again and enable it for the Exchange services you need to. If the certificate is self-signed, it shouldn’t be a concern — you can generate as many self-signed certificates as you want.

    To enable the certificate for IIS:

    Enable-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” -services IIS

  5. Remove the old certificate: Test services are working with the new certificate. If it works as expected, you can remove the old certificate using the EMC or the Remove-ExchangeCertificate cmdlet from the Shell.:

    Remove-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F”

Certificates and Certification Authorities

Digital certificates are signed by certification authorities (CAs) that issue them. They can be classified into three types based on who signs them.

  • Certificates signed by public CAs: Public CAs provide certification services, generally for a fee (although there are non-commercial public CAs), to the public. A public CA is generally trusted by device operating systems. It’s recommended to use certificates issued by a public CA for public services (including public web sites) and private services in mid/large organizations that don’t have an internal CA.
  • Certificates signed by private CAs: Many organizations set up a private CA to issue certificates internally or to members of a private group. Windows Server has included Certificate Services since many versions. This allows IT departments to control certificate issuance/revocation to their devices and users. Devices controlled by the organization (for example, computers that are part of the org’s Active Directory domain) can be configured to trust the org’s internal CA.

    Note: Internet standards make no distinction between certificates signed by public CAs and private or internal CAs.

  • Self-signed certificates: Self-signed certificates are signed by the device or service itself. Exchange Server 2007 and later create a self-signed certificate during Exchange setup. By default, self-signed certificates are not trusted by anyone but the device/service that creates it. Most browsers alert users about untrusted certificates when they visit a site using HTTPS.
    Screenshot: Self-signed certificate created by Exchange Server setup
    Figure 1: A self-signed certificate created by Exchange Server setup

Self-signed certificates are great for securing communication by default and handy for test environments. For client communication in production environments, it’s recommended to use certificates signed by a trusted CA. The cost of certificates from public CAs has come down significantly over the years. Most small and many mid-size organizations find it much more cost-effective to use a public CA.

Related posts:

{ 3 comments… read them below or add one }

Alessandro Spiandore June 8, 2016 at 1:33 am

Thanks!

Reply

David Guirl September 12, 2016 at 7:24 am

This article explains better the relationship between the Public cert and the Self-Signed certs.

http://www.msexchange.org/articles-tutorials/exchange-server-2013/management-administration/managing-certificates-exchange-server-2013-part1.html

or search “site:msexchange.org managing certificates exchange server 2013”

Reply

Bharat Suneja September 12, 2016 at 3:57 pm

Thanks for the feedback. This article isn’t meant to be an exhaustive reference on certificates.

Reply

Leave a Comment

{ 1 trackback }

Previous post:

Next post: