Nginx configures https access to generate ssl self-signed certificates, which can be directly accessed by browsers

question

Nginx configures a self-signed ssl certificate to support HTTPS access to nginx. When accessing nginx in a browser, it prompts that there is a risk. When accessing other major websites, the https protocol is also used. Why can it be accessed directly without prompting that there is a risk?

Dispel doubts

Let's start with the ssl certificate. Whether to use the https protocol or whether to use ssl authentication is determined by the background website server. If you want to use the https protocol, you can configure the ssl certificate in the background service. After the ssl certificate is configured, the browser must use the https protocol to access the website service. In this process, the browser will first obtain the certificate information in the website server, and then the browser itself maintains a list of trusted certificates. As long as the certificate returned by the website service is in the trusted certificate list, it means that the service is safe, and the browser can directly access the service. If the returned certificate is not in the trusted list, the browser thinks that the service is insecure and will send an alarm message, but the user can manually choose to trust the website and continue to access the service.
As can be seen from the above description, after using the ssl certificate, it is the browser to verify whether the server's certificate is trusted for security reasons, and the trust can be used for direct access. The HTTPS protocol browser of Dachang’s website did not issue an alarm because Dachang uses SSL certificates authorized by a third party. These certificate browsers are trusted certificates by default, so they can be accessed directly. However, third-party authorized SSL certificates generally require a fee to obtain.
The certificate used in this project is a self-signed certificate, which is not in the browser's trusted certificate list, so an alarm is issued.

The above mentioned is https single authentication, that is, the browser authentication background service certificate. You can also enable two-way authentication, that is, the browser authenticates the server certificate, and the server also authenticates the browser certificate. But for public websites, one-way authentication is generally enough.

solve

From the above description, we can see that if you want to prevent the self-signed certificate from alarming in the browser, you must add it to the browser trust list. I searched many methods on the Internet for nginx to generate certificates and add them to the browser trust list, but most of them cannot skip the browser's alarm. The following records the certificate generation method and configuration method that can successfully skip the browser alarm.
Use the tools provided by java to generate.
first step:

keytool -genkeypair -keyalg RSA -dname "CN=Demo" -alias server -keystore server.jks -keypass 123456 -storepass 123456 -ext SAN=dns:域名,ip:后端服务ip

Generate server.jks file.

Step two:

keytool -exportcert -file server.cer -alias server -keystore server.jks -storepass 123456

Generate server.cer file.

third step:

keytool -importcert -file server.cer -alias server1 -keyalg client_trusk.jks -storepass 123456 -keypass 123456

The output is as follows:
insert image description here
just enter yes.

the fourth step:

keytool -importkeystore -srckeystore server.jks -destkeystore server-pkcs12.p12 -deststoretype PKCS12

insert image description here
Just enter the corresponding password. Generate server-pkcs12.p12 file.

the fifth step:

openssl x509 -inform der -in server.cer -out server-pem.pem

The server-pem.pem file is generated.

Step six:

openssl pkcs12 -nocerts -nodes -in server-pkcs12.p12 -out server.key

Generate server.key file.

Step 7:
Configure the server.key file and server-pem.pem file into the config configuration file of the nginx service, and install the server.cer file in the trusted list of the browser. In this way, when the browser accesses nginx, it can directly access without alarming.

Reference article: Nginx certificate configuration: cer file and jks file to nginx certificate.crt and key file
(Note: There is a problem with the method of the reference article. The nginx configured according to the reference article cannot make the browser skip the alarm. This blog will update the article optimized and corrected)

expand

In the above operation, a total of the following files were generated:
insert image description here
in the end, only three of them were used. So what are these files for? For details, please refer to the article on the explanation of the suffixes of various certificates and key files such as PEM, DER, CRT, CER, KEY, etc. Here we only make a simple record.

In the above steps, the jks file is generated in the first step, and the jks file represents the Java keystore. It contains both the certificate and the private key.

In the second step, in the jks file generated in the first step, the cer file is exported. The cer file only contains the certificate and does not save the private key. Generally, Linux uses the .crt suffix, and .cer is the windows suffix. Because jks includes both the private key and the certificate, so in the second step, the certificate is extracted and becomes a cer file. And this cer file is also the certificate file that needs to be finally installed in the browser to the trusted list.

The third step is also an operation on the cer certificate, such as making the certificate trusted, fixed operation, just remember.

The fourth step is to convert the jks file generated in the first step into a p12 format file. The p12 file is in binary format and contains both the certificate and the private key. It can be seen that the format of the jks file is changed, and p12 also contains the certificate and private key.

The fifth step is to convert the cer certificate to pem format. The pem file is a plain text file encoded with Base64 ASCII. Regardless of whether it is a certificate or a key, as long as it is in pem format, opening it with a text editor will look similar, a string of lengthy strings. It can be seen that pem is just a file format, and both certificates and private keys can be converted into pem format. Here is to convert the certificate into pem format.

The sixth step is to convert the p12 file into a .key file. The .key file is a private key, which is paired with the certificate one by one. The private key in the p12 file is about to be extracted.

The seventh step is to configure the .key file (private key) and .pem file (certificate) into nginx, and configure the .cer file (windows format certificate) into the browser trust list, thus skipping the browser alarm.

The difference between public key/private key/certificate

In the ssl certificate, there will be a public key for a while, a private key for a while, and a certificate for a while, which is completely deceived. Let's sort it out:
First, the private key is placed in the server. As in nginx above, the .key file (private key) is placed on the server.
The certificate is the SSL certificate configured in the server. For example, the pem file in nginx is the certificate, and the certificate also contains the public key. When a browser accesses a website with the SSL protocol, it will obtain the website certificate and the public key at the same time. Then the browser takes the obtained public key and transmits it to the website, and after arriving at the server, the server decrypts the data through the private key. So https uses asymmetric encryption to ensure data security.

In the SpringBoot project configuration https access single authentication Google valid certificate article, only one .keystore file is configured in the background. It is because the .keystore file is not only a certificate file, but also contains a public key and a private key.

Guess you like

Origin blog.csdn.net/qq1309664161/article/details/127962653