This means that at the end of this month, all Microsoft production lines (such as Edge) will also directly trust the root certificate of Let's Encrypt (ISRG root X 1), so all mainstream products in the world will directly support its root certificate. So what does this mean? What is direct trust? What is the impact on people who use Let's Encrypt certificates? Listen to me slowly.
The news said:
Maybe you fainted. In order to understand, we must understand the concept of certificate chain.
The certificate chain is a trust chain, and the relationship is as follows:
Take the certificate issued by Let's Encrypt as an example. The certificate applied by the applicant can be called a server certificate. Run openssl to view the certificate. The key information is as follows:
This means that the server certificate is *. Simple, it is digitally signed by the intermediary certificate encryption authority X3, which means that the server certificate is trusted by the intermediary certificate authority X3.
This intermediate certificate belongs to Let's Encrypt CA organization and is used to issue server certificates. It should be noted that there may be multiple intermediate certificates, which are signed iteratively.
Who signed the intermediate certificate? Run the following command:
The intermediate certificate is signed by the root certificate of DST root CA X3 (the root certificate of IdenTrust CA). Students may be surprised. Why not let us sign the intermediate certificate with our own root certificate encryption? This is a good question.
The fundamental reason is that Let's Encrypt, as a new CA organization, has a short history. Most browsers cannot trust its root certificate directly. Without trust, they can't build a trust foundation. What do we do to make Let's Encrypt put into operation quickly? It uses the root certificate organized by IdenTrust CA (directly trusted by mainstream products, such as this root certificate is included in the trusted root certificate list of Chrome) to cross-authenticate its intermediate certificates, so that mainstream products can trust the Let's Encrypt server certificate, and finally the chain of trust chain: server certificate >; Let's encrypt the authoritative X3 intermediate certificate-> DST root CA X3 root certificate.
If students also use Let's Encrypt certificate, they can look at the certificate chain and open the Chrome developer tool, as shown in the following figure:
Essentially, Let's Encrypt has two certificate chains (which have existed for a long time), as follows:
The green line is the certificate chain currently in use. If mainstream browsers trust the root certificate of Let's Encrypt (ISRG root X 1), then a certificate chain marked with a red line can be adopted. That is, the chain of trust: server certificate >; Let's encrypt the authoritative X3 intermediate certificate-> ISRG root X 1 root certificate.
After my configuration, my website certificate chain is as follows:
Students may ask, how is this done? Don't worry.
Essentially, let's encrypt the intermediary certification authority X3 with two certificates, namely:
They can all sign the Let's Encrypt server certificate (using the same private key), which is the key. These two certificates are signed by ISRG root X 1 and DST root CA X3 respectively.
Smart students may have thought that when applying for the certificate of Let's Encrypt, Let's Encrypt currently uses the authority X3 (IDENTRUST cross-signed) of LET's Encrypt to sign it. After obtaining the certificate, the applicant configures the certificate chain (server certificate+intermediate certificate) to provide HTTPS service. Browser authentication certificate. At first glance, the intermediate certificate is signed by Let's Encrypt Authority X3 (IdenTrust Cross Signature), and finally the root certificate of IDENTRUST is found to complete the signature verification.
Today's blog said that when applying for the certificate of Let's Encrypt, Let's Encrypt can use Let's Encrypt Authority X3 (the signer is ISRG root X 1) to sign it. After obtaining the certificate, the applicant will configure the certificate chain (server certificate+intermediate certificate) to provide HTTPS service. Browser authentication certificate. At first glance, the intermediate certificate is signed by Let's encrypt authority x3 (signed by ISRG root x 1). Finally, the root certificate of Let's Encrypt ISRG root X 1 is found to complete signature verification.
In fact, when applying for a certificate, Let's Encrypt still uses IdenTrust cross-signed intermediate certificate to sign the server certificate. What is the reason? Although mainstream products (such as Chrome) have directly trusted their root certificates, there are many old versions of these products. If not updated, these versions still don't trust the root certificate of Let's Encrypt. Let's Encrypt predicts that these old versions will no longer exist in five years. At that time, Let's Encrypt can boldly use the intermediate certificate of Let's Encrypt Authority X3 (signed by ISRG Root X 1) to issue server certificates.
Did you beat us? Can you manually make your website use the new certificate chain? The answer is yes (if we don't consider the problem that the old product line doesn't trust Let's Encryptisrg X 1 root certificate).
As mentioned above, the server certificate can be signed with any of the following intermediate certificates:
Any key is the signature private key of these two certificates is the same. Can we configure our own certificate chain (red line)? Yes:
Then restart your server and use the Chrome browser developer tool to observe the certificate chain of the website. The result is this: