NGINX configures SSL two-way authentication
- 高洛峰Original
- 2016-11-17 13:21:581875browse
Background
For NGINX’s HTTPS configuration, usually we only need to implement server-side authentication, because the browser has built-in some trusted certificate authorities (CA), and the server-side only needs to obtain the certificates issued by these organizations and Once configured, the browser will verify the validity of the certificate itself and encrypt communications via SSL.
But in special cases we also need to verify the client. Only trusted clients can use the service interface. At this time we need to enable two-way authentication to achieve this purpose. Only when the client requests an available certificate can Adjust the server interface.
CA and self-signed
CA can only be done by authoritative organizations, and if the organization fails to meet security standards, it will be "blocked" by browser manufacturers. Not long ago, WoSign and StartSSL were blocked by Mozilla and Chrome. However, this does not affect our two-way authentication configuration, because we build our own CA...
For convenience, we make certificate-related production in the NGINX directory:
cd /etc/nginx mkdir sslcd ssl
Make CA private key
openssl genrsa -out ca.key 2048
Make CA root Certificate (Public Key)
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Note:
Common Name can be filled in at will
Other information that needs to be filled in. In order to avoid errors, fill it in. Let’s
Server-side certificate
Make server-side private key
openssl genrsa -out server.pem 1024 openssl rsa -in server.pem -out server.key
Generate and issue Request
openssl req -new -key server.pem -out server.csr
Note:
Common Name must be filled in as the domain name when accessing the service. Here we use usb.dev. The following NGINX configuration will use
Other information that needs to be filled in. In order to avoid errors, fill in . CA root certificate matching)
Issued with CA
openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out server.crt
Client certificate
Similar to the server certificate:
Note:
Common Name can be filled in at will
Other information that needs to be filled in. In order to avoid errors, fill in . (in order to match the CA root certificate)
Now you have all the required certificates Okay, we can start configuring NGINX.
NGINX
server {
listen 443 ssl;
server_name usb.dev;
access_log off;
ssl on;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_verify_client on;
location / {
proxy_pass http://backend$request_uri;
}
}where ssl_client_certificate /etc/nginx/ssl/ca.crt; means to use the CA certificate to verify whether the client certificate in the request is issued by the CA.
After configuring, reload NGINX:
service nginx reload
Okay, now we can start verification.
Request verification
The verification process can be done on other machines or on this machine. In order to be able to parse usb.dev, you also need to configure /etc/hosts:
127.0.0.1 usb.dev
If you use a browser to verify, you need to export the client certificate to p12 format, skip here. Our focus is on verification through curl:
curl --insecure --key client.key --cert client.crt 'https://usb.dev'
where --insecure is to ignore the non-authoritative nature of the self-built CA. If your verification is normal, you are in luck, because there is a deep pit here: some versions of curl will report errors:
<html> <head><title>400 No required SSL certificate was sent</title></head> <body bgcolor="white"> <center><h1>400 Bad Request</h1></center> <center>No required SSL certificate was sent</center> <hr><center>nginx/1.11.0</center> </body> </html>
These error-reporting versions of curl actually have to strictly require that the path of the --cert actual parameter must be completely correct, such as the current You need to use --cert ./client.crt under the directory. It is wrong to use --cert client.crt. During the pit climbing process, the -v parameter was enabled to observe the complete process, and an alarm was found:
warning: certificate file name "client.crt" handled as nickname; please use "./client.crt" to force file name