Fullchain.pem contained certs being issued in wrong order

mattg · October 3, 2019, 8:33am

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

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

_az · October 3, 2019, 8:43am

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)

_az · October 3, 2019, 8:52am

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

mattg · October 3, 2019, 9:23am

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?

_az · October 3, 2019, 9:25am

Sure, sent you a private message.

system · November 2, 2019, 9:32am

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

Topic		Replies	Views
Fullchain.pem contains an invalid Intermediate Help	3	823	October 13, 2022
Intermediate certificates in wrong order !? Help	10	2248	October 11, 2021
[solved] Wrong domain order Server	4	1770	May 30, 2016
I facing missing chain issue after I installed with the cert Help	6	663	March 26, 2020
Fullchain.pem: missing, empty, or okay?! Help	4	6566	May 8, 2020

Fullchain.pem contained certs being issued in wrong order

Related topics