When you are managing services for an Exchange Server 2013 SSL certificate via the Exchange Admin Center you may notice that the checkboxes for enabled services are greyed out and can’t be unticked.
Exchange 2013 will not allow you to disable/unassign an SSL certificate from a service that requires SSL. Instead, you should enable another SSL certificate to that service, which will automatically disable the existing one for you (for that specific service, not necessarily all services).
As numerous others have posted on here, the command “Enable-ExchangeCertificate -Services None -Thumbprint ” runs but does nothing. No errors. The expired internally signed cert from our CA remains assigned to IMAP, POP, SMTP. The DigiCert that we purchased, which is a WILDCARD certificate, is assigned to IIS, SMTP. Everything is working flawlessly because we don’t use IMAP nor POP services. I simply want to unassign the old certificate and remove it because it causes a nag when logging onto EAC.
But Microsoft clearly states the following with regard to wildcard certificates:
IMAP: Don’t enable a wildcard certificate for the IMAP4 service. Instead, use the Set-ImapSettings cmdlet to configure the FQDN that clients use to connect to the IMAP4 service.
POP: Don’t enable a wildcard certificate for the POP3 service. Instead, use the Set-PopSettings cmdlet to configure the FQDN that clients use to connect to the POP3 service.
Therefore I ran the command below, as instructed by Microsoft.
Set-POPSettings -X509CertificateName mail.mycompany.com
Set-IMAPSettings -X509CertificateName mail.mycompany.com
But this doesn’t solve how to unassign IMAP, POP, SMTP from the expired certificate. What is the trick in resolving this when using a wildcard certificate?
Have an odd issue, preparing to migrate from Exchange 2010 to 2016. The test account migrated to 2016 is getting a cert error a few seconds after opening up Outlook 2016, complaining that the name on the security certificate is invalid or does not match the name of the site, which is understandable, because the cert it’s trying to use is the default self signed certificate by the server itself. Even though I have assigned a valid public certificate to the server, and assigned it to IMAP, POP, IIS, SMTP. And I have configured all the virtual directories as well. And when looking at the Outlook Connection Status screen, Outlook only shows connections to the real good URL. So I don’t understand why Exchange is presenting the self signed one?!
I was also wondering as Dan previously asked, how to unassign IIS from the self signed certificate, because that’s the only thing I can think of causing this problem?
Any clue would be much appreciated!
And just to add one more bit of information, if I go to the URL with a browser, the correct/public certificate shows up. So this is very specific certificate error with Outlook.
And both inside/outside is configured to use the public cert.
Actually, correction, after troubleshooting it a little more, it’s the other way around, the certificate presented is the correct/public certificate, but Outlook is trying to connect to the internal name of the Exchange server…!
Hm… but no virtual directories are configured to use the internal server name… at least as far as I can tell… weird…!?
Again, any ideas would be much appreciated!!
Excellent. Thank you. Just curious if one may be able to correct what I did…I have done a number of 2013 to 2016 migrations without issue (and having the 2016 in the 2013 topology for a number of weeks before final cutover (changing DNS to point to new server) – but we did have an issue on a recent one (which was resolved so I am assuming I made an error in judgement in steps).
After installing the 2016 I immediately changed the autodiscover uri to point to the FQDN web.domain.com to match the 2013s. No immediate issues…but later folks were receiving cert errors, which I thought would be avoided by the uri change only (based on what I read). I intended to address other actions next day…but the cert errors started and continued till the 2016 was shut down.
I did later import/export SSL (which had been done in the evening once the issues came up, but did not resolve – the other engineer only assigned to IIS – I assigned to SMTP, IMAP and POP.). I also modified the internal / external URLs of the various virtual directories to match the 2013.
Since then, the issue has gone away. In the past I normally go through all those steps, but this time I figured the uri would be sufficient for a Point In Time to pause project.
I assume I was wrong. Can you confirm? Thank you.
The Real Person!
The Real Person!
I can’t really diagnose a problem that I can’t see, but it sounds like configuring all the vdir URLs was the solution.
Hi I realize this article is specific to 2013, but I am curious if the same applies re 2016? Reason I ask:
Self signed cert Microsoft Exchange shows services IIS and SMTP.
This is after enabling successfully a third party cert to server
I was surprised about the IIS remaining on the Microsoft Exchange.
When I enabled-cert I did have the –DoNotRequireSsl argument. I have seen this Microsoft Exchange with service IIS on a number of 2016 installs of late.
Example out put from a recent server.
PS>Get-ExchangeCertificate -server XXX | fl Thumbprint,NotAfter,Issuer,CertificateDomains,Services
Thumbprint : 24CAXXXXXXXXXXXF42B11
NotAfter : 3/22/2023 5:31:28 PM
Issuer : CN=NBXXXXX
CertificateDomains : {NBXXXX, NBXXXX.XXXX.com}
Services : IIS, SMTP
Thumbprint : A123F48XXXXX884F12201C8206B51
NotAfter : 4/10/2020 6:31:02 PM
Issuer : CN=Go Daddy Secure Certificate Authority – G2, OU=http://certs.godaddy.com/repository/,
O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona, C=US
CertificateDomains : {mail.XXXX.com, http://www.mail.XXX.com, drmail.XXX.com, autodiscover.XXX.com}
Services : IMAP, POP, IIS, SMTP
—-
I noticed this as reviewing /TS adding 2016 servers to existing 2013 topology. I confirmed same on another deployment which had not had any issues.
So I wonder if this is by design with 2016? Ty.
The Real Person!
The Real Person!
An Exchange 2016 Mailbox server (or an Exchange 2013 multi-role server) has both a frontend and backend website in IIS. The self-signed certificate can remain bound to IIS for the backend website. That is normal and expected, and doesn’t cause any problems.
Hi Paul,
I have one self-signed certificate that is assigned to services: IMAP,POP,IIS,SMTP. That’s fine.
But, I have another certificate that I use to integrate skype_owa, and when I import it, automatically it is tied to IMAP,POP services, and I just want to let it assigned to none services.
The following command didn’t work.
Enable-ExchangeCertificate -Thumbprint C53154BF580C5ACC69253461CADFC82CFEFBDDB4 -Services None
Thanks.
Thank you!
I assigned a new SSL cert to the SMTP service on my Exchange 2013 server and got the prompt about overwriting the old one. However, the old cert is still bound to the SMTP service and I can’t uncheck the box. Do I need to reboot the server or can I just restart the SMTP service to unbind it?
The Real Person!
The Real Person!
Hi Victor, here you go:
https://www.practical365.com/remove-ssl-certificate-exchange-server-2013/
Good explanation. Can’t say it makes any sense why Microsoft does that though.
The Real Person!
The Real Person!
Makes perfect sense. The reason is stated in the article.
Paul
To clarify, the self-signed certificate cant be managed, but explicit cert that we assign, can be managed?
Thanks
Gopinath T
The Real Person!
The Real Person!
Any certificate can be managed.
Pingback: Exchange 2013: Assign SSL Certificates to Exchange Services