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 id="nbsp-Bad-nbsp-Request">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
Hot AI Tools
Undresser.AI Undress
AI-powered app for creating realistic nude photos
AI Clothes Remover
Online AI tool for removing clothes from photos.
Undress AI Tool
Undress images for free
Clothoff.io
AI clothes remover
AI Hentai Generator
Generate AI Hentai for free.
Hot Article
Hot Tools
SAP NetWeaver Server Adapter for Eclipse
Integrate Eclipse with SAP NetWeaver application server.
Zend Studio 13.0.1
Powerful PHP integrated development environment
SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.
Dreamweaver CS6
Visual web development tools
MantisBT
Mantis is an easy-to-deploy web-based defect tracking tool designed to aid in product defect tracking. It requires PHP, MySQL and a web server. Check out our demo and hosting services.
