Nginx configuration HTTPS encryption reverse proxy access – self-signed CA

for internal company access considerations, the use of the CA is a native OpenSSL self-signed generated by the Internet can not be authenticated by the root CA, so the Web site is not trusted or the security certificate is not valid prompt, skip directly, directly access! HTTPS principles and Access procedures: Server Prerequisites:

A server private key key file

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

Access process:

1, the client browser accesses the server's 443 port through the HTTPS protocol, and obtains the server's certificate (public key); The client browser is looking for some Internet trusted ROOTCA (authoritative certification authority) to verify that the currently acquired certificate is valid, PS: These rootca are installed in the system with the operating system preset;

2, if the ROOTCA authentication is passed, indicates that the certificate is trustworthy, and if the server name labeled in the certificate is the same as the server URL address of the current access, it will directly use the public key contained in the certificate to decrypt the server through its own key (private key) encrypted transmission over the Web page content, Thus the content of the page is displayed normally;

3, if the ROOTCA verification does not pass, stating that the certificate is not a legitimate ROOTCA signature and authorization, so there is no way to prove the authority of the server currently being accessed, the client browser will display a warning that the user is currently accessing the server identity can not be verified, Ask the user if you want to continue browsing! (This is usually the case with self-signed CA certificates)

It is important to note that verifying the validity of a CA only proves that the identity of the current server is valid, has credibility, and is unique, preventing others from impersonating the site, but does not affect the encryption of the Web page, although the CA certificate cannot be certified as authoritative. However, it contains the public key and the server used to encrypt the page's private key is still a matching pair, so the server with its own private key encryption of the Web page content, the client browser can still use this certificate to decrypt, normal display page content, so when the user click "continue to visit this website (not recommended)", The Web page can be opened;

Self-signed CA certificate generation

1, randomly generate server key with OpenSSL, and certificate request file CSR

2, self-issued certificates for themselves

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

-days 3650 Certificate of validity period, oneself to issue a certificate, want to have how long period of validity, how long, I get a 10 years of validity;

-INMOONFLY.NET.CSR Specifying a CSR file

-signkey Moonfly.net.key Specify the server's private key file

-OUTMOONFLY.NET.CRT set the generated certificate file name

An order, oneself to self-stamped identity card Moonfly.net.crt was born!

Note: In fact, strictly speaking, here is only a rootca, not the strict meaning of the server certificate Serverca, the real serverca is the need to use this ROOTCA to the server signing method out of the certificate to calculate; But here we only talk about how to implement the SSL encryption of the Web page, So the direct use of ROOTCA, but also the normal implementation of encryption function!

Nginx configuration Enable HTTPS and configure the crypto reverse proxy

After the configuration file modified, with NGINX-T test configuration is correct, reload the Nginx service, check whether the 443 port is listening:

Configuration is complete, HTTPS is already working, you can now access the site through HTTPS

Nginx configuration HTTPS encryption reverse proxy access – self-signed CA