3 ms·
Yes, right. It's ISRG root certificate that's present in my OS certificate store. I was trying to troubleshoot our new web server where we have set up a let's e
by ssd532 3y ago
Yes, right. It's ISRG root certificate that's present in my OS certificate store. I was trying to troubleshoot our new web server where we have set up a let's encrypt certificate but some clients report issues. SSL lab test identifies the problem as missing intermediate certificate. Chrome doesn't have any problem accessing the HTTPS URL though. The problem I was trying to fix is my Go code that refuses to access this URL stating it can not validate the certificate. Sorry I am on mobile so can't give exact details.
This was a timely article but still left me confused.
- SAI_Peregrinus 3y agoThe web server should be configured to send the entire chain, not just its leaf certificate. Missing intermediate certs is a common cause of such issues.
- ssd532 3y agoThanks. But this is where my confusion is. I am wondering whether the certificate installed on the web server was signed by Let's Encrypt root or some intermediary (may be another let's encrypt entity). It was issued and installed using standard let's encrypt tooling for Ubuntu.
- agwa 3y agoIt was signed by a Let's Encrypt intermediate. Roots are not allowed to sign website certificates. And that's why your server needs to also send the intermediate certificate - so that clients can construct a chain of signatures from your website certificate to the root that is installed in the OS trust store.
- ssd532 3y agoAh, got it now. Thanks.
- tialaramex 3y ago[Andrew knows this but for the benefit of others] This (the fact all end entity certificates are signed by an Intermediate, never a root) is a policy of the Web PKI rather than being inherent to any conceivable system for such a purpose or to the X.509 technology in particular. Specifically the roots aren't allowed to be online by policy. So you can't use them to issue end entity certificates, when they do sign things (notably to create new Intermediates) that's a supervised activity, several humans (perhaps an officer from the organisation which owns the root, plus somebody representing their third party auditor, plus a technician to do the actual work) are typically physically present overseeing the signing process. The rest of the time the roots might live in a safe in somebody's office, that sort of thing. This sort of safeguard means even catastrophic IT failures should only result in a compromised Intermediate. Still not good, but recoverable without needing to co-ordinate large numbers of third parties or greatly annoy the Relying Parties (ordinary people).
- toast0 3y agoReally, you shouldn't send the entire chain. Just the leaf and intermediates (and maybe a cross signed root). There's no need to send the root certificate --- if the client trusts your root, it already has it; if the client doesn't trust your root, sending it doesn't help.
- woodruffw 3y agoOn top of this: sending the entire chain makes it much easier for the client to do silly and insecure things, like naively trusting any root the server presents (meaning that the connection would effectively be self-signed, rather than chained to a pre-trusted CA).
- SAI_Peregrinus 3y agoRight, the whole chain back to (but not including) the root. Every intermediate must be sent if you want maximum compatibility, roots should never be sent by anything other than an application or OS update.