Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to use self-signed CA to configure HTTPS encrypted reverse proxy access, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

Write at the front

With the development of the Internet, many companies and individuals pay more and more attention to the security of the network, and more and more companies use HTTPS protocol instead of HTTP protocol. Why is HTTPS more secure than HTTP? Friends, let's do it on our own! I won't say it. Today, let's talk about how to configure Nginx's HTTPS encryption reverse proxy using self-signed CA. Ahem, guys, get in the car.

Implementing HTTPS with Nginx

For the sake of security access, the CA used is self-signed by native Openssl, so it cannot be verified by Root CA, so there will be a prompt that the site is not trusted or the security certificate is invalid. Just skip it and visit it directly!

The principle and access process of HTTPS

Server necessary conditions

A server private key KEY file

A CA certificate that matches the server domain name (public key, generated from the private key key)

Access process

(1) the client browser accesses port 443 of the server through https protocol and obtains the server's certificate (public key). At this time, the client browser will find some Internet trusted RootCA (authoritative certificate authority) to verify whether the certificate currently obtained is legal and valid. PS: these RootCA are installed in the system by default along with the operating system.

(2) if the RootCA verification is passed, the certificate is trusted, and if the server name indicated in the certificate is the same as the URL address of the server currently visited, the public key contained in the certificate will be used directly to decrypt the web page content transmitted by the server encrypted through its own KEY (private key), thus displaying the page content normally.

(3) if the RootCA verification fails, the certificate has not been signed and authorized by a legitimate RootCA, so it cannot prove the authority of the server currently visited. The client browser will display a warning at this time, indicating that the identity of the server you are currently visiting cannot be verified, and ask the user whether to continue browsing! (this is usually the case with self-signed CA certificates)

It should be noted here that verifying the validity of CA only proves whether the identity of the current server is legal and valid, whether it has credibility and identity uniqueness, so as to prevent others from imitating the site. However, it will not affect the encryption function of the web page. Although the CA certificate cannot be certified by authority, the public key it contains and the private key used to encrypt the page on the server still match, so the server encrypts the web page content with its own private key, and the client browser can still use this certificate to decrypt and display the web page content normally, so when the user clicks "continue browsing this website (not recommended)" The web page can be opened.

Self-signed CA certificate generation

1. Use Openssl to randomly generate the server key and the certificate application file CSR

two。 Issue your own certificate to yourself

Enter the following command method certificate on the server command line.

# opensslx509-req-days 3650-in moonfly.net.csr-signkeymoonfly.net.key-outmoonfly.net.crt

-the period of validity of the days 3650 certificate. Issue your own certificate. You can have it as long as you want. I have done it for 10 years at once.

-inmoonfly.net.csr specifies the CSR file

-signkeymoonfly.net.key specifies the private key key file of the server

-outmoonfly.net.crt sets the generated certificate file name

A command, their own stamped ID card moonfly.net.crt was born!

Note: strictly speaking, what is generated here is only a RootCA, not a server certificate ServerCA in a strict sense, the real ServerCA is a certificate that needs to be signed to the server by using this RootCA; but here we only talk about how to achieve SSL encryption of the web page, so we directly use RootCA, which can normally achieve encryption functions.

Nginx enables HTTPS

After the configuration file is modified, test the configuration with nginx-t, and then reload the nginx service to see if port 443 is listening:

After configuration, https is already working, and now you can access the website through https

After reading the above, do you have any further understanding of how to configure HTTPS encrypted reverse proxy access using self-signed CA? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.