Renew Exchange 2010 Certificates – Event ID: 12017 & Event ID: 12018
Wow, what a horrible weekend it has been dealing with all these certificate expirations (both clients, and my own). Ton’s of articles on the internet, however tons don’t cover what you do if you have your own certificate authority and DON’T want to use a self-signed certificate. Also, all the tutorials on the net use the Shell, I rather use the GUI…
When it comes time to renew your certificate, you’ll be seeing these in your Event Viewer:
Event ID: 12018
User (If Applicable): N/A
Computer: server.domain.com Event Description: The STARTTLS certificate will expire soon: subject: server.domain.com, thumbprint: ZOMGZOMGZOMGZOMGZOMGZOMGZOMGZOMG, hours remaining: 664. Run the New-ExchangeCertificate cmdlet to create a new certificate.
Event ID: 12017
User (If Applicable): N/A
Computer: server.domain.com Event Description: An internal transport certificate will expire soon. ZOMGZOMGZOMGZOMGZOMGZOMGZOMGZOMG, hours remaining: 664 Event Log Name: Application Event Log Type: error
Anyways, first off, DO NOT use this tutorial if your running “Microsoft Small Business Server”, there is a better, easier, and more automated way to perform this on SBS (I won’t be covering that in this blog post, I will however make another one to explain the procedure). Depending on you’re environment, this may or may not be the best way or the right way to do this. In my environment, I have 1 server that acts as a Domain Controller and a Certificate authority, and a second server that is running Microsoft Exchange 2010.
You take your own risk if you perform the instruction in this blog post.
1) Start the renewal process
We need to generate a renewal request. Load up the Exchange Console, and select the “Server Configuration” on the left. It should load up your Exchange Certificates on the lower half of your screen. Look for your certificate that is about to expire. To get the details on the certificates, simply double click and it will load the info, if you’re unsure of which certificate it is, use the thumbprint provided in the Event viewer, and compare it to the Thumbprint on the “Details” tab of the certificate. Once you find it, highlight it and select “Renew Exchange Certificate…” on the action pain to the right.
2) Create renewal request Wizard
This will open the certificate renewal request wizard (as shown below):
Simply choose a file name and location to save the request. It’s easiest just to save it on your desktop. After, hit “Renew”. This will generate the certificate renewal request.
3) Copy certificate request to clipboard
Locate the file you created above inside of Windows Explorer. Right click on this file and select “Open”, or “Open With”. When prompted, uncheck the “Always use the selected program to open this kind of file” option, and select “Notepad” as the program to open the file with. Example below:
This will open the certificate request. Now highlight all the text and copy it to your clipboard. Example below:
4) Submit certificate request to certificate authority using web interface
Now we submit the request! Log on to your certificate authority web interface. On the first screen, we will select “Request a certificate”, as shown below:
Then select “advanced certificate request”, as shown below:
And now, choose “Submit a certificate request by using a base-64 encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.”, again example below:
Finally, we are going to populate the request. Inside of the “Saved Request:” text box, paste your request from your clipboard (which we copied to your clipboard above), then for “Certificate Template:” choose “Web Server”. Example is below:
Now select Submit! On the next page that loads, simply select “Download certificate” and save it to a location you’ll remember.
5) Install certificate on Exchange
We now have a certificate that’s ready to be installed. Go back to the Exchange console where we left off. Inside of the certificate list, you should see an item that has a status that says something about a pending request. Highlight this request, and on the Action Pane, select “Complete request”. I could be wrong on what this says as I can’t remember and did not take screenshots.
A wizard should open up, in this wizard simply point it to the new certificate (the file we just saved at the end of step 4, shown above). Follow the instructions.
6) Assign Services to Certificate
Now that the certificate is installed, we need to assign which services will use it. The new certificate should also now be in the list of certificates inside of Exchange. Highlight the new certificate, right click, and select “Assign Services to Certificate”. Example below:
Once the wizard opens up, follow through and when actually prompted for the services check everything except for “Unified Messaging”. Finish the wizard.
7) Delete old certificate
Now we are almost done. Go back to the certificate list inside of Exchange and look for the old certificate that is going to expire. Highlight it, right click, and select “Remove”.
Hi, i belong “that’s simple”.
I can’t read the file .req with the Notepad Application.
Can you Help me ?
Thanks in Advance.
Hello Sue Leon,
What happens when you try to open it?
Thx for the procedure 🙂
The wizard in Exchange 2010 (SP1 ?) exports certificate request in binary format (running the New-ExchangeCertificate cmdlet with the -BinaryEncoded parameter)
You can import the request directly in the Certificate Authority MMC.
Then, if you get an error “0x80094801 – The request contains no certificate template information”, you can run the following command on the CA :
certreq -submit -attrib “CertificateTemplate:WebServer”
Works fine for me 🙂
Oups… Command croped by HTML because of using gt & lt 😉
certreq -submit -attrib “CertificateTemplate:WebServer” “x:\FullPathToYourRequestFile.req”
Thank you all!! I had the same issue of Sue and thanks to Chris’s suggestion it works great!
Thanks for the information. For my case, I was prompted with certificate status in EMC “The certificate status could not be determined because the revocation check failed”. I could not proceed to assgin service to renewed certification.
Any solution for this?
Saved my day Stephen. Thank you for such informative article.
Thank you so much for this article..
Yay! Thank you! Other sites had people just questioning why one wouldn’t use a third-party cert. You solved my problem.
Awesome! Thanks for posting this.
We have a few Exchange 2010 servers. My question is do we need to do the renew process n every server?
Or it is possible to do in on one server, then Export/Import certs to others?
As far as I know, each exchange server should have it’s own FQDN, therefore I’m guessing that each server will require it’s own certificate.
I could be wrong, haven’t played too much with multiple Exchange server environments.
MR stephen, i have done with whole proces
I want to know how to get the certificate which i can install for microsoft outlook on mmc console
Can I use the cert generated from Windows 2003 CA to Exchange 2010 using? Thanks
As far as I know you should be able to. I can’t confirm this, but it shouldn’t matter what the CA is running on…
Let us know how you make out, as I’m sure some other people might be curious about the same thing.
Thanks for taking the time to do this!!
for some reason this gave me a self signed cert… any way to have this authorized by the DC? I used the DC’s certsrv URL so I would have thought that would work.
If your target is a cert from a domain CA, then the instructions should result in a cert from the CA. Have you confirmed it is a self-signed cert, or do you not have the root CA cert installed on the machine that you’re using?
Did you make sure to use the proper commands when importing the cert back in to the host?
Hi there, got event 12017 on both Exchange 2019. Renewed with CERT from official CA (Sectigo). Did it with multi domain CERT since there are several names involved (second level, autodiscover, mail and the servers). Did it on one Exchange which lists the name of this server on top (unfortunately btw.). On this server all is ok. But on the other, every 15 Min. 2 Warnings appear that the CERT is about to expire in 3 months. Obviously, only the first name in the UCC CERT get checked. Both CERTs show in EAC and EMS. Very annoying. Best, Marcel
Check to make sure no other IIS services are using the old cert. Also, use the Exchange powershell commands to de-activate and delete the old certificates and you should be good.
Thanks. IIS is not included as service in the old Exchange CERT. When trying to delete the old CERT with EAC, the message “A special RPC error occurs on server xxxx. The internal transport certificate cannot be removed because that would cause the Microsoft Exchange transport service to stop. To replace the internal transport certificate, create a new certificate. The new certificate will automatically become the internal transport certificate. You can then remove the existing certificate.”
Guess the same will happen with power shell commands. It seems to me that Exchange only checks the subject of the CERT and this is – due to its origin – from the second Exchange server. Kind regards, Marcel
Thanks Stephen for the steps provided. Worked for me 😉
An external consultant upgraded our Exchange 2016 2-server DAG infrastructure to Exchange 2019. He exported the GoDaddy SSL cert from the 2016 machine and imported it onto both Exchange 2019 VMs. Once we shutdown the 2016 machines, we had cert errors related to the actual internal names of the 2019 machines that he wrestled with for 3 hours. He was unable to resolve the error and finally decided to install our GoDaddy domain star cert on both 2019 machines and bound IIS to it and that ended the difficulty. Recently, when checking both the GoDaddy SSL cert and the GoDaddy start cert, I found that he never bound IIS to the external GoDaddy SSL cert. If I now simply bind IIS to the GoDaddy cert on both 2019 machines, can I forget about the star certs and allow them to expire? Thanks in advance for your answer.
It sounds like the old server may not have been decommissioned properly, or the new virtualdirectory configuration may be wrong. It could also be the certificates, but I can’t say without seeing them and verifying them against the configuration.
Depending on your configuration, it may be better and easier to manage if you’re using a wildcard certificate.
All binding should be handled via the PowerShell commands for Exchange (or the GUI). The only time I ever manually modify the IIS bindings is for specific examples or issues that require it. Also, make sure you do not touch or modify the “Exchange Backend” site.
Thanks again Stephen. Guess it will just be easier to leave both certs, with their current binding configurations, on both Exchange 2019 boxes since we are not having any issues at all and I do not want to create one.