From the Department of I Wish The Prerequisite Analysis Checked for This, comes the unfortunate issue that customers with expired SSL certificates will run into when they try to install an Exchange cumulative update. In short, the CU install will fail, and the server will be left in a broken, non-functional state.
During the cumulative update the following error will be thrown:
Mailbox role: Transport service FAILED
The following error was generated when “$error.Clear();
Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
{
Install-AuthCertificate -DomainController $RoleDomainController
}
” was run: “System.Security.Cryptography.CryptographicException: The certificate is expired.
at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception
, ErrorCategory errorCategory, Object target, String helpUrl)
at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception
, ErrorCategory category, Object target)
at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCert
ificate.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)”.
This isn't so much a flaw in the Exchange setup process as it is a stark reminder of just how common it is to see poorly maintained servers in the field. Imagine all the Exchange servers that aren't being backed up at all (and there's plenty of those out there), creeping ever closer to filling up their transaction log drive and dismounting databases. Viewed through that lens it's easy to also picture an office full of staff dutifully clicking past the expired certificate warnings they see in Outlook and their web browser every day to get to their email. It's almost ironic that after neglecting a server to the point where its cert has expired, that when the admin finally tries to do some maintenance by installing a CU they're going to end up making things worse.
Anyway, once you've found yourself in this hole, you're going to need a quick way out. Looking around for solutions you might find your way to the instructions for renewing an Exchange certificate. Your bad day doesn't get better yet though, because you discover that you can't connect to any of the Exchange management tools for your server.
But all is not lost! Fortunately, you can manage the certificate bindings using IIS Manager on the Exchange server. Select the Default Web Site, click the Bindings link in the Actions pane, and edit the bindings for HTTPS (there should be two of them for port 443, and you'll need to do both). From the list of SSL certificates, you should see one called “Microsoft Exchange” that is the self-signed certificate that was automatically configured on the server when Exchange was installed. Just to be sure, click on View and check whether it's expired (it should have a 5 year lifespan).
Apply that change and re-run the Exchange cumulative update.
If for some reason the self-signed certificate doesn't work, or is missing, you can generate a new one in IIS Manager by clicking on your server, opening the Server Certificates section, and selecting Create Self-Signed Certificate.
When you've successfully completed the cumulative update for your Exchange server, it's time to do something about your certificate problems. There'll be a cost involved, usually not more than a few hundred dollars, which hopefully by now you consider a bargain. Here's some reading for you:
Paul, where is the self signed cert for and where is it being used for? What is impact if its expired in a multi server org?
Every Exchange server is configured with a self-signed SSL certificate automatically during installation, because Exchange needs a certificate so that it can enable SSL for services like OWA and ActiveSync. The self-signed certificate is replaced for most services by a new certificate that the administrator provisions from a CA like Digicert. The self-signed certificate should remain on the server though.
Self-signed certs have a life of 5 years. However, if it expires, you can renew it.
Hi Paul,
So, you don’t recommend to remove self-signed certificate ? In terms of above mention, look like all services can be taken by new certificate.
The self-signed certificate remains bound to the backend IIS website, as well as being used for some SMTP/TLS scenarios. There’s no need, or benefit, to removing it.
You can replace the cert on the IIS, on the SMTP/TLS as well without issue since the Exchg 2007 days. So still don’t see why it may remain -if any- in use after the proper certs have been generated and assigned. Is this some kind of grey -undocumented- area, why people with past exchg experience still keep sticking to old practices, even if in vCurrent its no longer applicable? i remember thewe was a golden rule around Exchange 2007 NOT TO remove the self-signed certs, as Outlook MAPI (if I recall correctly) still used that cert. May that be the reason why the same mantra -dont delete the selfsigned cert- still remains in the heads? No offense here, just asking honestly.
You can replace the cert, but you’ll need to replace it with one that includes the server’s FQDN so that all SMTP/TLS scenarios are covered (such as server to server internal traffic). It’s not recommended to include the server FQDN on the cert used for HTTPS services, so you’d need a separate cert for SMTP. At which point you’ve gained nothing by replacing the self-signed cert with a new one, since it just has the server’s FQDN on it. Furthermore, if the server’s FQDN is in a domain you can’t get a certificate from a public CA for, such as a .local domain, that leaves you with using a private CA (which not everyone has, and it not a trivial thing to deploy securely), or using a self-signed cert (which takes you back to where you started anyway).
I have sha-1 certificates right now on my one Exchange server, not set to expire until 2018. Should I switch over to sha-2 now before I perform the CU 13?
You can if you like.
Hi Paul,
we are getting the below error in CAS 2013 Server.
“Microsoft Exchange could not load the certificate with thumbprint of from the personal store on the local computer. This certificate was configured for authentication with other Exchange servers. Mail flow to other Exchange servers could be affected by this error. If the certificate with this thumbprint still exists in the personal store, run Enable-ExchangeCertificate -Services SMTP to resolve the issue. If the certificate does not exist in the personal store, restore it from backup by using the Import-ExchangeCertificate cmdlet, or create a new certificate for the FQDN or the server enabled for SMTP by running the following command: New-ExchangeCertificate -DomainName serverfqdn -Services SMTP. Meanwhile, the certificate with thumbprint is being used.”
I had ran the command “Get-ExchangeCertificate” and not able to get the old or new certificate details.
But i can see the certificate in MMC/certificates and date was expired. This certificate got from internal CA server. Could you guide me to check something.
You should replace or renew the expired certificate.
actually we are having this problem now too.
But our certificates are not expired.
1 certificate is automatically renewed using Lets encrypt.
the 2nd certificate is a self signed cert from us, where all clients have it installed.
So all should be valid, any other reason, this could fail?
Sure I could set it to the Exchange Cert, and afterwards set it back. But still wondering the root cause.
What does the error say?