Qualys/SSL Labs reports Chain issues: Contains anchor
A run of the Qualys/SSL Labs test of segments* machines (e.g., found here: https://globalsign.ssllabs.com/analyze.html?d=segments-backup.ligo.org&hideResults=on) gives each segments* server a grade of "A", but reports a minor issue in the Additional Certificates (if supplied)
section: Chain issues: Contains anchor
.
A search for the issue turned up a page by Qualys, which says:
It means that you have added Intermediate as well as Root CA, when you only need the Intermediate as the client will already have Root CA (will be already trusted by browser in browser certificate store). You can get the same info using openssl command:
echo "" | openssl s_client -connect test.stomt.com:443 2>&1 | grep -A 6 "Certificate chain"
It's not an issue in the sense that the anchor is not allowed, but that the extra certificate (which serves no purpose) is increasing the handshake latency.
Because of TCP slow start, the first bytes on a connection are the slowest. Hence, you can minimize the size of the handshake so that HTTP bytes can start flowing as soon as possible. So the issue is not so much "can the extra certificate fit into the initial window" (it most likely can, even with the old setting of 3 network segments), but "what other, more useful, data could we be sending instead".
However, there is no security risk with "Contains anchor", you can largely ignore the "Contains Anchor" warning. Fixing it would possibly save bandwidth slightly and increase the performance.
I think I have noticed that the first of several command-line queries takes noticeably longer than subsequent queries, so I thought that this might be the cause. Since I don't know enough about CAs, I asked Juan about it. He replied:
With the CertficateChainFile undefined, the rating went from "A" to "B" because of incomplete chain. I think any performance increase might be negligible so we'd better off leaving it as is.
I'm not 100% sure that was the fix I was asking about, so I'm creating this ticket for possible further investigation.
Since this ticket is open, I'll note that the other items in the above test (and I think the same for every segments* machine tested) are as follows:
-
DNS CAA: No
This is a warning, not error, and it has a link to this page, which says:
Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. ... The fact that any CA can issue a certificate for any domain name is commonly cited as the weakest aspect of the PKI ecosystem. ... CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. It's not at all clear that this will significantly improve security, since compliance is voluntary.
- In
Handshake Simulation
, several simulations (all older browsers:IE 11 / Win Phone 8.1
andSafari 6 / iOS 6.0.1
throughSafari 8 / OS X 10.10
) reportServer sent fatal alert: handshake_failure
. I don't think we want to spend much time trying to figure out why very old browsers are having handshake issues, since no one should be using those browsers anymore anyway (IE is dead, and latest Safari test is forSafari 12.1.1 / iOS 12.3.1
). - In
Protocol Details
, theDROWN
test reportsUnable to perform this test due to an internal error.
andINTERNAL ERROR: test.drownattack.com
. It's not clear what is causing this test to fail to run or how to fix it. It is listed as a warning, not an error, but it might be worth a little bit of time to investigate.
Overall, the servers each got a rating of A
on 2023.11.23, with scores of 100% for Certificate
and Protocol Support
and 90% for Key Exchange
and Cipher Strength
.