User says, "Outlook for Windows(C2R) v16.0.15726.20174 in the Office 365 suite."
1 Like
I don't think it sees that, the only place I see it is in the Qualys report. Apache is using SNI to serve multiple SSL-encrypted sites from a single IP, so apparently Qualys is doing something with its requests that doesn't follow the SNI browser protocols.
1 Like
SSLLabs does both: with and without SNI.
3 Likes
Working on this...
1 Like
Thanks! 
1 Like
Here are 3 more links on Chains:
2 Likes
Am I looking at using the certbot --preferred-chain option when creating/updating certs, or the openssl -trusted-first option when exporting a PKCS12 file from the LE cert?
I'm scratching my head trying to figure out where the "extra" root is coming from. Is it included in the LE cert, or is my system adding it during the openssl export?
it is not.
I don't think OpenSSL, with the command you've posted earlier, would do that as you're only using the files provided by Certbot. And they don't include the root cert.
3 Likes
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.
5 Likes
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.
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.
1 Like
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.
1 Like
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.
2 Likes
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.
3 Likes