Hacker News Reader

Comment by tomkinstinch | Hacker News Reader

Nice work; this is a good tool to have in the world. The Qualys test[1] may be more comprehensive, but it is also much slower if you only need to examine certificate chain issues.

1. ex, albeit cached: https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...

View on HN

Thanks!

Yes, the SSL Labs test is way more comprehensive. I think a single-purpose tool is still valuable because it provides background about chain certs, and if it detects a misconfiguration, it provides a link to download the correct chain.

Absolutely! Single-purpose tools are great.

I actually have a few questions about cert chains: Is it necessary to have the entire chain? Or only the last few certificates (closest to the site certificate)? Is it any faster to have a shorter cert chain, or are there ways to optimize the cert chain for speed? (encodings? compression?) A small FAQ on cert chain background would be a nice addition to the site.

Would it be make sense to add a quick check for OCSP Stapling too, since that is related to the cert chain setup?

Your chain should start with the certificate that signs your server's certificate and continue up to, but not including, a root certificate that's trusted in all browsers.

Certificates can have multiple chains to a root certificate, some longer than the others, so to optimize you should pick the shortest chain. There's a trade-off to be made with browser support, because a short chain might be to a root that's not trusted in all browsers. The chain cert generator[1] picks the shortest chain that's to a root that's trusted in all reasonably recent browsers (basically everything you're likely to encounter today except Android 2.2, which is woefully lacking in both root certificates and modern TLS support).

An FAQ is a good idea; OCSP stapling seems a little out-of-scope but I'll think about it.

[1] source code here = https://github.com/SSLMate/mkcertchain

Doesn't it seem that configuration is needlessly complex for certificates? I think it would be easier to list the entire chain in one directive:

    TLSCertificates /path/to/host.crt /path/to/intermediate.crt /path/to/root.crt

That would support any number of intermediates and remove the need to concatenate certificates into a single file. Terminating with the root certificate would be optional, but if present the server could perform a check to verify the chain to the very end when starting.

Just as an aside: the SSL Labs test is slow on purpose -- that's how we stay under the radar and avoid too many complaints from server operators. That said, it's a common complaint and I intend to optimize some operations in the next major version.

Honestly, all credit is due to CloudFlare. They get this stuff right and you need to worry much less about it. Not that the HN server tests poorly, but I can't check since they started disallowing IPs.

Reply on news.ycombinator.com