Nun, die erste Sache zu prüfen ist, ob Tomcat korrekt konfiguriert ist, um ein Zertifikat vom Client für den fraglichen Pfad anzufordern. Für Tomcat 6 bedeutet dies, dass Sie einen Connector in conf/server konfiguriert haben sollten .xml etwas wie folgt aus:
<Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="${user.home}/.keystore" keystorePass="password"
truststoreFile="conf/truststore" truststorePass="password"
clientAuth="true" sslProtocol="TLS" />
Die truststoreFile & truststorePass wichtig sind - wenn man nur hinzufügen „ClientAuth = true“ ohne diese beiden Parameter einschließlich, finden Sie alle Arten von seltsamen Verhalten sehen (und keine Warnung, dass Sie hat etwas falsch gemacht.) Das truststoreFile muss auf eine legitime JKS-Datei zeigen, die die CAs auflistet, denen Sie vertrauen, dass sie die Client-Zertifikate signieren. Wenn Tomcat korrekt konfiguriert ist, sollte der Browser Öffnen Sie den Dialog wie folgt: "Die Website benötigt ein Client-Zertifikat" sowie eine Liste aller Zertifikate, die in den Browser importiert wurden. Wenn Sie dies nicht sehen, ist etwas mit Ihrem Tomcat-Setup nicht in Ordnung.
Es klingt, als ob Sie das richtig eingerichtet haben, aber es lohnt sich, es nochmals zu überprüfen. Wenn Sie es ordnungsgemäß eingerichtet haben, sehen Sie außerdem eine Handshake-Nachricht "Zertifikatsanforderung", wenn Sie die Verbindung in Wireshark nachverfolgen, die die vertrauenswürdigen CAs nach Distinguished Name auflistet. Wenn Sie dies nicht sehen, überprüfen Sie Ihr Tomcat-Setup und vor allem den Truststore.
Die nächste Sache wäre, die PKCS12-Datei selbst zu überprüfen. Sie können dies tun mit:
openssl pkcs12 -in [path-to-pkcs12-file] -nokeys | openssl x509 -noout -subject -issuer
sicherstellen, dass der Distinguished Name eines der Emittent der trustedCaCert Einträge in Ihrem Vertrauensspeicher passt. Dies ist eine Art von Ärger mit dem Java keytool zu tun, aber Sie können verdoppeln Prüfung mit:
keytool -exportcert -keystore conf/truststore -alias [alias of trusted cert] | openssl x509 -noout -subject -inform der
Wenn all dies überprüft, aber es funktioniert immer noch nicht, es lohnt sich OpenSSL s_client verwenden, da Sie zu beheben, Normalerweise erhalten Sie viel mehr Informationen zur Fehlerbehebung. Um dies zu tun, werden Sie den Schlüssel aus dem Zertifikat in der PKCS12-Datei trennen müssen:
openssl pkcs12 -in [PKCS12 file] -out [whatever].key
openssl s_client -tls1 -connect localhost:443 -cert [whatever].key -key [whatever].key
(Sie können die gleiche Datei für das „-cert“ verwenden und „-Taste“ Argument, weil openssl smart genug nach den Trennzeichen "BEGIN CERTIFICATE" und "BEGIN RSA PRIVATE KEY" in den Quelldateien suchen. Ich hatte ein frustrierendes Problem mit Client-Zertifikaten, das ich nicht einmal herausfinden konnte, bis ich s_client verwendete und eine Erinnerung erhielt, dass mein Client-Zertifikat abgelaufen war (das nicht protokolliert oder irgendwo anders ausgegeben wurde).
Auch möchten Sie vielleicht in Erwägung ziehen, Ihre Konfiguration Verschiebung Apache Tomcat über die Verwendung - Apache ist ein viel flexibler und gibt Ihnen eine viel mehr Feedback, wenn es um SSL confifguration kommt als Tomcat ist.
Sie haben Ihren Server bereits für die Client-Authentifizierung eingerichtet, Sie sagen: Welche Art von Keystore hatten Sie für Ihren Connector? – Cratylus
Jks, ich glaube nicht, dass es das Problem gibt, weil es mit meinem eigenen generierten Schlüssel funktioniert, und arbeitet mit openssl s_client mit pfx Schlüssel. Funktioniert nur nicht mit pfx mit firefox, dh (mit Schlüssel im Windows-Store) oder Java-App zeigt auf p12 Keystore – Deo
Die Art, wie Sie es beschreiben, ist die pfx leer oder beschädigt. Haben Sie versucht, seinen Inhalt zu sehen? – Cratylus