r/exchangeserver • u/DraugTheWhopper • 12d 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.
Edit: As commenters suggested, my issue was because the outbound connector is looking for a specific Issuer and Subject. My CA changed their intermediate issuer for the first time in a long time, and I've never run into this before. I was able to check this with Get-SendConnector Outbound* | fl, and after some careful string editing, set it with Get-SendConnector Outbound* | Set-SendConnector -TlsCertificateName $certstring (note I only have one matching connector, so a wildcard was fine). So, apparently the answer is no, Hybrid mailflow does not need the ClientAuth part of the cert. (But then how the heck is it doing some kind of client auth? Do EX and EXO collaborate to break the rules of TLS somehow? Maybe it's a special STARTTLS thing? Oh well...)
4
u/reevesjeremy 12d 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.
2
u/H0TR0DL1NC0LN 12d ago
I don't know that they can fix it. 3rd party CAs are being forced to drop the various extensions from certificates and shorten certificate life by the CAB forum. Google is pushing things forward and isn't very concerned about other use cases.
3
u/reevesjeremy 12d ago
Doing a little reading it looks like the goal is to phase out the use of dual purpose certificates in favor of dedicated certificates. So one cert for client and one cert for server, in cases where both is needed. Ugh what a pain.
2
1
u/chefkoch_ 12d ago
I have used lets encrypt certs issued after june for hybrid connections without issues.
1
u/blockagle 12d 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.
2
u/DraugTheWhopper 11d ago
Good call, it turned out to be a changed intermediate, which I've never had to deal with before. More details in the edited post.
1
u/Naughty_Cactus 11d ago
Before doing this take a snap shot of your current config for send and receive connectors in both exo and on prem.
1
u/actor-observer 11d ago
For this connector, rather than TLS validating the correct cert is being used, Exchange is receiving the instruction "when I send to this domain,use the installed certificate whose issuer and subject match this value" - not a validation, rather an instruction
1
u/auditvault-de 9d ago
No — the ClientAuth EKU removal does not break hybrid mail flow by itself. Hybrid secure mail transport only needs the cert to be a valid third-party CA cert bound to your SMTP connectors; Microsoft's hybrid certificate requirements don't list clientAuth as a requirement.
Your actual problem is the cert replacement: 454 4.7.5 means the issuer/subject
string stored in the Send Connector no longer matches any installed certificate —
CAs changing hierarchies on renewal (e.g. new intermediate/root) changes the
Issuer field, so the old <I>...<S>... value goes stale. Fix (documented):
powershell
$TLSCert = Get-ExchangeCertificate -Thumbprint <Thumbprint>
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"
Set-SendConnector "Outbound to Office 365" -TlsCertificateName $TLSCertName
Also enable the new cert for SMTP (Enable-ExchangeCertificate -Thumbprint ... -Services SMTP)
and restart the transport service. Check the Receive Connector / EOP inbound
connector if on-prem inbound still stalls after that.
3
u/WastedFiftySix 12d ago edited 12d 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/