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?

  • 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


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.

You must log in to answer this question.

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