Can't access WildFly over HTTPS with browsers but can with OpenSSL client

Question

I've deployed Keycloak on WildFly 10 via Docker. SSL support was enabled via cli. Final standalone.xml has:

<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 was generated and placed in $JBOSS_HOME/standalone/configuration

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 is exposed via Docker.

Accessing https://mydomain:8443/ in chrome results in ERR_CONNECTION_CLOSED. Firefox returns "Secure Connection Failed, the connection was interrupted..."

However, OpenSSL client works nicely:

 openssl s_client -connect mydomain:8443

Input:

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

This returns the Keycloak welcome page.

So clearly WildFly is working but I am being blocked by the browsers for whatever reason. What could this reason be? I was under the impression that I should be able to add an exception for self signed certificate in either browser. Maybe the generated key length is too short or maybe I am hitting some other security constraint imposed by Firefox/Chrome?

I always get ERR_SSL_PROTOCOL_ERROR. created the jks and made above changes. Can't understand what might be the problem. — Anwar Reefat, Nov 08 '21 at 07:12

score 1 · Answer 1 · answered May 16 '16 at 20:14

1

Using these parameters in keytool solved the problem: -keyalg RSA -keysize 2048

answered May 16 '16 at 20:14

cen

2,873
3
31
56

score 0 · Answer 2 · edited May 23 '17 at 12:08

... -dname "CN=mydomain

The certificate is probably malformed. The Browsers and other user agents, like cURL and OpenSSL, use different policies to validate a end-entity certificate. The browser will reject a certificate if the hostname is in the Common Name (CN), while other user agents will accept it.

The short answer to this problem is, place DNS names in the Subject Alternate Name (SAN), and not the Common Name (CN).

You may still encounter other problems, but getting the names right will help immensely with browsers.

However, OpenSSL client works nicely:
openssl s_client -connect mydomain:8443

OpenSSL prior to 1.1.0 did not perform hostname validation. Prior version will accept any name.

cURL or Wget would be a better tool to test with in this case.

For reading on the verification you should perform when using OpenSSL, see:

SSL/TLS Client

For reading on the rules for hostnames and where they should appear in a X509 certificate, see:

Can't access WildFly over HTTPS with browsers but can with OpenSSL client

2 Answers2