Event ID 12014: Exchange can't find a TLS certificate for a connector FQDN

Event ID 12014 means a connector has no usable certificate for the name it's configured with, so it can't offer STARTTLS. Exchange Online, partners and smart hosts that insist on TLS stop exchanging mail with that server, often right after a certificate renewal. In this post I'll show how to read the event, find the mismatch, fix the binding and prove TLS is back.

Symptoms#

The Application log repeats this error. The source is MSExchangeFrontEndTransport or MSExchangeTransport, depending on which service owns the connector:

Log Name:      Application
Source:        MSExchangeFrontEndTransport
Event ID:      12014
Task Category: TransportService
Level:         Error
Description:   Microsoft Exchange could not find a certificate that contains the domain name mail.contoso.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Frontend EX01 with a FQDN parameter of mail.contoso.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Related signs:

• The EHLO response on port 25 has no 250-STARTTLS line.
• Mail from Exchange Online (hybrid) or TLS-enforcing partners queues on their side.
• Outbound queues sit in Retry with 454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found.
• The send protocol log shows TLS negotiation failed with error UnknownCredentials (a certificate named on the connector isn't enabled for SMTP).

Why it happens#

Before a connector can use STARTTLS, the transport service must pick a certificate for it. Simplified:

• If the connector has a TlsCertificateName (format <I>issuer<S>subject), Exchange wants exactly that issuer and subject.
• Otherwise it wants a certificate whose subject or SAN list contains the connector's Fqdn, or the server's FQDN when that value is empty.
• The match must be in the Local Computer Personal store, trusted, in date, and have a private key the transport service can read; enabling it for SMTP grants that access.

Typical triggers:

• A renewed certificate replaced the old one, but TlsCertificateName on the Default Frontend or "Outbound to Office 365" connector still describes the old one. A new CA intermediate changes the issuer string even on a like-for-like renewal.
• The new certificate isn't enabled for SMTP, or exists on only one server.
• It was imported without its private key, or the intermediate is missing, so Status isn't Valid.
• The self-signed "Microsoft Exchange" certificate, used by the built-in connectors, expired or was deleted.
• A connector's FQDN was changed to a name no certificate covers.

How to fix it#

1. Put connectors and certificates side by side#

Take the connector name and server from the event, then compare:

Get-ReceiveConnector -Server EX01 | Format-Table Name, TransportRole, Fqdn, TlsCertificateName -AutoSize
Get-SendConnector | Format-Table Name, Fqdn, TlsCertificateName, RequireTLS -AutoSize
Get-ExchangeCertificate -Server EX01 | Format-List FriendlyName, Thumbprint, Subject, Issuer, CertificateDomains, NotAfter, Services, Status, HasPrivateKey

Good looks like: the expected certificate lists the name in CertificateDomains, with Status : Valid, HasPrivateKey : True, a future NotAfter and SMTP in Services. Any TlsCertificateName matches its issuer and subject character for character.

2. Enable the right certificate for SMTP on every server#

Enable-ExchangeCertificate -Server EX01 -Thumbprint <NewThumbprint> -Services SMTP

When asked whether to overwrite the existing default SMTP certificate, answer No: that keeps the self-signed certificate for internal transport, and Microsoft warns that overwriting it can break EdgeSync. Repeat on every server that logs the event; where the certificate is missing, export it with its private key from another server and import it first.

3. Repoint TlsCertificateName at the new certificate#

$cert = Get-ExchangeCertificate -Server EX01 -Thumbprint <NewThumbprint>
$tlsName = "<I>$($cert.Issuer)<S>$($cert.Subject)"
Set-ReceiveConnector "EX01\Default Frontend EX01" -TlsCertificateName $tlsName
Set-SendConnector "Outbound to Office 365" -TlsCertificateName $tlsName   # use your connector's exact name

In hybrid, Microsoft's alternative is to clear the receive connector value (-TlsCertificateName $null) and re-run the Hybrid Configuration Wizard with the new certificate so it rewrites the hybrid connector settings. See renewing the hybrid certificate without breaking mail flow.

4. Change an FQDN only on connectors you created#

For a partner-facing or custom connector whose FQDN isn't on any certificate, bind one with TlsCertificateName or set the FQDN to a covered name: Set-ReceiveConnector "EX01\Partner TLS" -Fqdn mail.contoso.com.

5. Replace an expired or deleted self-signed certificate#

If the event names the server's own FQDN (for example ex01.contoso.local) on Default EX01 or Client Proxy EX01, replace a missing or expired self-signed certificate:

Get-ExchangeCertificate -Server EX01 | Where-Object { $_.IsSelfSigned } | Format-List FriendlyName, Thumbprint, CertificateDomains, NotAfter, Services
New-ExchangeCertificate -Server EX01 -FriendlyName "Microsoft Exchange" -DomainName ex01.contoso.local, ex01 -Services SMTP

This time accept the overwrite prompt: the old default is the broken one. With Edge Transport, re-create the Edge Subscription afterwards.

6. Restart transport and retry the queues#

Restart-Service MSExchangeFrontEndTransport, MSExchangeTransport
Get-Queue -Server EX01 | Where-Object { $_.LastError -like "*TlsCertificateName*" } |
  ForEach-Object { Retry-Queue -Identity $_.Identity }

The restart briefly interrupts SMTP, so pick a quiet moment.

Verify the fix#

1. No new events: Get-WinEvent -FilterHashtable @{LogName='Application'; Id=12014; StartTime=(Get-Date).AddHours(-1)} returns "No events were found that match the specified selection criteria."
2. openssl s_client -connect mail.contoso.com:25 -starttls smtp shows the new certificate's subject and issuer.
3. Get-Queue -Server EX01 shows no TLS-related LastError and falling message counts.
4. The connector's SMTP protocol log records a successful TLS negotiation.
5. In hybrid, test both directions and confirm in Exchange Online message trace.

Prevent it next time#

• Before deleting a certificate, list connectors that reference one: Get-ReceiveConnector | Where-Object { $_.TlsCertificateName } | Format-Table Identity, TlsCertificateName (and the same for Get-SendConnector).
• Renew in order: install on every server with the private key, enable SMTP (answer No), update TlsCertificateName or re-run the HCW, test, then remove the old certificate. See also renewing the SAN and Auth certificates and hybrid mail flow connectors and TLS.
• Check expiry monthly with Get-ExchangeCertificate | Where-Object { $_.NotAfter -lt (Get-Date).AddDays(45) } and run the Health Checker.

References#

• Can't receive mail in a hybrid environment after you install a new certificate on the server
• Renew TLS certificates in an Exchange Hybrid deployment
• TLS negotiation failed with error NoCredentials if messages to external domains are deferred