NGINX konfiguriert die bidirektionale SSL-Authentifizierung

Hintergrund

Für die HTTPS-Konfiguration von NGINX müssen wir normalerweise nur die serverseitige Authentifizierung implementieren, da der Browser über einige vertrauenswürdige Zertifizierungsstellen (CA) integriert ist und die serverseitige Authentifizierung nur erforderlich ist zu erhalten Nachdem die von diesen Organisationen ausgestellten Zertifikate konfiguriert wurden, überprüft der Browser die Gültigkeit des Zertifikats selbst und verschlüsselt die Kommunikation über SSL.

Aber in besonderen Fällen müssen wir auch den Client überprüfen. Nur vertrauenswürdige Clients können die Serviceschnittstelle verwenden. Zu diesem Zeitpunkt müssen wir die Zwei-Wege-Authentifizierung aktivieren. Nur wenn der Client dies anfordert Zertifikate können zur Anpassung der Serverschnittstelle verwendet werden.

CA und selbstsigniert

CA kann nur von maßgeblichen Organisationen durchgeführt werden, und wenn die Organisation die Sicherheitsstandards nicht erfüllt, wird sie vor nicht allzu langer Zeit vom Browserhersteller „verboten“. , WoSign und StartSSL Es wurde von Mozilla und Chrome blockiert. Dies hat jedoch keinen Einfluss auf unsere bidirektionale Authentifizierungskonfiguration, da wir unsere eigene Zertifizierungsstelle erstellen.

Der Einfachheit halber führen wir die zertifikatbezogene Produktion im NGINX-Verzeichnis durch:

cd /etc/nginx
mkdir sslcd ssl

Erstellen Sie einen privaten CA-Schlüssel

openssl genrsa -out ca.key 2048

Erstellen Sie ein CA-Stammzertifikat (öffentlicher Schlüssel)

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

Hinweis:

Der allgemeine Name kann beliebig ausgefüllt werden

Sonstiges Um Fehler zu vermeiden, geben Sie alle Informationen ein, die ausgefüllt werden müssen.

Serverseitiges Zertifikat

Serverseitigen privaten Schlüssel erstellen

openssl genrsa -out server.pem 1024
openssl rsa -in server.pem -out server.key

Signaturanforderung generieren

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

Hinweis:

Beim Zugriff auf den Dienst muss der allgemeine Name als Domänenname eingegeben werden wird verwendet

Andere Informationen, die ausgefüllt werden müssen, um Fehler zu vermeiden, füllen Sie beide aus (Um mit dem CA-Stammzertifikat übereinzustimmen)

Ausgestellt von CA

openssl x509 - req -sha256 -in server.csr -CA ca.crt -CAkey ca.key - CAcreateserial -days 3650 -out server.crt

Client-Zertifikat

ähnelt dem Server Zertifikat:

Hinweis:

Gebräuchlicher Name ist in Ordnung

Weitere Informationen, die ausgefüllt werden müssen. Um Fehler zu vermeiden, füllen Sie um mit dem CA-Stammzertifikat übereinzustimmen)

Da nun die erforderlichen Zertifikate vorhanden sind, können wir mit der Konfiguration von NGINX beginnen.

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

wobei ssl_client_certificate /etc/nginx/ssl/ca.crt bedeutet, das CA-Zertifikat zu verwenden, um zu überprüfen, ob das Client-Zertifikat in der Anfrage von der CA ausgestellt wurde.

Nach der Konfiguration NGINX neu laden:

service nginx reload

Okay, jetzt können wir mit der Überprüfung beginnen.

Verifizierung anfordern

Der Verifizierungsprozess kann auf anderen Maschinen oder auf dieser Maschine durchgeführt werden. Um usb.dev analysieren zu können, müssen Sie auch /etc/hosts konfigurieren:

127.0.0.1 usb.dev

Wenn Sie die Browserüberprüfung verwenden, müssen Sie das Client-Zertifikat in das p12-Format exportieren, was hier übersprungen wird. Unser Fokus liegt auf der Verifizierung durch Curl:

curl --insecure --key client.key --cert client.crt 'https://usb.dev'

wobei --insecure die nicht autorisierende Natur der selbst erstellten Zertifizierungsstelle ignorieren soll. Wenn Ihre Überprüfung normal ist, haben Sie Glück, denn hier gibt es eine tiefe Grube: Einige Versionen von Curl melden Fehler:

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

Diese Versionen von Curl, die Fehler melden, stellen tatsächlich strenge Anforderungen an den Pfad Der tatsächliche Parameter --cert muss vollständig korrekt sein. Sie müssen beispielsweise --cert./client.crt im aktuellen Verzeichnis verwenden. Während des Grubenklettervorgangs wurde der Parameter -v aktiviert, um den gesamten Vorgang zu beobachten, und es wurde ein Alarm gefunden:

warning: certificate file name "client.crt" handled as nickname; please use "./client.crt" to force file name