I haven’t followed this entire thread, but it would be worth checking what hostname the mail client is configured to use.
Depending on your DNS setup, it’s possible the mail client has a different name that happens to resolve correctly but isn’t on the certificate.
It looks like the server is adding that anchor when it creates the certs in /etc/certificates, to which it then points the various service configs. I'm chasing that down.
Still not sure that this the cause of the original issue. Hopefully my user will get back to me with the Outlook certificate path.
It's looking for "mail.brazoslink.net" which is in the cert.
Is also old, the current version is LibreSSL 3.6.1 released Oct 31st, 2022.
The PKCS12 cert gets imported into the system keychain, macOS Server pulls the cert data from the keychain and creates certificate files in /etc/certificates, updates the various service config files (postfix, dovecot, apache etc.) to point to the certs in /etc/certificates, and then reloads those services.
What I think is happening is that, when macOS Server pulls the cert data from the system keychain and creates the files in /etc/certificates, it's including that self-signed anchor that is causing the ssllabs.com error flags. To test, I reconfigured one of my SSL sites to use the (now revoked but not expired) GoDaddy wildcard cert and tested that with ssllabs.com. Of course it shows that the cert is revoked, but it also shows the same "Incorrect order, Extra certs, Contains anchor" issues.
This tells me two things. One, I'm probably correct that the chain issues are being inserted by macOS Server's certificate creation gyrations. And two, since the chain issue is not new, i.e. it existed even with the wildcard cert that wasn't causing any problems with the Outlook client, fixing the chain issue probably isn't going to fix the Outlook issue.
Right, 2.2.7 is the included version in macOS 10.13.6. I have openssl 3.0.7 installed via MacPorts, so I can use that if needed for some reason.
I realize this does nothing for the present, but for the future it might help;
request the vendor update their LibreSSL to be modern.
It's current in the current version of macOS. I'm running 10.13.6 which is from mid-2017. Long story, but at the next release, Apple killed off the functionality of the Server product so it stopped managing pretty much all the services I've had configured and running for...let's just say "a long time" and leave it at that. I've already migrated DNS services (now on the current bind9), and as I have time will be migrating everything else, which ultimately should resolve the certificate issue since I'll be creating those files myself, using modern versions of everything, rather than letting Server.app do it with its old stuff.
So it says "this certificate is OK," but still throws the "target principal name is incorrect" error.
OMG shoot me in the head.
The user had an old config that was using hostnames that...(drum roll please)...WERE NOT IN THE CERT AT ALL.
While we were all meshuggeneh with SSL chains and added anchors, @mcpherrinm sidled into the thread and solved the problem. Technically @Bruce5051 alluded to the problem earlier, but it wasn't quite as specific. If I could award the solution to both of you, I would.
I had JUST reworked the entire cert to list mail.brazoslink.net as the CN, with everything else SANs.
Y'all give me a link where I can contribute $100 to the cause. I owe you that much, at least, and it will be easier on my head than bashing it against the countertop repeatedly.
n/m, went to letsencrypt.org & found it myself.
As an aside, https://mail.brazoslink.net is currently serving a chain with 2 leaf certs included (i.e. the web server on mail.brazoslink.net is pointing to a cert that still has a wacky chain). It's serving mail.brazoslink.net ▶▶ mail.brazoslink.net ▶▶ R3 ▶▶ ISRG Root X1
I think that step is either unnecessary or has one too many certs in it.
That step is just importing the PKCS12 cert into the system keychain. That cert was created by:
# openssl pkcs12 -export -inkey privkey.pem -in cert.pem -certfile fullchain.pem -out letsencrypt_sslcert.p12 -passout pass:<random passkey>
So maybe I need to change something about this command? Should I use "chain.pem" instead of "fullchain.pem" for the certfile option?
Update: Tried that, response was "2 certificates imported," which seemed promising, but SSLLabs still says that root cert is being sent.
According to RFC 8446, which seems to be the latest iteration of the standard, "Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates."
Unless anyone can point me to an RFC that says that the anchor MUST NOT or SHOULD NOT be sent, then I don't see why SSLLabs flags an included anchor, which is specifically allowed per the standard, as a negative. That's causing almost as many headaches as I caused with this thread.
Then what does this part do?:
Is that question to SSL Labs OR Microsoft?
Really just to the ether. The actual problem here was just a stupid misconfiguration of the Outlook client, and the error message from Outlook was obtuse enough that we didn't think to look for the simple fix, we went way off in the other direction thinking there was a problem with the SSL cert. The "red flag" issue that we all focused on was that anchor cert being included in the chain being sent by the server. At the end of the day, not only was that not the problem, but it's actually standards-compliant. SMH.
Personally, I think SSL Labs should not flag it as a chain problem, because it isn't. But it's their tool, and it's free for us to use, and you get what you pay for.