3 ms·

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 c

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?

agwa 12y ago
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 https://github.com/SSLMate/mkcertchain
- jackalope 12y ago
  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.

agwa 12y ago

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 https://github.com/SSLMate/mkcertchain

jackalope 12y ago
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.