Zugriff auf WildFly über HTTPS mit Browsern nicht möglich, aber mit OpenSSL-Client

Question

Ich habe Keycloak auf WildFly 10 über Docker bereitgestellt. Die SSL-Unterstützung wurde über CLI aktiviert. Finale standalone.xml hat:

<security-realm name="UndertowRealm"> 
    <server-identities> 
     <ssl> 
     <keystore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password="changeit" 
alias="mydomain" key-password="changeit"/> 
     </ssl> 
    </server-identities> 
</security-realm> 

Undertow Subsystem:

<https-listener name="default-https" security-realm="UndertowRealm" 
socket-binding="https"/> 

Key generiert wurde und platziert in $ JBOSS_HOME/Standalone/Konfiguration

keytool -genkey -noprompt -alias mydomain -dname "CN=mydomain, 
OU=mydomain, O=mydomain, L=none, S=none, C=SI" -keystore 
keycloak.jks -storepass changeit -keypass changeit 

Port 8443 wird über Docker ausgesetzt.

Zugriff auf https://mydomain:8443/ in Chrom ergibt ERR_CONNECTION_CLOSED. Firefox zurück "Sichere Verbindung fehlgeschlagen, wird die Verbindung unterbrochen wurde ..."

Allerdings funktioniert OpenSSL Client schön:

openssl s_client -connect mydomain:8443 

Eingang:

GET/HTTP/1.1 
Host: https://mydomain:8443 

Dies gibt die Keycloak Seite begrüßen .

So funktioniert natürlich WildFly, aber ich bin aus irgendeinem Grund von den Browsern blockiert. Was könnte dieser Grund sein? Ich hatte den Eindruck, dass ich in jedem Browser eine Ausnahme für das selbstsignierte Zertifikat hinzufügen könnte. Vielleicht ist die generierte Schlüssellänge zu kurz oder ich treffe eine andere Sicherheitseinschränkung von Firefox/Chrome?

Answer 1

diese Parameter in keytool verwenden das Problem gelöst: -keyalg RSA -keysize 2048

Answer 2

... -dname "CN=mydomain

Das Zertifikat ist wahrscheinlich fehlerhaft. Die Browser und andere Benutzeragenten, wie cURL und OpenSSL, verwenden unterschiedliche Richtlinien, um ein End-Entitätszertifikat zu validieren. Der Browser lehnt ein Zertifikat ab, wenn sich der Hostname im Common Name (CN) befindet, während andere Benutzeragenten dies akzeptieren.

Die kurze Antwort auf dieses Problem ist, stellen DNS-Namen in der Betreff Alternate Name (SAN) und nicht die Common Name (CN).

Sie können immer noch auf andere Probleme stoßen, aber die richtigen Namen zu bekommen, wird immens mit Browsern helfen.

---

Allerdings funktioniert OpenSSL Client schön:
openssl s_client -connect mydomain:8443

OpenSSL vor 1.1.0 tat nicht Hostnamen Validierung durchführen. Vorherige Version akzeptiert einen beliebigen Namen.

cURL oder Wget wäre in diesem Fall ein besseres Werkzeug zum Testen.

---

Für über die Prüfung Lesen Sie durchführen sollten, wenn OpenSSL finden Sie unter:

• SSL/TLS Client

Für für Host-Namen über die Regeln zu lesen und wo sie in einem X509-Zertifikat erscheinen soll siehe:

• How do you sign Certificate Signing Request with your Certification Authority?
• How to create a self-signed certificate with openssl?