We have several Exchange 2013 servers in the AD domain with a local CA installed and configured correctly. Every Exchange server has SSL certificates generated for it by the CA. Those certificates are attached to the services by using Set-ExchangeCertificate. However, during installation Exchange generates its own self-signed certificates and attaches them to the same services.

The final picture can look like this (Mailbox server role):

[PS] C:\temp>Get-ExchangeCertificate

1BBD5EE99EF8FA6C17977DAF9A40D611292482D9  IP..S..    CN=SERVER.org.com
50C52CB800E8D75E2972EB4B31E9D6E3125136F5  IP.WS..    CN=SERVER.org.com, O=Org, C=Com
CF10F109E60D735F16ED7300ACF3C00715458C71  ....S..    CN=Microsoft Exchange Server Auth Certificate
B1129A00CDCA7A588F7C90DB67E56248821AE879  IP..S..    CN=SERVER
33BAA0348B8C0BC6A1F3E1951220CDA9DB29F649  .......    CN=WMSvc-SERVER

As we can see, all the certificates except the  last one are attached to the SMTP service, for example. Three of them are attached to the IMAP service.

The question is, how Exchange chooses one of the certificates attached to the same service? Is it safe to remove one of multiple certificates (the self-signed one, in particular) on th

Hi Evgeniy,

Microsoft says - When you install Exchange 2013, a self-signed certificate is automatically configured on the Mailbox servers. A self-signed certificate is signed by the application that created it. The subject and the name of the certificate match. The issuer and the subject are defined on the certificate. This self-signed certificate is used to encrypt communications between the Client Access server and the Mailbox server. The Client Access server trusts the self-signed certificate on the Mailbox server automatically, so no third-party certificate is needed on the Mailbox server. When you install Exchange 2013, a self-signed certificate is also created on the Client Access server. This self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere won't work with a self-signed certificate on the Client Access server. Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. If the client confirms the trust, then SSL communications can continue.

By default, the digital certificate installed on the Mailbox server or servers is a self-signed certificate. You dont need to replace the self-signed certificate on the Mailbox servers in your organization with a trusted third-party certificate. The Client Access server automatically trusts the self-signed certificate on the Mailbox server and no other configuration is needed for certificates on the Mailbox server.

So, making long story short -

1. You might want to bind all services a specifically designed SAN or wildcard certificate from external/internal CA;
2. Normally you don't need to remove default Exchange certificates, as they do not present any problems for normal Exchange functionality.

> Normally you don't need to remove default Exchange certificates

Normally, yes. With a little addition: while they are valid. ;) Any certificate tends to expire sooner or later, and expired certificates aren't removed automatically.

However, this is not what I'm asking about. The main question is, how Exchange chooses from the list of certificates assigned to a specific service?

Right now my CAS and mailbox servers have several certificates attached to the web and IMAP services. In particular, the CAS servers have a normal certificate generated by our CA with all the required SAN names, as well as a self-signed certificate generated by Exchange itself during the server deployment process. The latter one is going to expire in two weeks, and I have corresponding warnings in the EAC. What will happen if I remove the expiring certificates right now? I know how to check the web interface (the certificate properties can be viewed in a web browser), but what about IMAP? Disruption of service and the mail system downtime would be much unappreciated.

Hi Evgeniy,

I notice that you want know how client select Exchange certificate. SMTP STARTTLS, POP3, and IMAP4 all perform a similar selection process to determine which certificate to use for a particular session.

To advertise or use STARTTLS, Exchange selects a certificate based on the FQDN and a matching value in the CertificateDomains field of a certificate, then Exchange searches Personal certificate store on the host computer for all valid certificates. If more than one valid certificate is found, Exchange selects a certificate based on the following criteria: The value in the NotBefore field or Certificates issued by a trusted CA vs. self-signed certificates.

More details please refer to Certificate selection section in Certificate Use in Exchange Server 2007:
https://technet.microsoft.com/en-us/library/bb851505(v=exchg.80).aspx

Best Regards,
Allen Wang

• Marked as answer by Evgeniy Lotosh 6 hours 15 minutes ago

Allen,

Thank you for the explanation and the link. Really, my question is answered with the single sentence:

> In most cases, Exchange selects a certificate issued by a trusted CA over a self-signed certificate regardless of the age of the certificate.

That's all I wanted to know. Thanks again.