Certificate chain is not in the required order
Updated
Fewer than 1% of the 923 domains we could check get a warning for this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured
What this check looks for
The linking certificates are present but sent in the wrong order, or one is repeated. Modern clients cope; older and stricter ones do not.
Why it matters
It works today because almost every client sorts the chain for you. It stops working on the one embedded device, old Android build or strict TLS library that follows the specification literally — and that failure is very hard to reproduce.
When the check passes, your report says: “The certificate chain is sent in the required order”.
What it costs your score
When this check fails it removes 5 points from your TLS score, before the status, confidence and repeat multipliers are applied. TLS carries a weight of 15 in the overall score.
It shares the tls.certificate family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from TLS. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 5 points
- Family cap
- tls.certificate · 60
- Category
- TLS
- Module
- Tls certificate
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Rebuild the certificate file in order: leaf, then each issuer in turn.
A strict client is entitled to reject an unordered chain, and some do.
Concatenate the certificates leaf-first into one file.
Remove any duplicate and any self-signed root from the file.
Reload the server.
How to confirm it worked
openssl s_client -connect ‹host›:443 -servername ‹host› -showcerts </dev/null 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Remediation by platform
cat leaf.pem intermediate.pem > /etc/ssl/‹host›/fullchain.pem
nginx -t && systemctl reload nginxcat leaf.pem intermediate.pem > /etc/ssl/‹host›/fullchain.pem
apachectl configtest && systemctl reload apache2Technical detail
‹detail›
RFC 9846 §4.4.2 (formerly RFC 8446) requires each certificate in the Certificate message to certify the one before it. RFC 5246 said the same for TLS 1.2. TLS 1.3 explicitly permits clients to accept an unordered chain, and most do, which is why this is a warning rather than a failure — but the fix is one line of configuration.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.