Before further discussion, we need to introduce the concept of certificate chain. Ask a question: How does your browser know whether to trust the SSL certificate of the website? Any subordinate certificate of the trusted root is trusted. How does this work on a technical level?
When you visit a website, the browser will check its SSL certificate and quickly verify the authenticity of the certificate. The browser will check the validity of the certificate, ensure that the certificate has not been revoked, and verify the digital signature of the certificate.
Browser operations to verify certificates along the certificate chain. To obtain an issued SSL certificate, you must first generate a certificate signing request (CSR) and a private key. In the simplest iteration, you send CSR to the certification authority, and then it signs the SSL certificate with the private key from its root and sends it back.
Now, when the browser sees the SSL certificate, it will see that the certificate is issued by a trusted root in the root store (or, more accurately, signed with the root's private key). Because it trusts the root, it trusts any certificate signed by the root. To make it easier for you to understand, we have simplified the above content and linked the server certificate directly to the root. Now join the intermediate certificate.
Certificate authorities do not issue server/leaf certificates (end-user SSL certificates) directly from their root certificates. These root certificates are too precious and it is too risky to issue them directly.
Therefore, in order to protect the root certificate, CAs usually issues a so-called intermediate root. CA uses its private key to sign the intermediate root, making it trusted. Then, the CA uses the private key of the intermediate certificate to sign and issue the end-user SSL certificate. This process can be performed many times, in which one intermediate root signs another intermediate root, and then the CA uses this root to sign the certificate. These links, from root to middle to leaf, are all certificate chains. The following is a visual graph of the certificate chain. In order to make it easier to understand and simplify the complicated process, we only add an intermediate certificate to the certificate chain, and the actual certificate chain is usually much more complicated.
You may notice that when a CA issues an SSL certificate, it also sends an intermediate certificate that needs to be installed. In this way, the browser can complete the certificate chain and link the SSL certificate on the server back to one of its roots. Browsers and operating systems handle incomplete chains in different ways. Some will only issue problems and report errors when the intermediate certificate is lost, while others will save and cache the intermediate certificate to prevent it from being used in the future.
Digital signature is a bit like notarization in digital form. When the root certificate digitally signs the intermediate certificate, it actually transfers part of the trust to the intermediate certificate. Because the signature comes directly from the private key of the trusted root certificate, it is automatically trusted.
Whenever you provide an SSL certificate to a browser or device, it will receive the certificate and the public key associated with it. It verifies the digital signature through the public key and sees who generated it (that is, which certificate signed it). You can start piecing these together now. When your browser verifies the end-user SSL certificate on the website, it will use the provided public key to verify the signature and move a link up the certificate chain. Repeat this process: verify the signature and track the signed certificate chain until it finally reaches the root certificate in the browser trust store. If it cannot link the certificate back to its trusted root, it will not trust the certificate.
This is actually very simple. A root CA is a certification authority with one or more trusted roots. This means that they are rooted in the trust library of mainstream browsers. An intermediate ca or a sub-ca is a certification authority issued by an intermediate root. They have no roots in the browser's trust store, and their intermediate roots will be linked back to a trusted third-party root. This is sometimes called cross-signing.
As we discussed earlier, CAs do not issue certificates directly from their roots. They improve the security of root certificates by issuing intermediate certificates and signing them with intermediate certificates. This helps to minimize and disperse losses in the event of wrong transmission or safety accidents. When a security incident occurs, it is not necessary to revoke the root certificate, but only the intermediate certificate, so that the certificate group issued from the intermediate certificate cannot be trusted.
We have just described roots and intermediates, which involve the trust model of certification authority, certificate chain and encrypted signature. In essence, it boils down to one word: PKI or public key infrastructure. So far, I have avoided using this term too much. It looks abstract unless you know some details in depth.
This article is quoted from:
FreeBuf.COM
Self-made Https certificate and use it in Spring Boot and Nginx