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. 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. Note: Once you enable a certificate for a particular Exchange Server service, there’s no way to disable it (for that service). 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). The new certificate generated using the above command is enabled only for POP, IMAP and SMTP – IIS is missing. Get-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” | flĢ) The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate is generated and enabled. Yes Yes to All No No to All Suspend Help Overwrite existing default SMTP certificate, The default SMTP certificate is used to encrypt SMTP sessions between transport servers in your organization. If the existing certificate is being used as the default SMTP certificate, you will get the following prompt.
#Exchange 2010 renew self signed certificate install#
If you want to be able to export a certificate with its private key for backup (or to install it on another server in some cases, although this is generally done only for CA-signed certificates), create the new certificate with an exportable private key by using thePrivateKeyExportable parameter.įor example :–> New-ExchangeCertificate -PrivateKeyExportable $true Get a new certificate with a new expiration date: Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers).
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.ġ) This command renews the certificate for server , a server with CAS and HT roles installed: For client communication in production environments, it’s recommended to use certificates signed by a trusted CA. Self-signed certificates are great for securing communication by default and handy for test environments. For most deployments, you will end up purchasng a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed). 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. Nevertheless, one should treat these certificates as temporary. This is a great development – it ensures that data will not be transferred in the clear by default and all communication is encrypted. The self-signed certificate meets an important need – securing communication paths for Exchange services by default. In Exchange 2010, the certificate validity period is raised to five years.
In Exchange 2007, the certificate is issued for a period of one year. Exchange 2010 and Exchange 2007 Setup creates a self-signed certificate for the server to protect communication with services like SMTP, IMAP, POP, IIS and UM.