NGinx SSL-Zertifikat-Authentifizierung, signiert von Zwischen-CA (Kette)

Ich versuche, aktivieren Sie die client-Zertifikat-Authentifizierung in nginx, wo die Zertifikate signiert wurden, die von einer Zwischenzertifizierungsstelle. Ich bin in der Lage, dies funktioniert gut, wenn mit einem Zertifikat durch ein selbstsigniertes root-CA; dies gilt jedoch nicht, wenn das signierende CA intermediate CA.

Meine einfache server-Abschnitt sieht wie folgt aus:

server {
    listen       443;
    server_name  _;

    ssl                  on;
    ssl_certificate      cert.pem;
    ssl_certificate_key  cert.key;

    ssl_session_timeout  5m;

    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   on;

    ssl_client_certificate ca.pem;
    ssl_verify_client on;
    ssl_verify_depth 1;

    location /{
        root   html;
        index  index.html index.htm;
    }
}

Für den Inhalt der ca.pem, ich habe versucht mit nur das intermediate-CA und auch die Verkettung der intermediate-CA-Zertifikat und das root-CA-cert, d.h. so etwas wie:

cp intermediate.crt ca.pem
cat root.crt >> ca.pem

Habe ich auch überprüft, ob das Zertifikat gültig von openssl ist die Perspektive, wenn mit dem gleichen CA-Kette:

openssl verify -CAfile /etc/nginx/ca.pem certs/client.crt 
certs/client.crt: OK

Habe ich experimentierte mit der Einstellung ssl_verify_depth explizit auf 1 (wie oben) und dann ist auch 0 (nicht sicher, was diese Zahl genau bedeutet), aber bekomme immer noch denselben Fehler.

Den Fehler bekomme ich in allen Varianten von intermed CA "400 Bad Request" und insbesondere "Das SSL-Zertifikat-Fehler" (nicht sicher, was das genau bedeutet).

Vielleicht nginx nur nicht unterstützt cert-Ketten für die zwischen-certs? Jede Hilfe sehr dankbar!

InformationsquelleAutor der Frage Hans L | 2011-12-08

  1. 41

    Edit: ich hatte auch dieses "problem", Lösung und Erklärung unten im text.

    Schien es wie nginx nicht unterstützt intermediate-Zertifikate. Meine Zertifikate selbst erstellt: (RootCA ist eigensignierter, IntrermediateCA1 ist signiert von RootCA, etc.)

    RootCA -> IntermediateCA1 -> Client1 
RootCA -> IntermediateCA2 -> Client2

    Möchte ich in nginx "IntermediateCA1", um Zugang zu site nur für Besitzer der "Client1" - Zertifikat.

    Wenn ich auf "ssl_client_certificate" Datei mit IntermediateCA1 und RootCAund setzen Sie "ssl_verify_depth 2" (oder mehr) clients können sich anmelden, Website mit Zertifikat Client1 und Client2 (sollte nur Client1).
    Das gleiche Ergebnis ist, wenn ich auf "ssl_client_certificate" Datei mit nur RootCA - clients einloggen können.

    Wenn ich auf "ssl_client_certificate" Datei mit nur IntermediateCA1und setzen Sie "ssl_verify_depth 1" (oder "2" oder mehr - egal) , es ist imposible, um sich anzumelden, bekomme ich den Fehler 400. Und im debug-Modus sehe ich Protokolle:

    verify:0, error:20, depth:1, subject:"/C=PL/CN=IntermediateCA1/[email protected]",issuer: "/C=PL/CN=RootCA/[email protected]"
