Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SSL error - client module - release 1.5.29 #398

Closed
ddobrin opened this issue Feb 18, 2019 · 15 comments
Closed

SSL error - client module - release 1.5.29 #398

ddobrin opened this issue Feb 18, 2019 · 15 comments
Assignees
@stevehu @DSchrupert
Labels
showstopper

Comments

@ddobrin
Copy link
Contributor

ddobrin commented Feb 18, 2019

This issue happens after the upgrade to 1.5.29 at my client.

19:47:15.181 [Client task-6] ERROR com.networknt.client.ssl.SSLUtils handleTrustValidationErrors - No subject alternative names present
java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at com.networknt.client.ssl.ClientX509ExtendedTrustManager.checkServerTrusted(ClientX509ExtendedTrustManager.java:108)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1072)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
19:47:15.200 [Client task-8] ERROR com.networknt.client.ssl.SSLUtils handleTrustValidationErrors - No subject alternative names present
java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at com.networknt.client.ssl.ClientX509ExtendedTrustManager.checkServerTrusted(ClientX509ExtendedTrustManager.java:108)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1072)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.073 sec <<< FAILURE! - in....
@DSchrupert
Copy link
Member

From this site, it looks like you have a few options:

  • If the certificate is your own, you may re-create it and add alternative names in optional fields
  • If the certificate is your own, use the host IP address instead of its name in the certificate subject
  • Map the server in /etc/hosts with the expected name in the certificate.
  • Disable hostname validation altogether.

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 18, 2019

Thanks for the link.

The builds do run fine with 1.5.28 on a MacBook, directly out of Github.
The APIs, once migrated to 1.5.29, fail.

There is no change to the APIs and failures are not expected.

Documentation would be appreciated indicating that users to 1.5.29 would need to look at making changes.

The dependency changes, as indicated in the 1.5.29 release notes, are all in place.

@DSchrupert
Copy link
Member

Yes it seems like your services depended on a bug in the code.. it's unfortunate that now that the bug is fixed your services fail. If hostname verification is enabled in your services, I think you should have expected the hostname to be verified.

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 18, 2019

Development teams do not make any changes, and start from the light-codegen project generated skeleton.

We need to educate them to overwrite the client.yml, set by default in the client module, to bypass this issue, and disable hostname verification. The default one is now set to true.

Developers don't get additional certs to start development quickly and are not aware of /etc/hosts, or Windows related changes.

There are multiple options available for addressing it, however I think that the goal needs to remain: onboard new FW users as easy as possible.

@stevehu
Copy link
Contributor

stevehu commented Feb 18, 2019

In short term, the best way is to disable the hostname verification in client.yml. There are two options in the framework. 1. disable in the client.yml in Client module of light-4j. 2. update light-codegen to generate a client.yml in the application. I am preferring the second option as eventually, this config file should be generated anyway.

Long term solution is to generate the client.truststore and server.keystore based on the config.json in the light-codegen. There are two flags that need to be added. domain dns vs service Id and we can generate self-signed certificates based on the flag.

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 18, 2019

I would agree with [2].

For my client, I have updated all APIs with a client.yml and disabled verifyHostname.

@stevehu
Copy link
Contributor

stevehu commented Feb 18, 2019

SSL error - client module - release 1.5.29

@stevehu
Copy link
Contributor

stevehu commented Feb 18, 2019

networknt/light-codegen#230

@dz-1
Copy link
Contributor

dz-1 commented Feb 19, 2019 •
edited
Loading

If the client.yml is set like the one below, the standard HTTPS hostname verification is used. That means, you cannot use IP address to access the service. The reason is that the common name in the server cert is localhost. It won't match with the IP address.

tls:
  # if the server is using self-signed certificate, this need to be false. If true, you have to use CA signed certificate
  # or load truststore that contains the self-signed cretificate.
  verifyHostname: true
  # trust store contains certifictes that server needs. Enable if tls is used.
  loadTrustStore: true

To make hostname verification work properly, the client.yml needs to be configured like the one blow.
And you need a customized XnioSsl instance to create the Http2Client. An example is shown below too.

tls:
  # if the server is using self-signed certificate, this need to be false. If true, you have to use CA signed certificate
  # or load truststore that contains the self-signed cretificate.
  verifyHostname: true
  trustedNames: 
    local: localhost
  # trust store contains certifictes that server needs. Enable if tls is used.
  loadTrustStore: true

Http2Client client = Http2Client.getInstance();

XnioSsl ssl= new UndertowXnioSsl(Http2Client.WORKER.getXnio(), OptionMap.EMPTY, Http2Client.BUFFER_POOL, Http2Client.createSSLContext("trustedNames.local"));

try {
	// Create an HTTP 2.0 connection to the server
	final ClientConnection connection = client.connect(new URI("https://127.0.0.1:8443"), Http2Client.WORKER,
			ssl, Http2Client.BUFFER_POOL, OptionMap.create(UndertowOptions.ENABLE_HTTP2, true))
			.get();

	return getData(client, connection, path);
} catch (Throwable t) {
	logger.error(t.getMessage(), t);
}

@dz-1
Copy link
Contributor

dz-1 commented Feb 19, 2019 •
edited
Loading

To make the default configuration work, we may also add the IP address (e.g., 127.0.0.1) to the subject alternative names of the server cert.
We'll need the config below when generating the keystore.

subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
IP.2 = 0.0.0.0

@stevehu
Copy link
Contributor

stevehu commented Feb 19, 2019

@dz-1 I think the default keystore only support localhost for now and I think we should encourage people to use localhost. In the future, we can support 127.0.0.1 but not 0.0.0.0 as it is not a common practice. I will update the PR based on your recommendation and resubmit. Thanks a lot.

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 20, 2019

At this time, localhost is the only one supported.
127.0.0.1 is not supported at this time

@stevehu
Copy link
Contributor

stevehu commented Feb 20, 2019

@ddobrin Could you please confirm if you need to the customized XnioSsl?

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 20, 2019

@stevehu : The default configuration, as generated by light-codegen:

  • supports localhost
  • does not support 127.0.0.1

As this issue needs to be closed and a new release published, I would agree on closing it, as long as:

  • release notes indicate clearly how developers should set their testing endpoints

The code in the APIs at my client works with all test code set with localhost, but not the ones which were set with 127.0.0.1
The APIs have been modified to use only localhost

@ddobrin
Copy link
Contributor Author

ddobrin commented Feb 21, 2019

Release notes indicate the test URL to be recommended to developers.
https://github.com/networknt/light-4j/releases

Issue will be closed

@ddobrin ddobrin closed this as completed Feb 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@stevehu stevehu

@DSchrupert DSchrupert

Labels
showstopper
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@stevehu @DSchrupert @ddobrin @dz-1