Обновление самоподписанного сертификата Exchange 2010

Чуть позже переведу :)



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.

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

Get-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” | fl

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.

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.

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

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

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 Servicessince 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.

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.