Original Address http://www.liaoxuefeng.com/article/0014189023237367e8d42829de24b6eaf893ca47df4fb5e000
HTTPS is almost the only option for securing a secure connection to your Web browser to the server. HTTPS is actually HTTP over SSL, which means that the HTTP connection is built on SSL secure connections.
SSL uses certificates to create secure connections. There are two modes of authentication:
The client only authenticates the server's certificate, and the client does not provide the certificate itself;
Both the client and the server authenticate each other's certificates.
Obviously the second way is more secure, which is usually done by online banking, but ordinary Web sites can only take the first approach.
How the client verifies the server's certificate. The server's own certificate must be signed by an "authoritative" certificate, and this "authoritative" certificate may be signed by a more authoritative certificate, which goes back to the first level, and the most authoritative certificate on the top level is called the root certificate. The root certificate is built directly into the browser so that the browser can use its own root certificate to verify that a server's certificate is valid.
If you want to provide a valid certificate, the server's certificate must be signed from a certification authority such as VeriSign so that the browser can verify the pass, otherwise the browser gives a warning that the certificate is invalid.
The fee for signing a certificate is dozens of ~ hundreds of a year, so if it is for administrative purposes only, you can create a self-signed certificate to ensure that the administrator is securely connected to the server through the browser.
The following is a brief description of how to create a self-signed SSL certificate.
To create a self-signed certificate, you need to install OpenSSL, using the following steps:
Create key;
Create a signature request;
Remove the key password;
Sign the certificate with key.
Certificates that are prepared for HTTPS need to be aware that the CN of the signature request created must be exactly the same as the domain name, otherwise it cannot be authenticated through the browser.
The above steps are cumbersome, so I made a shell script that can be done at once. Download the script from here:
https://github.com/michaelliao/itranswarp.js/blob/master/conf/ssl/gencert.sh
Run the script, assuming that your domain name is www.test.com, then follow the prompts to enter:
$./gencert.sh
Enter your domain [www.example.com]: www.test.com
Create server key ...
Generating RSA private key, 1024 bit long modulus ... ...
++++++ ...
++++++
e is 65537 (0x10001) [* * * * * * C6/>enter Pass phrase for Www.test.com.key: Enter password
verifying-enter pass phrase for Www.test.com.key: Enter password
Create SE RVer Certificate Signing request ...
Enter pass phrase for Www.test.com.key: Enter password
Remove password
... Enter pass phrase for Www.test.com.origin.key: Enter password
writing RSA key
Sign SSL certificate ...
Signature OK
subject=/c=us/st=mars/l=itranswarp/o=itranswarp/ou=itranswarp/cn=www.test.com
Getting Private key
TODO:
copy www.test.com.crt to/etc/nginx/ssl/www.test.com.crt
copy Www.test.com.key to/ Etc/nginx/ssl/www.test.com.key
ADD configuration in Nginx:
server {
...
SSL on;
Ssl_certificate /etc/nginx/ssl/www.test.com.crt;
Ssl_certificate_key/etc/nginx/ssl/www.test.com.key;
}
The red part is input, note that the password entered 4 times is the same.
4 files are created in the current directory: WWW.TEST.COM.CRT: Self-signed certificate WWW.TEST.COM.CSR: Certificate request Www.test.com.key: Key with no password Www.test.com.origin.key: Key with password
The Web server needs to send WWW.TEST.COM.CRT to the browser for verification, and then use Www.test.com.key to decrypt the data sent by the browser, leaving two files that need not be uploaded to the Web server.
Take Nginx as an example, in the server {...} Configured in:
server {
...
SSL on;
Ssl_certificate /etc/nginx/ssl/www.test.com.crt;
Ssl_certificate_key/etc/nginx/ssl/www.test.com.key;
}
If all goes well, open your browser and you can access the Web site via HTTPS. A warning appears on the first visit (because our self-signed certificate is not trusted by the browser), the certificate is imported into the system through the browser (Windows uses IE import, the Mac uses Safari import) and is set to "trusted", which allows the computer to securely connect to the Web server when it accesses the Web site:
How to configure the certificate in the application server. such as Tomcat,gunicorn and so on. The correct approach is not to configure, let Nginx process HTTPS, and then through proxy HTTP connection to the backend of the application server, the equivalent of using Nginx as HTTPS to HTTP security agent, which is to take advantage of the Nginx Http/https processing power, It also avoids the disadvantage that the application server is not good at HTTPS. feel the content of the site is good, after reading has harvested.