After using HTTPS, the entire process from the client to the server is encrypted and protected, and only the communicating parties can decrypt the data.
2. Understand CA certificates
CA certificates contain a lot of content, and you can master CA certificate-related knowledge from the following four aspects:
CA certificate-related terms;
CA certificate issuance process;
CA certificate authentication process;
CA certificate issuance practice.
1. CA certificate related terms
CA certificates involve many terms. The following are some core terms for reference:
(1) CA: Certificate Authority (CA for short) is an authoritative organization responsible for issuing and managing digital certificates. As a trusted third party, it is responsible for verifying the legitimacy of public keys in the public key system;
(2) CA certificate: A CA certificate is a digital certificate issued by a CA. Its format may vary. The most commonly used format is the X.509 certificate format.
(3) Public key and private key: A public key and a private key are a pair of keys generated by a specific algorithm. The public key is the public part of the key pair and is usually used to encrypt session keys, verify digital signatures, or encrypt data that needs to be decrypted by the corresponding private key. The private key is the non-public part.
(4) Encryption algorithm: A variety of encryption algorithms can be used to encrypt data. Common encryption algorithms include the following two categories:
(5) Symmetric encryption: Only one key is used for encryption and decryption, the key is the same and the encryption and decryption speed is faster. Typical symmetric encryption algorithms include DES and AES;
(6) Keys appear in pairs (public key and private key). The public key and private key match each other, and the private key cannot be derived from the public key, and vice versa. When the public key is used for encryption, it must be decrypted by the private key, and when the private key is used for encryption, it must be decrypted by the public key. Compared with symmetric encryption, it is slower. Typical asymmetric encryption algorithms include RSA and DSA.
(7) X.509 certificate encoding format: X.509 certificates may use different encoding rules. Currently, the encoding formats mainly include the following two:
PEM (Privacy Enhanced Mail): text format, the file suffix is .pem, starts with -----BEGIN XXXXXX-----, ends with -----END XXXXXX-----, and the content is BASE64 encoded. It is mostly used in Apache and UNIX servers;
DER (Distinguished Encoding Rules): binary format, the file suffix is .der, and it is unreadable. It is mostly used in Java and Windows servers.
(8) X.509 certificate file suffix: The file suffix of an X.509 certificate is not necessarily .pem or .der. The following are common types:
CRT (.crt): stands for Certificate, which is commonly found in UNIX systems. It may be encoded in PEM or DER, and most are encoded in PEM;
CER (.cer): stands for Certificate, which is commonly found in Windows systems. It may be encoded in PEM or DER, and most are encoded in DER;
KEY (.key): usually stores public or private keys. Although it is not an X.509 certificate, its encoding format may be PEM or DER;
CSR (.csr): Certificate Signing Request. CSR is not a certificate, but a request to the authoritative certificate issuing authority for a signed certificate. It mainly includes a public key and additional information. When the application is generated, a private key will be generated at the same time. You need to keep it properly and do not need to submit it to the CA organization.
It is important to note that if the certificate file has a suffix of .pem or .der, the file name should reflect the file category, for example: server-key.pem represents a private key file, and server-crt.pem represents a certificate file.
In order to better understand CA-related content, the following will focus on the CA issuance process. While introducing the process, the relevant concepts will be explained. The CA certification process is actually also the HTTPS certification process.
2. CA certificate issuance process
The CA certificate certification process is shown in the figure below:
The process shown in the figure above is explained as follows:
(1) The server submits the public key, organizational information, personal information (such as domain name) and other content to the third-party CA and applies for certification (no private key is required);
(2) CA verifies the authenticity of the information provided by the applicant through various means, such as online and offline, such as confirming whether the organization exists, whether the enterprise is legal, whether it owns the domain name, etc.
(3) If the information review is passed, CA will issue the applicant a certification document (certificate):
The certificate contains the following information: the applicant's public key, organizational information and personal information, information about the issuing CA, certificate validity period, certificate serial number and other plain text information, and also includes a signature;
Signature generation algorithm: First, use the hash function to calculate the information summary of the plaintext information, then use the CA's private key to encrypt the information summary, and the generated ciphertext is the signature.
(4) After the client sends a request to the server, the server returns the server's certificate file;
(5) The client reads the plaintext message in the server certificate and uses the same hash function to calculate the information digest. Then, the signature data is decrypted using the corresponding CA's public key and compared with the information digest. If the two are consistent, the legitimacy of the certificate can be confirmed, that is, the public key is legitimate. At the same time, the client also needs to verify the domain information, validity period, and other content in the certificate. The client usually has a built-in trusted CA root certificate (including the public key). If the CA is not trusted, the corresponding CA certificate cannot be found and the certificate will be judged as illegal;
(6) The client generates a random number R, encrypts it with the public key in the server certificate, and sends it to the server. The server uses its private key to decrypt and obtain the random number R. Then both parties use a symmetric encryption algorithm to exchange data.
3. CA certification process
CA certificate certification is divided into one-way certification and two-way certification. In actual development, you can choose according to your needs:
One-way authentication: Applicable to scenarios where user identity verification is not required at the communication layer. Generally, it is used to ensure the user's legitimate login at the application logic layer. One-way authentication is also the most commonly used authentication method in enterprise applications.
Two-way authentication: Requires both parties in communication to verify their identities. For example, when there is a mutual adjustment relationship between enterprise application services, it may be necessary to verify the identities of both parties in communication.
(1) One-way authentication process
The one-way authentication process is shown in the figure below.
The figure above clearly shows the steps of the one-way process, so I will not explain it in detail here. It should be noted that in step 3, the public key of the CA certificate (root certificate) is used to decrypt the signature.
From the above one-way authentication process, we can see that the entire process requires the following three certificate files: root certificate, server public key certificate, and server private key file.
(2) Two-way authentication process
One-way authentication only verifies the identity of the server. What if someone impersonates the client? In this case, two-way authentication can be used.
The two-way authentication SSL handshake process is different from the one-way authentication process. Most of its steps are the same as the one-way authentication process. However, after the client successfully authenticates the server, a new process step is added for the server to authenticate the client. The two-way authentication process is shown in the figure below.
From the above two-way authentication process, it can be seen that the entire two-way authentication process requires 5 certificate files: root certificate, server public key certificate, server private key file, client public key certificate, and client private key file.
4. CA certificate issuance practice
CA certificates are issued by authoritative CA organizations, and the issuance process is relatively complex and expensive. In back-end application development, developers or maintenance personnel usually generate root certificates and their private keys by themselves, and play the role of CA, responsible for issuing certificates for other servers and clients. Such certificates are also called self-signed certificates.
In enterprise application development, you can use the openssl tool to issue root certificates, server certificates, and client certificates. Using the openssl tool to issue certificates specifically includes the following steps:
Issue root certificate and private key;
Generate server certificate;
Generate client certificate;
(1) Step 1: Issue root certificate and private key
Issuing root certificate and private key includes the following 3 steps: generate root certificate private key, generate request file, and generate root certificate.
① Generate root certificate **** private key
Use the following command to generate root certificate private key:
The genrsa subcommand is mainly used to generate RSA private key. Command line format: openssl genrsa [args] [numbits]. The parameters involved are explained as follows:
-out file: save the generated private key to the specified file;
numbits: specify the size of the generated private key, the default is 2048.
② Generate a request file
Use the certificate private key to generate a request file. The command is as follows:
The req subcommand is mainly used to create a certificate request file. Its command line format is: openssl req [options] <infile> outfile. The parameter description is as follows:
-new: Create a new certificate request file;
-key file: Specify the private key file used to create the certificate request;
-out arg: specifies the output file path;
-subj arg: sets or modifies the subject information in the certificate request.
The subject information options of the certificate request are as follows:
CN (Common Name): specifies the name used to identify the identity in the certificate. The name must be unique. Usually fill in the domain or subdomain for which the SSL certificate is required;
C (Country): country code;
ST (State): state or province;
L (Locality): City;
O (Organization): Organizational name;
OU (Organizational Unit): Organizational unit name.
③ Generate root certificate
Execute the following command to generate a root certificate:
The x509 command is mainly used to create and modify x509 certificates. Its command line format is as follows: openssl x509 [options] <infile> outfile. The parameter description is as follows:
-in arg: specifies the input file, the default is standard input;
-out arg: specifies the output file, the default is standard output;
-req: specifies the input file as the certificate request;
-signkey arg: specifies the private key file for self-signing;
-CA arg: sets the CA file, which must be in PEM format;
-CAkey arg: sets the CA private key file, which must be in PEM format;
-CAcreateserial: creates a serial number file.
(2) Step 2: Generate a server certificate
Execute the following command to generate a server certificate:
In the above command, the rsa subcommand is mainly used to process RSA public and private key files. The command line format is: openssl rsa [options] <infile> outfile. The parameters involved are explained as follows:
-in arg: specifies the input file;
-pubout: specifies the output file as the public key, the default is the private key;
-out arg: specifies the output file.
(3) Step 3: Generate a client certificate
Execute the following command to generate a client certificate:
