[keycloak-user] Version 2.5.0 Java client cannot handshake with SSL SAN certificates?

[Bill Burton]

Hello,

I'm having an issue where after a user successfully logs in to the
application, the Java client tries to connect to the Keycloak server to get
the token verified and fails with the user seeing the text, "Forbidden" in
the browser. In the server.log is the following:

2017-12-14 23:48:17,671 WARN  [org.keycloak.events] (default task-18)
type=CODE_TO_TOKEN_ERROR, realmId=MyRealm, clientId=my-client-1,
userId=5d019b47-59dd-46f4
-8c31-8c280c5ba31a, ipAddress=10.65.15.22, error=invalid_code,
grant_type=authorization_code,
code_id=dc589b79-7ebc-4a73-a842-0ac988eb4cec, client_auth_method=
client-secret
2017-12-14 23:48:17,674 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-18)
JtaTransactionWrapper  commit
2017-12-14 23:48:17,676 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-18)
JtaTransactionWrapper end
2017-12-14 23:48:17,685 INFO  [stdout] (default task-18) default task-18,
WRITE: TLSv1.2 Application Data, length = 316
2017-12-14 23:48:17,794 INFO  [stdout] (default task-12) default task-12,
READ: TLSv1.2 Application Data, length = 552
2017-12-14 23:48:17,806 INFO  [stdout] (default task-12) default task-12,
called close()
2017-12-14 23:48:17,806 INFO  [stdout] (default task-12) default task-12,
called closeInternal(true)
2017-12-14 23:48:17,806 INFO  [stdout] (default task-12) default task-12,
SEND TLSv1.2 ALERT:  warning, description = close_notify
2017-12-14 23:48:17,807 INFO  [stdout] (default task-12) default task-12,
WRITE: TLSv1.2 Alert, length = 26
2017-12-14 23:48:17,807 INFO  [stdout] (default task-12) default task-12,
called closeSocket(true)
2017-12-14 23:48:17,807 INFO  [stdout] (default task-12) default task-12,
called close()
2017-12-14 23:48:17,807 INFO  [stdout] (default task-12) default task-12,
called closeInternal(true)
2017-12-14 23:48:17,807 ERROR
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-12) failed
to turn code into token
2017-12-14 23:48:17,807 ERROR
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-12) status
from server: 400
2017-12-14 23:48:17,807 ERROR
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-12)
[unintelligible garbage]

It's my understanding this is happening when the Java client attempts to
connect to the Keycloak server via SSL and always fails in a manner similar
to the above. Sometimes an exception is thrown with:

017-12-14 11:00:50,865 ERROR
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2) failed
to turn code into token: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target

Both the Java client and Keycloak server are at version 2.5.0 and deployed
into Wildfly 10.0. The Oracle server JDK 1.8.0 build 144 is used all around
running on RedHat Linux 6.5.

The best I can tell is the SSL handshake is failing due to a certificate
name mismatch even though I have the certificate and CA of the Keycloak
server imported into the truststore used by the Java client.

The SSL certificate used has SAN (Subject Alternative Name) entries for
many DNS entries. It's defined something like:
CN=abc.com
dnsName=abc.com
dnsName=def.com
dnsName=ghi.com
[ about 40 DNS entries in total]

For the purpose of this example, the Keycloak server is deployed to
def.com which
is different than what's defined with the CN. When the Java Keycloak client
in the same LAN attempts to connect to https://def.com/auth passing the
token, this results in a *CODE_TO_TOKEN_ERROR* with the error,
*invalid_code*.

However, when using a regular non-SAN self-signed certificate in a testing
environment where CN=def.com matches the DNS of the Keycloak server, the
SSL handshake works successfully and there is no issue.

The certificate was created using the letsencrypt.org CA - not that it
would make any difference who the CA was.

Due to limitations of the production environment I'm constrained to, using
a non-SAN or dedicated certificate is not an option so I need to find a way
get Keycloak to work with SAN certificates.

I've spent a bit of time looking through all the current and past issues
filed for Keycloak and have not found any issues that appear to be related
to this issue.

Have also looked through the Git commit history on github.com in the master
branch back to 2.5.0 and not found much of anything that could be related
to this issue.

Upgrading to a newer version of the Keycloak client is not so simple as the
application software vendor ships their product based on Wildfly 10.0,
Keycloak client and server 2.5.0 plus their own integration support already
configured in a single archive. Depending on how the archive is deployed
and configured, it takes on different roles.

In any case, I've tried to upgrade the client first to 2.5.5 and then to
3.4.3 but was unsuccessful in executing the .cli scripts either online or
offline. Probably my mistake was I didn't remove the existing Keycloak
client configuration in standalone.xml. However, if any of the vendor code
that integrates with the Keycloak client has to be updated to work with the
3.x releases I don't have access to it.

Thank you for any input,
-Bill