1

macOS 10.13.6, Server.app 5.6.3

I'm using LetsEncrypt SSL certs. After updating a cert with certbot, I use openssl to export a PKCS12 file, then import that to the system keychain using "security" as follows:

# cd /etc/letsencrypt/live/www.brazoslink.net
# openssl pkcs12 -export -inkey privkey.pem -in cert.pem -certfile fullchain.pem -out letsencrypt_sslcert.p12 -passout pass:(random passkey)
# security import letsencrypt_sslcert.p12 -f pkcs12 -k /Library/Keychains/System.keychain -P (random passkey) -T /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/ServerManagerDaemon.bundle/Contents/MacOS/servermgrd

This all works, no errors, the updated cert appears in Server Admin just as it should, and any services/websites using that cert are automatically updated to use the updated cert so I can delete the old version. All good.

However, the cert that gets created in /etc/certificates contains the self-signed "ISRG Root X1" cert, which was not contained in the original LE cert. When I run the SSL cert tests at ssllabs.com, it complains, "Incorrect order, Extra certs, Contains anchor" and gives me a "B" rating.

Can anyone explain what is going on here, and how I can fix it?

Improve this question
4
  • I tested a GoDaddy wildcard cert, and it gets the same errors. So macOS Server is adding that self-signed root when it pulls the cert from the system keychain and generates the files in /etc/certificates. Question is, how to stop that, or fix it?
    – JLG
    Commented Nov 14, 2022 at 23:07
  • Note that this is an old version of macOS Server, last version before Apple gutted it.
    – JLG
    Commented Nov 14, 2022 at 23:24
  • Can you do it in Keychain Access.app?
    – benwiggy
    Commented Dec 15, 2022 at 16:06
  • No point in messing with it, since it turns out that the current behavior is RFC compliant. SSL Labs is erroneously flagging it as a problem, most likely to generate consulting business for themselves.
    – JLG
    Commented Dec 16, 2022 at 18:06

1 Answer 1

Reset to default
0

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."

So this isn't actually a problem. Sending the root cert in the chain is fully standards-compliant, and ssllabs.com should not be flagging it as an issue.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .