Fullchain.pem contained certs being issued in wrong order

Hi,

Our SSL monitoring reported that the issued fullchain.pem is invalid according to the RFC https://tools.ietf.org/html/rfc5280 in that it contains the cert for the domain, in addition to the intermediate/CA (example attached), in the wrong order. Example:

-----BEGIN CERTIFICATE-----
[domain SSL cert]
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

The cert validates OK via sslshopper but according to RFC:

  • Each following certificate must directly certify the one preceding it
  • The subject of certificate x should be the issuer of certificate x+1
  • A certificate must not appear more than once in a prospective certification chain

We use https://github.com/Neilpang/acme.sh and the developer confirmed that when using the default v2 endpoint, the fullchain is returned by the CA, so Let’s Encrypt.

Please advise?

Thanks,

Matt

Here’s the actual text from the RFC:

The sender’s certificate MUST come first in the list.

Each following certificate MUST directly certify the one preceding it.

It seems to me that fullchain.pem fulfills these requirements because:

  • The leaf certificate is first
  • The intermediate certificate is the issuer for the preceding certificate (the leaf)
1 Like

I think I might understand what the confusion might be (or I might be further confused). In RFC5280 Basic Path Validation, it describes the algorithm in such a way that the trust anchor is the start/input, and the leaf certificate as the target at the end. But this does not actually refer to the on-wire order of certificates, it’s just a description of an algorithm.

TLS itself expects you to send the certificates in the order that builds a path from the leaf to the trust anchor eventually (or at least, TLS 1.2 does, TLS 1.3 doesn’t care as long as the leaf is first).

1 Like

Unfortunately, I’m not familiar enough with the detailed technical aspects of issuance. We used to use certbot-auto, which is fine, but now use acme.sh, which isn’t fine. The developer of that client said:

"Thanks for the info. I didn’t notice that the cert order is specified in an RFC.

Yes, if you are using the letsencrypt v2 endpoint(the default endpoint), the fullchain is returned by the CA. So, the CA gave us the wrong order."

I just compared two systems, one with certbot-auto and the other with acme.sh, and the fullchain.pem does indeed have the same order on both. The only difference is an empty line between the trust and the leaf. Removing it makes no difference.

But when configuring an Apache site to use fullchain.pem as the SSLCertificateChainFile, our monitoring triggers with “The certificate is not trusted - Intermediate certificates are missing in the certificate chain”. This doesn’t occur with certbot-auto client issued certs.

I can provide examples privately if you would like to interrogate two configurations to see the difference?

1 Like

Sure, sent you a private message.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.