In the previous article " Practical Cryptography for Developers - Digital Certificates ", digital certificates were introduced, but to make users trust the issued digital certificates, the CA center needs to be introduced here.
The so-called CA (Certificate Authority) certification center is an organization that uses PKI (Public Key Infrastructure) public key infrastructure technology to provide network identity authentication services. A CA can be a civil society or a government agency. CA is responsible for issuing and managing digital certificates, and is authoritative and impartial. Its role is like the company that issues certificates in our real life, such as passport agencies.
Root CA Trust Model
Faced with such a wide range of users around the world, only one CA is obviously not enough. PKI introduces "trust model", which is used to describe and analyze the establishment and transfer process of trust relationship within the same CA management domain or between different CA management domains. The PKI trust model mainly adopts the root CA trust model, also known as the strict hierarchical trust model.
Under this trust model, CA centers can be divided into multiple levels, and there is a strict hierarchical relationship between CA centers at all levels. There is only one top-level CA center, which is called root CA, and other CAs are called sub-CAs. The digital certificate of the root CA is issued by itself and is a self-signed certificate, and the digital certificate of the sub-CA is issued by the superior CA. A trust anchor can be a root CA or a sub-CA.
In the above figure, user X's trust anchor is the root CA, so it can trust sub-CA1 and thus trust user A's certificate. The chain of trust is root CA -> sub-CA1 -> user A's certificate . User Y's trust anchor is sub-CA2, so it can trust sub-CA4, thus trusting user D's certificate, and the chain of trust is sub- CA2 -> sub-CA4 -> user D's certificate .
Note, don't be misled by the above picture, there is more than one root CA in the world, it should be said that the CA in the real world is a multi-root CA trust model .
To establish a trust anchor, you need to obtain a CA certificate (according to the previous description, it can be a root certificate, a secondary or tertiary certificate, or a user certificate). How to obtain this certificate? Will I get a fake certificate? In fact, the answer to this question is very simple, and it may be beyond our expectations, that is, the preset root certificate.
Preset root certificate
According to the previous CA model, the application does not need to preset all CA certificates, but only needs to preset the certificate of the top-level CA (usually called the root certificate), and the number of top-level CA centers in the world is limited, about a dozen , so there will be no storage problems. Of course, if we look at the root certificates preset by the system, we find that the number seems to be far more than that, because for the convenience of program processing, we may also preset some secondary CA certificates. For example, China's CA center may only be a secondary CA center in the world, and we often verify the certificates issued by the Chinese CA center. At this time, these secondary CA certificates are preset, which can prevent the verification chain from being too long during certificate verification and improve efficiency.
The format in which the root certificate is stored and where it is stored is related to the implementation of the application. Take the browser as an example, the Windows system certificate storage area used by the Chrome Windows version, and the processing of the certificate is also to call the Windows CryptoAPI. The root certificate of the Chrome Linux version is stored in the NSS database. In the Android version of the Chrome browser, the preset certificate of the Android system is used. And with the upgrade of the version, these policies may also be adjusted.
The method of presetting the root certificate also has certain shortcomings, that is, it is assumed that the top CA centers in the world are unchanged. In fact, with the increasing demand for digital certificates on the Internet, the top-level CA center is also expanding, which leads to the fact that the certificates issued by the new CA center may not be recognized in the existing system. Also, sometimes you trust the certificate even though it was not issued by these authoritative CA centers. For example, the 12306 website in the early years used a self-signed certificate instead of a certificate issued by the CA center.
Therefore, most software provides certificate management function, you can import the certificate, the following picture is the certificate management interface of chrome browser:
Some software is more flexible and convenient, such as the chrome browser, which allows you to choose whether to trust or not when encountering a suspicious certificate. If you choose to trust, you can continue to visit.
So certificates are essentially a trust issue. Why browsers and operating systems preset certificates is because developers trust these CA centers and the certificates they issue. In other cases, some software may let users make choices, such as browsers, while some software does not give users choices, such as players, and will directly reject untrusted certificates.
Build the State Secret CA Center
The CA center sounds like a very big name. In fact, individuals can also complete the CA center and issue certificates. Of course, these are no problem for testing purposes. As for whether it is feasible in practice, it depends on the ability to fool.
The CA in the real world is managed hierarchically, and the hierarchy can have multiple layers. For the sake of simplicity, this article only simulates three-level CA management, specifically:
Root CA -> Server CA -> Server
Root CA is a primary CA with root CA certificate, Server CA is secondary CA, its CA certificate is issued by Root CA, Server is an end user, and its certificate is issued by Server CA. Of course, the Root CA can also directly issue a certificate to the Server. This is an assumption made here to demonstrate the needs of the CA level.
Make a root CA certificate
Generate SM2 private key:
$ gmssl ecparam -genkey -name sm2p256v1 -text -out rootkey.pem
The private key of the root certificate is stored in rootkey.pem, please keep it properly.
Create a certificate request:
$ gmssl req -new -key rootkey.pem -out rootreq.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [Some-State]:Hubei
Locality Name (eg, city) []:Wuhan
Organization Name (eg, company) [Internet Widgits Pty Ltd]:China LianTong
Organizational Unit Name (eg, p) []:
Common Name (e.g. server FQDN or YOUR name) []:www.china_liantong.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
The above command will ask for some information, since the certificate is self-signed and only used for development testing, it doesn't matter what you fill in.
Create a certext.ext text file with the following content:
[ v3_ca ]
basicConstraints = CA:true
[ usr_cert ]
subjectAltName = DNS:localhost
"CA:true" This extension is used to specify whether the issued certificate is a CA certificate.
Generate certificate:
$ gmssl x509 -req -days 365 -in rootreq.pem -signkey rootkey.pem -extfile certext.ext -extensions v3_ca -out rootcert.pem
Signature ok
subject=C = CN, ST = Hubei, L = Wuhan, O = China LianTong, CN = www.china_liantong.com
Getting Private key
The generated root certificate file is rootcert.pem.
Note: The above command line parameters have an additional -extensions v3_ca parameter, which specifies the extension items in the v3_ca section of the certext.ext file above.
Issue the Server CA certificate
As with the above steps, here is a direct summary of the commands:
$ gmssl ecparam -genkey -name sm2p256v1 -text -out serverCAkey.pem
$ gmssl req -new -key serverCAkey.pem -out serverCAreq.pem
$ gmssl x509 -req -days 365 -in serverCAreq.pem -extfile certext.ext -extensions v3_ca -CA rootcert.pem -CAkey rootkey.pem -CAcreateserial -out serverCAcert.pem
It should be noted that the third command has more -CA and -CAkey parameters, indicating that the root certificate and CA's private key are used.
This way we can use the Server CA certificate and private key to issue user certificates.
Issue a server certificate
As with the above steps, here is a direct summary of the commands:
$ gmssl ecparam -genkey -name sm2p256v1 -text -out serverkey.pem
$ gmssl req -new -key serverkey.pem -out serverreq.pem
$ gmssl x509 -req -days 365 -in serverreq.pem -extfile certext.ext -extensions usr_cert -CA serverCAcert.pem -CAkey serverCAkey.pem -CAcreateserial -out servercert.pem
Note: The parameter value given by -extensions of the third command is usr_cert, which corresponds to the extension item in the usr_cert section of the certext.ext file, and usually requires the DNS name of the given server. It can also be seen that the certificate of the leaf node and the CA certificate still have some different attributes.
In this way, the generated server.pem contains the root certificate, Server CA certificate and Server certificate, including the complete certificate chain, which can be used for testing. You can try importing the root certificate in the chrome browser:
certificate chain
In the browser, we can view the certificate information. Generally speaking, the certificate usually presents a multi-level state.
The server is configured with the server entity certificate issued by the CA, and the client (browser or operating system) is preset with the root certificate. Now the question is, how to obtain the intermediate certificate?
According to the X.509 standard, the server should send the complete certificate chain (excluding the root certificate). If the certificate sent by the server side is incomplete, some clients can go and try to build a complete certificate chain, but some browsers may not do this, and the whole HTTPS protocol handshake will fail.
The method to find the complete certificate chain based on the server entity certificate is very simple. The browser obtains the CA key identifier (Authority Key Identifier) from the server entity certificate, and then obtains the upper-level intermediate certificate file, and then passes the CA key in the intermediate certificate. The identifiers are iterated until the root certificate is obtained.
The advantage of the server sending the complete certificate chain is to improve the handshake speed, and the browser does not need to search for other intermediate certificates, which can speed up the HTTPS handshake process.
Verification process:
The browser obtains the public key from the upper-level certificate (such as the B certificate) of the server entity certificate, which is used to verify the signature of the server entity certificate. If the verification is successful, it will continue, otherwise the certificate verification will fail.
The browser obtains the public key from the upper-level certificate of the B certificate (such as the C certificate), which is used to verify the signature of the B certificate. If the verification is successful, it will continue, otherwise the certificate verification will fail.
The verification process iterates continuously until the browser finds that the issuer and user of a certain certificate are the same person, which means that the root certificate has been found. Verifying the signature of the root certificate is not the same as verifying the signature of the non-root certificate. The public key used to verify the signature of the root certificate is in the root certificate, while the public key used to verify the signature of other non-root certificates is from the upper-level certificate. , the root certificate uses its own public key to verify the signature. If the verification is successful, it means that the verification of the complete certificate chain is successful.
Certificate integrity check
The X.509 standard does not specify the standard for verifying certificates, and different browsers have different rules for verifying certificates. Generally speaking, verification mainly includes four aspects:
Validation of the certificate chain. It is mainly to iteratively verify the signature of each certificate, and finally find the self-signed root certificate. Since the browser has integrated the root certificate, it can fully trust the public key of the root certificate to complete the final signature verification. However, a successful signature verification can only mean that a server certificate is indeed signed by a root certificate, and does not mean that the authentication is successful.
Verification of the server entity certificate. The main verification is as follows:
(1) Whether the domain name accessed by the browser matches the domain name included in the certificate Subject Alternative Name (SAN) extension, if not, the verification fails.
(2) Date verification, the certificate includes the validity period, and the effective time is in the range of {notBefore, notAfter}. If the certificate expires, the verification fails.
(3) Certificate extension verification (optional). For example, if the extension Critical is marked as True, the client MUST handle the extension correctly, otherwise the validation fails. For another example, browsers usually verify the Key Usage extension. If the value corresponding to the extension does not contain Digital Signature and Key Encipherment, the verification fails.
Intermediate certificate.
(1) Date verification, the validity period of the verification certificate.
(2) If the certificate extension Critical is identified as True, it must be verified.
(3) The intermediate certificate also contains a public key, and the purpose of the public key needs to be verified. The verification method is to determine the Key Usage extension. If the value corresponding to the extension does not include Digital Signature (digital signature), Certificate Sign (signing certificate), CRL Sign (signing CRL), verification failed.
(4) Check the basic constraints extension, check whether the intermediate certificate can issue the certificate, if it is not allowed to issue, the check fails.
Revocation status check. The validation logic is very complex, and some browsers may abandon the revocation status check. It should be noted that both the server entity certificate and the intermediate certificate need to check the revocation status, but how to check depends on the browser, these are not the standards of the TLS/SSL protocol.
summary
The series of articles "Practical Cryptography for Developers" has come to an end. In fact, network security and system security are far more than encryption and decryption, signatures, certificates, etc., but cryptography is the foundation of network security. While supplementing my knowledge of cryptography, I also have a better understanding of network security. Later, I will conduct research on national secrets, network security, HTTPS, HTTP/2, etc. Welcome to discuss and exchange.
