Wie wird https: // localhost: port ein selbstsigniertes Zertifikat in Embedded Jetty verwendet?

Question

Ziel: Ich möchte, dass diese URL (https://localhost:8083) mein selbstsigniertes Zertifikat auf meiner lokalen Maschine verwendet.

Zuerst habe ich diese URL referenziert (https://gist.github.com/oslego/f13e136ffeaa6174289a) und dem, was ich tat, war:

$ openssl genrsa -des3 -out server.orig.key 2048

$ openssl rsa -in server.orig .key -out server.key

$ openssl req -new -Taste server.key -out server.csr

Land Name (2-Buchstaben-Code) [AU]:

...

Common Name: localhost.ssl ​​

...

openssl $ x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

$ echo "127.0.0.1 localhost.ssl" | sudo tee -a/private/etc/hosts

ich dann server.crt konvertieren, indem die Ausführung

$ openssl x509 -in server.crt -out keystore.pem -outform PEM server.pem

$ keytool -import -trustcacerts -alias testcert -datei keystore.pem -keypass testpass -keystore keystore.jks -storepass testpass

$ keytool -export -alias mykey -keystore keystore.jks -rfc -file-Vertrauens

$ vim keystore.password // manuell erstellt keystore.password über vim

Aber wenn ich auf https://localhost:8083 zugreifen, es nicht mit SSL arbeiten.

Dann
Ich habe auch ein anderes Zertifikat mit

Common Name: localhost

$ "127.0.0.1 localhost" echo | sudo tee -a/privat/etc/hosts

Aber das funktioniert auch nicht. Wie kann ich meinen https://localhost:8083 mein selbstsigniertes Zertifikat verwenden?

FYI, ich benutze Embedded Jetty und Java liest alle Informationen korrekt über Config-Dateien, die die Standorte der Keystore.jks, Truststore und Keystore.password Dateien definiert.

Answer 1

(1) Dir die Anweisung genrsa mit Verschlüsselung und dann rsa zu geben, um die Verschlüsselung zu entfernen, ist ein guter Hinweis auf jemanden, von dem man nicht weiß, wovon er spricht und seit mindestens 10 Jahren die Manpage nicht mehr gelesen hat . Dir die Anweisung zu geben, req -new und dann x509 -req -signkey zu tun, ist ein ausgezeichneter Hinweis auf jemanden, der nicht weiß, wovon er redet und die Manpage seit mindestens 5 Jahren nicht mehr gelesen hat. Ich rate, jede Website oder jeden Autor, der diese Dinge sagt, völlig zu ignorieren. Auch die Cert-Ausgabe von x509 -req -signkey oder req -new -x509 ist bereits PEM und benötigt keine Konvertierung.

(2) Sie geben Übersetzungen in /private/etc/hosts an und geben keine Auskunft darüber, welche Browser und/oder andere Clients oder Middleware (n) Sie verwenden, aber ich habe noch nie von einem Client gehört (s) die eine solche Datei für die Namensauflösung verwenden, es sei denn, Sie verwenden eine Jail oder einen Container einer Art, die Sie nicht in Ihrer Frage angegeben haben. (Praktisch alle Unix-Systeme tun oder können /etc/hosts verwenden, aber das ist nicht das Gleiche.)

(3) Sie geben auch keine Ahnung, was "nicht funktioniert" bedeutet. Aber wenn es Handshake-Fehler aufgrund von Verschlüsselungskonflikten (nicht immer als solche erkannt) bedeutet, liegt es zweifellos daran, dass Sie den Java-Keystore und somit Jetty nur Ihr Zertifikat eingegeben haben, wenn der SSL/TLS-Server den privaten Schlüssel benötigt. Das macht dies zu einem Duplikat mehrerer Fragen, die unter https://stackoverflow.com/a/37423399/2868801 verknüpft sind, die alle mit leicht unterschiedlichen Details erklären, dass Sie openssl pkcs12 -export verwenden müssen, um den PKR-Schlüssel des Zertifikats PLUS in eine PKCS12-Datei zu konvertieren und dann die PKCS12-Datei in Java zu verwenden oder zu konvertieren.

(4) jww ist teilweise korrekt; Aktuelle Standards verlangen, dass Zertifikate die SubjectAltName (SAN) -Erweiterung enthalten, und Sie sollten das tun - was viel einfacher ist mit req -new -x509 als mit der Methode, die Sie haben, siehe (1). Aber bis jetzt nur erzwingt diese Anforderung, so ein offiziell-veraltetes Zertifikat mit nur Subject.CN wird tatsächlich in anderen Clients arbeiten - sobald Sie sie auf dieses Zertifikat vertrauen, was immer ein Problem für selbstsigniert ist.