Configure HTTPS encrypted reverse proxy access in NGINX-Self-Signed CA

Configure HTTPS encrypted reverse proxy access in NGINX-Self-Signed CA

For internal access considerations of the company, the CA used is generated by self-Signed Openssl on the local machine. Therefore, it cannot be verified by the Internet industry Root CA. Therefore, the website is not trusted or the security certificate is invalid, skip this step and access it directly!

HTTPS principle and access process: Necessary Conditions for the server:

A server Private KEY File

A ca certificate that matches the server domain name (Public key, generated based on the private key)

Access process:

1. The client browser accesses port 443 of the server through the https protocol and obtains the server certificate (Public Key). The client browser will go to some trusted Internet RootCA (authoritative Certificate Authority) at this time) verify whether the obtained certificate is valid and valid. PS: These rootcas are pre-installed in the system along with the operating system;

2. If the RootCA authentication succeeds, the certificate is trusted. If the server name indicated in the certificate is the same as the URL of the currently accessed server, the public KEY in the certificate is used to decrypt the webpage content transmitted by the server after its own KEY (Private KEY) is encrypted, so that the page content is displayed normally;

3. If the RootCA verification fails, it indicates that the certificate has not obtained the valid RootCA signature and authorization. Therefore, it cannot prove the authority of the currently accessed server, at this time, the client browser will display a warning prompting you that the identity of the server currently accessed by the user cannot be verified and asking you if you want to continue browsing! (This is usually the case for self-Signed CA certificates)

 

It should be noted that verifying the validity of the CA only proves whether the identity of the current server is valid, credibility, and identity uniqueness, so as to prevent others from counterfeiting the website; however, the encryption function of the web page is not affected. Although the CA certificate cannot be proved by authority, its public key and the private key used to encrypt the page on the server are still matched, therefore, when the server uses its own private key to encrypt the webpage content, the client browser can still use this certificate for decryption and the webpage content is displayed normally, therefore, when you click "continue to browse this website (not recommended)", the webpage can be opened;

Self-Signed CA certificate generation

1. Use Openssl to randomly generate server keys and CSR certificates.

 

2. issue a certificate for yourself

# Opensslx509-req-days 3650-in moonfly.net. csr-signkey moonfly.net. key-outmoonfly.net. crt

-Days 3650 indicates the validity period of the Certificate. You can issue a certificate to yourself. If you want to renew the validity period, you can renew the validity period for 10 years;

-Inmoonfly.net. csr specifies the CSR File

-Signkey moonfly.net. key: Specifies the private key file of the server.

-Outmoonfly.net. crt: Set the generated Certificate file name

With a command, moonfly.net. crt, a steel-printed ID card, 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 the certificate that needs to be signed by the server using this RootCA; however, here we will only talk about how to implement SSL encryption for webpages, so we can directly use RootCA, which can also implement the encryption function normally!

Enable HTTPS in NGINX configuration and configure encrypted reverse proxy

After the configuration file is modified, use nginx-t to test whether the configuration is correct. Load the nginx service and check whether port 443 is listening:

After the configuration is complete, https is working. Now you can access the website through https.