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:
Thank you for this write up. It just saved me a lot of time.
Thank you Paul,
You saved my night.
>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.
Or.. Lets Encrypt..
You’re a genuine lifesaver. Thanks for taking the time to write this post.
As you mentioned, this should be part of the prerequisite checks.
Thanks, saved my ass!
worked like a charm!
Thanks a lot again, Paul!
Your posts keep saving my day dealing with exchange CUs.
I’ll read one of your posts again soon I guess 😉
Best regards from Belgium!
Arno
Thanks for pointing me in the right direction. One binding was pointed to the current certificate, the other to the old expired one.
You saved my bacon.
Far out there are so many possible things that could go wrong with these Cumulative Updates.
I got this while installing CU19 on a Hybrid server that had not been touched since CU12.
At one point my update appeared to have stalled on “Copying Exchange Files 16%”. For that you just need to be patient, but when it did get to 100% it sat there and I left it for an hour and a half. There had been no CPU or Disk activity for the whole hour and I was about to reboot the server, instead I decided to see if I could exit the CMD window and upon hitting the enter key the results all of a sudden progressed to “Language Files 1%”
FAR OUT!! Was it waiting for some input but had failed to write the message to the screen??
Thanks to you I have now progressed… on to the next issue with this update, whatever that may be.
Thanks heaps
Thank YOU!!!! God knows I was not ready to explain to the client what happen to their Exchange server. Man you saved me. Seriously its 3:30am and I was sure what to do once I received this message.
What to do when the self-signed Exchange Certificate itself has expired?
How to Renew the self-signed Exchange Certificate without EAC or EMS?
Hi Frans
Did you manage to get an answer for this problem, I have the same issue, the Microsoft Exchange Server Certificate expired and I ran the Cumilative update, now I cant access EAC, EPS, only have access to Power shell and Command.
Your the best!! just experienced this my self, and found this post on my first google hit, solved the problem within a hour!! You saved my weekend ;), have a nice one!
Please help me below error.
Unable to handle the request https 503 (OWA)
I appreciate the griefing on unmaintained.. it’s my lab! Thanks Paul!
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.
The Real Person!
The Real Person!
What does the error say?
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.
The Real Person!
The Real Person!
You should replace or renew the expired certificate.
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?
The Real Person!
The Real Person!
You can if you like.
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?
The Real Person!
The Real Person!
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 Real Person!
The Real Person!
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.
The Real Person!
The Real Person!
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).
Hi,
Self-signed certificates on my CAS servers & MBX servers will expire in months . So my question is do i need to initiate the renewal of those certificates or do they renew it by itself ? Please enlighten me.
The Real Person!
The Real Person!
You will need to renew them.