First, the steps are shorthand //Generate the public key certificate and private key file of the top-level CA, valid for 10 years (RSA 1024bits, default) openssl req -new -x509 -days 3650 -keyout CARoot1024.key -out CARoot1024.crt //The top-level CA's private key file removes the protected password openssl rsa -in CARoot1024.key -out CARoot1024.key //Generates the top-level CA's public key certificate and private key file, valid for 15 years (RSA 2048bits, specified) openssl req -newkey rsa: 2048 -x509 -days 5480 -keyout CARoot2048.key -out CARoot2048.crt //Remove the protection password for the top-level CA's private key file openssl rsa -in CARoot2048.key -out CARoot2048.key //Generate private for the application certificate/intermediate certificate Key file openssl genrsa -out app.key 2048 //Generate csr file (certificate request file) for application certificate/intermediate certificate according to private key file openssl req -new -key app.key -out app.csr //Use CA The public and private key files are signed to the csr file to generate an application certificate, which is valid for 5 years openssl ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024. Key -days 1826 -policy policy_anything //Sign the csr file with the CA's public and private key file to generate an intermediate certificate, valid for 5 years openssl ca -extensions v3_ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024 .key -days 1826 -policy policy_anything The above are all the commands to be used in the process of generating the root certificate and applying the certificate. They are divided into three groups according to the generation target. The first two groups are used to generate a self-signed top-level CA (the difference is only in the key length). In actual applications, only one group can be selected according to requirements. The last set is used to generate non-self-signed certificates, including intermediate and application certificates. The so-called intermediate certificate is a sub-CA with the authority to continue to issue subordinate certificates. The application certificate mentioned in this article refers specifically to a certificate that cannot be used to continue to issue subordinate certificates and can only be used to prove individual identity. When the top-level CA issues both, it is only the difference between the -extensions v3_ca option, which gives the issued certificate the right to continue issuing the sub-certificate. Second, the detailed steps 2.1 Generate a self-signed root certificate (ie top-level CA) Typical example: openssl req -new-x509 -days5480 -keyoutCA.key -outCA.crt [1] Command options and parameter interpretation In the example, each option (and The meaning of the parameter) is as follows: req Use the req subcommand of openssl -new to generate a new certificate request -x509 generate a self-signed certificate -days 5480 The self-signed certificate is valid for 5480 days (15 years) [only valid when the -x509 option is used 】 -keyout CA.key The private key file name is specified as CA.key. If the private key file exists before the operation and the original name is not CA.key, the name is changed to CA.key; otherwise, the newly generated private key file is named CA.key] -out CA.crt Specifies to output the information generated by the self-signed certificate to the file, and the file name is CA.crt [recommended not to be omitted] Among them, the -days, -keyout options can be omitted, if omitted, the default is used. Value, the default period is 30 days [specified by the internal initialization of the variable in the program, regardless of the configuration file], the default value of the private key file name is specified by the relevant entry in the configuration file openssl.cnf, not changed As privkey.pem. The option -out, if omitted, openssl does not output the generated certificate/certificate request as a file. Instead, it prints the file information directly to the screen by default, which in most cases does not meet our requirements. So it is best not to omit this option! The req subcommand can use the -key option to specify an existing private key file for the certificate request. However, in the case of the example, although the -new and -x509 options are used, but the -key option is not used, the req subcommand automatically generates an RSA private key for the self-signed certificate, the default for the key length. The value is specified by the relevant entry in the configuration file openssl.cnf, which is 1024 bits if it has not been changed. [2] About the designation of the private key file encryption password During operation, you will be prompted to enter the encryption password as follows: writing new private key to 'CA.key' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: This password is used to encrypt the private key The private key information in the file CA.key, if you do not want to enter the encrypted password during the run, you can use the option -passout to specify directly in the command. The option -passout is of the form: -passoutarg where arg is the argument to the option -passout and has a variety of formats. See the "OpenSSL Official Documentation" for an introduction to "PASS_PHRASE_ARGUMENTS". The commands in the typical example of this section can be modified with the option -passout as follows: openssl req -new-x509 -days5480 -keyoutCA.key -out CA.crt-passoutpass:1314 Since the history command record can be viewed using the history command in Linux systems, Therefore, for security reasons, it is generally not necessary to specify the password directly in the command. This is consistent with the reason that mysql login does not specify the login password directly in the -p option. [3] About the DN field in the certificate request file During operation, you will be prompted to enter some Distinguished Name fields, that is, the certificate identification name information field, referred to as the DN field, as follows: You are about to be asked to enter information that will be incorporated into There you can have a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', ----- Country Name (2 letter code) [GB]: US State or Province Name (full name) [Berkshire]: California Locality Name (eg, city) [Newbury]: Organization Name (eg, company) [My Company Ltd]: GeoAuth Inc. Organizational Unit Name (eg, section) []:. Common Name (eg, your name or your server's hostname) []:Authentication Global Root Email Address []:. Most of these DN fields have default values, and the default values are specified by the relevant entries in the configuration file openssl.cnf. To use the default value in a DN field, you don't need to enter any information, just click the "Enter" key; if the value of a certain DN field is to be set to null, enter a '.' and click "Enter" ;key. These DN fields are primarily used to identify the identity of the certificate holder. The following table is abbreviations, descriptions, and some instructions for completing them. [This section refers to the SSL entry of the interactive encyclopedia] DN field name Abbreviation Description Fill in the requirements Country Name C Country of the certificate holder Requirement of the country code, with 2 letters State or Province Name ST Certificate holder's state or province Fill in the full name, you can omit the default. Locality Name L The city where the certificate holder is located Can be omitted. Organization Name O The organization or company to which the certificate holder belongs. It is best to fill in the Organizational Unit Name OU. The holder of the certificate holder can be omitted. Common Name CN Common name of the certificate holder Required. For non-applied certificates, it should be unique to a certain extent; for application certificates, the server domain name or wildcard-style domain name is generally filled in. Email Address The certificate holder's communication mailbox can be omitted. Explanation of Table 2-1 DN field