dotvitals

Certificate chain is not in the required order

LowConfirmedQuick wintls.certificate.chain-out-of-order

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 the whole score is calculated

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.

  1. Concatenate the certificates leaf-first into one file.

  2. Remove any duplicate and any self-signed root from the file.

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

nginx
cat leaf.pem intermediate.pem > /etc/ssl/‹host›/fullchain.pem
nginx -t && systemctl reload nginx
Apache
cat leaf.pem intermediate.pem > /etc/ssl/‹host›/fullchain.pem
apachectl configtest && systemctl reload apache2
Technical 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.

Open the tls certificate checkerBuild the fix

Other tls certificate checks