NGINX configures SSL two-way authentication-PHP开发-php.cn

NGINX configures SSL two-way authentication

高洛峰

Release： 2016-11-17 13:21:58

Original

1892 people have browsed it

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

Copy after login

Make CA private key

openssl genrsa -out ca.key 2048

Copy after login

Make CA root Certificate (Public Key)

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Copy after login

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

Copy after login

Generate and issue Request

openssl req -new -key server.pem -out server.csr

Copy after login

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;
    }
}

Copy after login

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

Copy after login

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

Copy after login

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 &#39;https://usb.dev&#39;

Copy after login

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>

Copy after login

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

Copy after login