I have a site that runs on-prem Exchange 2019 on Server 2019. The server SSL cert renews as expected via an ACME client (Certify the web and prior to that Win Acme)
External connectivity is fine - the cert is recognised when using OWA, ActiveSync on android and ECP. Internally however the client machines running Outlook 2016/2019/365 all say the cert is invalid. My suspicion is its DNS related - any thoughts
Can show the certificate and certificate chain?
(Please DO NOT post the Private Key)
Hi, is this a new problem and was it renewing fine before? Has it worked OK since you switched from win-acme?
The most likely problem is the internal clients are trying to access the service using one name .e.g something.domain.com and the external stuff is all called something else e.g. webmail.domain.com. If you can include all the correct names as domains on the cert that would fix it.
Feel free to email support {at} certifytheweb.com with more details.
Hi Webprofusoin,
Thanks for the response.
The site uses the external FQDN of the mail server mail.domainname.com and autodiscover.domainname.com. Both are configured in External and internal zones in DNS. When I migrated the site from Exchange 2010 to 2019 it all worked fine, but the the users didn't report it as being an issue for some months and could not recall when it started.
Could any services need restarted since the last renewal? Just refreshing the cert doesn't make the service use it, you generally have to restart stuff. The built in task in Certify The Web is just a basic powsershell script which you can can optionally replace: certify-plugins/Exchange.ps1 at development · webprofusion/certify-plugins · GitHub
Ultimately if you can manually update the cert in the Exchange admin UI and still have the same problem then you'll need to dig deeper into the exact error. Certs can be considered invalid for multiple reasons so you'll need the exact reason. e.g. invalid name, invalid dates, unknown root CA etc
Also watch out for the recent Windows Update thing that broke TLS session tickets, which I think was this one: Microsoft fixes Windows TLS handshake failures in out-of-band updates
Also worth re-iterating that if your cert contains only mail.domain.com and autodiscover.domain.com then the host domain URL/endpoint etc that your service point to must have one of these exact names. e.g. exchange.domain.com [or even just mail] would absolutely fail.
[If you migrated exchange versions then I'd lookout for old host names that have been repointed to the same IP or a CNAME, e.g. owa, exchange or webmail which presumably the old client could still be trying to use]
How about the chain of intermidate CAs being sent?
Do they have the same Root CA trust anchors?
Are they saying what is invalid about the Certificate?
Time?
Domain Name not a match?
etc?
HI All,
Thanks for the information and especially the things to consider.
The Outlook clients are looking for mail.domainname.com and using autodiscover.domainname.com.
I now really feel it's DNS related. When I checked the cert in the past Outlook was receiving the server signed cert mail.ad.domainname.com. Now it is getting one from Comodo, and digging deeper, it is the website hosting server cert that Outlook is receiving. Clearly I missed this fact by just assuming it was the same issue.
The website developer made a stack of changes to the public and internal DNS, and a check of my records shows he has amended them again.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
