Konfigurieren der Clientzertifikatauthentifizierung in Apache

Ich versuche, einen Teil eines VirtualhostIn-Apache so einzurichten, dass eine Clientauthentifizierung erforderlich ist. Der VirtualHostbetreffende Server fungiert auch als Reverse-Proxy für den eigentlichen Webserver. Folgendes habe ich getan:

• Erstellt ca.crt, ca.csrund ca.keyauf dem Server ich als CA. bin mit
• Die Konfiguration des wurde so geändert VirtualHost, dass sie folgendermaßen aussieht:

...

ProxyPass / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverseCookiePath / /

SSLEngine On
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
SSLCertificateChainFile "/private/etc/apache2/ca_bundle.crt"
SSLCACertificateFile "/private/etc/apache2/self_ca.crt"
SSLVerifyClient none
SSLOptions StrictRequire   
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /clientauth>
    # These options force the client to authenticate with a client certificate.
    SSLVerifyClient require
    SSLVerifyDepth 1
</Location>

• Erstellt ein Testclient-Zertifikat mit meiner benutzerdefinierten Zertifizierungsstelle.
• Installierte das Client-Zertifikat im Login-Schlüsselbund unter Mac OS X Lion und manuell in Firefox.

Aber ich kann nicht zum /clientauthPfad navigieren .

• Laut Firefox konnte der SSL-Peer keinen akzeptablen Satz von Sicherheitsparametern aushandeln.
• Opera sagt "Sichere Verbindung: Schwerwiegender Fehler (40) vom Server."
• Chrome und Safari sagen "HTTP 403 Forbidden".
• cURL (mit der .p12-Datei) kann den Schlüssel aus irgendeinem Grund nicht finden ...
• cURL (unter Verwendung der Dateien .crt und .key) führt den Handshake durch, sendet die Anforderung und sagt dann "Leere Antwort vom Server".
• Die Apache-Fehlerprotokolle wiederholen die Zeile immer wieder Re-negotiation handshake failed: Not accepted by client!?

Ist dies ein Konflikt zwischen der Verwendung der Clientauthentifizierung und der Verwendung eines Reverse-Proxys? Oder habe ich etwas anderes falsch gemacht?

Das zugrunde liegende Problem ist hier die Ablehnung der Neuverhandlung. Dies ist auf die Aktivitäten in den letzten ein oder zwei Jahren zur Behebung einer TLS-Sicherheitsanfälligkeit zurückzuführen, und es gab verschiedene vorläufige Korrekturen, bei denen die Neuverhandlung verweigert wurde, bis eine neue TLS-Erweiterung implementiert wurde. Sie müssen also sicherstellen, dass Ihr SSL (OpenSSL) und möglicherweise auch Ihr Apache-HTTPD so aktuell wie möglich sind.

Der HTTP-Client sendet die HTTP-Anforderung erst, nachdem die SSL-Sitzung ausgehandelt wurde. Dies bedeutet, dass der Server die vom Client angeforderte URL erst kennt, wenn SSL eingerichtet wurde. Da Sie den Wert von SSLVerifyClientbasierend auf der URL ändern , kann Apache das Clientzertifikat nicht anfordern, wenn die SSL-Sitzung zum ersten Mal ausgehandelt wird, und muss stattdessen eine Neuverhandlung der Sitzung erzwingen, sobald die URL bekannt ist. Es scheint, dass das Problem in dieser Neuverhandlung liegt, und deshalb schlage ich vor, dass Sie es ohne dies testen, indem Sie es SSLVerifyClient requirein den VirtualHostBlock setzen und aus dem LocationBlock entfernen .