verify:0, error:27, depth:1, subject:"/C=PL/CN=IntermediateCA1/[email protected]",issuer: "/C=PL/CN=RootCA/[email protected]"
verify:1, error:27, depth:0, subject:"/C=PL/CN=Client1/[email protected]",issuer: "/C=PL/CN=IntermediateCA1/[email protected]"
(..)
client SSL certificate verify error: (27:certificate not trusted) while reading client request headers, (..)

    Ich glaube, das ist ein bug. Getestet auf Ubuntu, nginx 1.1.19 und 1.2.7-1~dotdeb.1, openssl 1.0.1.
    Ich sehe, dass nginx 1.3 hat einige Optionen mehr über die Verwendung von client-Zertifikaten, aber ich'dont siehe Lösung zu diesem problem.

    Derzeit nur eine Möglichkeit zum trennen von clients 1 und 2 ist zwei, eigensignierter RootCAs, dies ist aber nur ein workaround..

    Edit 1:
    Gemeldet ich hab dieses Problem hier: http://trac.nginx.org/nginx/ticket/301

    Edit 2"
    *Ok, es ist kein bug, es ist feature 😉*

    Bekomme ich Antwort hier: http://trac.nginx.org/nginx/ticket/301
    Es funktioniertmüssen Sie nur überprüfen, was Ihre ssl_client_i_dn ist (. Anstelle der Emittenten, die Sie verwenden können, die ebenfalls Gegenstand der Bescheinigung ist, oder was Sie wollen von http://wiki.nginx.org/HttpSslModule#Built-in_variables

    Dies ist, wie die Zertifikat-Verifizierung funktioniert: Zertifikat müssen
    überprüft bis zu einer vertrauenswürdigen Stammzertifizierungsstelle. Wenn die Kette nicht gebaut werden, um eine Vertrauenswürdige
    root (nicht befriedigend) - überprüfung fehlschlägt. Wenn Sie die trust-root - alle
    signierte Zertifikate, indem es direkt oder indirekt, wird
    erfolgreich überprüft.

    Begrenzung der überprüfung der Tiefe kann verwendet werden, wenn Sie
    wollen begrenzen client-Zertifikate zu einem direkt ausgestellt Zertifikate
    nur, aber es ist mehr über die DoS-Prävention, und natürlich kann es nicht sein
    zur Begrenzung verificate zu intermediate1 nur (aber nicht
    intermediate2).

    Was Sie wollen, hier einige Genehmigung Schicht auf der Grundlage
    auf die überprüfung Ergebnis - d.h. Sie können prüfen wollen, dass Kunden
    Zertifikat Emittent intermediate1. Einfachste Lösung wäre,
    Aufträge ablehnen, wenn Emittenten DN entspricht nicht einem erlaubt, z.B.
    so etwas wie dieses (vollkommen ungetestet):

    [ Edit von mir, es funktioniert in meiner Konfiguration ]

    server {
    listen 443 ssl;

    ssl_certificate ...
    ssl_certificate_key ...

    ssl_client_certificate /path/to/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    if ($ssl_client_i_dn != "/C=PL/CN=IntermediateCA1/[email protected]") {
        return 403;
    }
}

    InformationsquelleAutor der Antwort Jack

  2. 11

    Haben Sie versucht, die Erhöhung ssl_verify_depth Richtlinie? Docs sagen:

    (it) sets a verification depth in the client certificates chain.

    Aber Ihr überprüfen, Tiefe 1 ist. Sie sagen:

    Habe ich experimentierte mit der Einstellung ssl_verify_depth explizit auf 1 (wie oben) und dann ist auch 0 (nicht sicher, was diese Zahl genau bedeutet), aber bekomme immer noch denselben Fehler.

    Also, versuchen Sie, 2 oder 3..

    PS:
    Überall, wo ich finden, die dieses problem erwähnt, seine erzählte kombinieren intermediate-CA-Zertifikate mit der Sie server-cert. in einer Datei (als @vikas-nalwar vorgeschlagen und Sie haben) in der Reihenfolge der überprüfung (aber ich bin mir nicht sicher, ob die Reihenfolge spielt eine Rolle) und-grob gesprochen-set ssl_verify_depth Anzahl von certs im bundle.

    InformationsquelleAutor der Antwort Andrew D.

  3. 2

    Ich glaube, dass Sie möchten, aktivieren Sie die client-Validierung auf Ihrem server-Seite. Wenn dies so ist, ich sehe nicht, dass Sie Ihr client-Zertifikat in der Kette. Versuchen Sie, die folgenden in der gleichen Reihenfolge. Verwenden Sie die certchain.pem. 

      cat client.crt > certchain.pem
  cat intermediate.crt >> certchain.pem
  cat root.crt >> certchain.pem

    InformationsquelleAutor der Antwort Drona

  4. 2

    als ich war strugling mit nginx und cloudflare,

    diese Zeilen hat den trick für mich:

    ssl_client_certificate    /etc/nginx/ssl/ca-bundle-client.crt;  
ssl_verify_client optional_no_ca;  
ssl_verify_depth 2;

    in der zweiten Zeile mit optional_no_ca ist der wichtige Teil

    InformationsquelleAutor der Antwort Tal

  5. 0

    Ich muss sagen, es funktioniert gut für mich mit nginx/1.13.2d.h.

    • Ich habe einen root-CA signiert hat zwei intermediate-CAs
    • beide Zwischenprodukte jede unterzeichnete einen client

    • Ich concat die certs wie
      cat client-intermediate1.crt ca-client.crt > ca.chained1.crt und
      cat client-intermediate2.crt ca-client.crt > ca.chained2.crt und
      cat ca.chained1.crt ca.chained2.crt > ca.multiple.intermediate.crt

    • wenn ich nur ca.chained1.crt als ssl_client_certificate dann nur client1.crt anschließen kann, ebenfalls für ca.chained2.crt/client2.crt

    • wenn ich ca.multiple.intermediate.crt dann beide clients verbinden können,

    für den Widerruf ein Zwischenprodukt, entfernen Sie einfach die cert-Kette von ca.mehrere.Mittelstufe.crt

    hier ist der entsprechende config. auch hat eine hohe Sicherheitseinstellungen

    # minimum settings for ssl client auth 
ssl_client_certificate /etc/ssl/ca.multiple.intermediate.crt;
ssl_verify_client on;
ssl_verify_depth 2;

# ssl high security settings (as of writing this post)
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

    wenn Sie möchten, analysieren die certs CN und übergeben backend, dann fügen Sie diese AUßERHALB der server {.. block

    # parse out CN
map $ssl_client_s_dn $ssl_client_s_dn_cn {
    default "should_not_happen";
    ~CN=(?<CN>[^,]+) $CN;
}

    und in den block, können Sie es verwenden, dann

    # add headers for backend containing SSL DN/CN
add_header X-SSL-client-s-dn $ssl_client_s_dn;
add_header X-SSL-client-s-dn_cn $ssl_client_s_dn_cn;

    InformationsquelleAutor der Antwort pHiL

  6. -1

    weitere einfache Möglichkeit ist die Verkettung von Zertifikaten (inklusive domain certifate) in einer einzigen Datei und verwenden, die auf Ihrem Server und nginx conf-Datei

    Katze http://www.example.com.crt bundle.crt - > http://www.example.com.chained.crt

    Immer daran denken, Sie mit dem server-Zertifikat den ersten und dann nur CA-server-Zertifikate

    Können Sie mehr Lesen über am http://nginx.org/en/docs/http/configuring_https_servers.html#chains

    InformationsquelleAutor der Antwort Naveen

Schreibe einen Kommentar