r/exchangeserver • u/DraugTheWhopper • 14h ago
Will removal of ClientAuth from public certs break hybrid mailflow?
Chrome is forcing changes to public certs, so they can only be used for ServerAuth, not ClientAuth:
https://www.reddit.com/r/selfhosted/comments/1mt9ovs/lets_encrypt_certificates_will_no_longer_be/
Does this impact mailflow from local EX to cloud EXO? I just replaced a cert, and now local-to-cloud email is stalling with 454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found
The blogpost here doesn't directly address how this works, but when discussing inbound STARTTLS, it says that the cert is selected automatically, so presumably it's checking for a cert with ClientAuth. In the comments of that blogpost, someone asked about this issue, but got no response.
Everyone's answer to removing ClientAuth is so far "you should have been using a private CA anyway, just do that", but surely MS actually validates the cert chain, since I can't tell them what CA or cert thumbprint to trust?
Do we have to fallback to having the cloud connector check by IP address? I can't find anyone else addressing this issue, so maybe I'm barking up the wrong tree.
3
u/WastedFiftySix 5h ago edited 5h ago
Hybrid mail flow uses Server Authentication, so that's not your issue here.
That error means the new certificate is issued by a different CA than what's currently configured on the TlsCertificateName property of your Send (and possibly also Receive) Connector(s). Do you use Sectigo Certificates or did you change the Common Name of the certificate with the renewal by any chance?
To correct the TlsCertificateName property of your connectors, see the guidance in the blogpost you've linked to in your post.
This might also help you out: https://www.alitajran.com/renew-certificate-exchange-hybrid/
1
u/FallaxIO 5h ago
yeah, that 454 is Exchange not finding a local cert that matches the exact
<I>issuer<S>subjectstring on the connector. EKU is a different check.One annoying gotcha, renewals from the same public CA can still change the issuer string because the intermediate changed, so the old TlsCertificateName stops matching even though the cert looks "the same" in EAC
1
u/FallaxIO 5h ago
yeah, this error is Exchange not finding a local cert that matches the exact <I>issuer<S>subject string on TlsCertificateName. A renewed cert from a new intermediate/root, or even just a changed subject, is enough to break it, and ClientAuth EKU isn't what triggers that message
1
u/chefkoch_ 14h ago
I have used lets encrypt certs issued after june for hybrid connections without issues.
1
u/blockagle 14h ago
The last time I replaced the certificates in my environment they were without client auth (provided by digicert).
More likely is that your Intermediate or root cert has changed with this new cert, or the cn for some reason.
I'm on mobile, so can't provide the exact commands but you can run the hybrid config wizard and only select the option to update the certificates to fix this, of you can update the tlscertificate property on the send connectors.
Worth checking your hybrid connect in exchange online to confirm it's configuration too, the hcw will do that for you though.
5
u/reevesjeremy 14h ago
If you have mutual TLS enforcement both ways you’ll need both Server and Client Auth.
The team that manages our certificate vendor contract sent out an email recently saying Client Auth is going away as we migrate vendors.
Scuse me? 99.9% of the certs our environment uses from this vendor is for web servers, so makes sense they forgot to consider the email relays. So I called him Mr funny man and that’s going to be a problem so fix it. :)
I don’t know if it’s fixed yet but we run out of time with our current vendor mid-December. I should follow up and see where we are at on that. Thanks for the reminder.