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.

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

Jetty hands IP address to SSL for handshake instead of hostname #3466

Closed
mcooper7290 opened this issue Mar 15, 2019 · 4 comments
Closed

Jetty hands IP address to SSL for handshake instead of hostname #3466

mcooper7290 opened this issue Mar 15, 2019 · 4 comments

Comments

@mcooper7290
Copy link

Starting with 9.4.15.v20190215 jetty embedded appears to pass the IP address of the incoming client to the Java SSL layer for handshake.

We have a server app which uses embedded jetty to receive connections. Some connections require the client to send a certificate with ClientAuth. The ClientAuth cert has a Subject CN=host.domain and a SAN of "DNS:host.domain". This has worked perfectly fine in jetty through 9.4.14.v20181114. Starting with 9.4.15.v20190215 the server will reject the incoming connection during SSL handshake:

IDLE session T54, fatal error: 46: General SSLEngine problem
java.security.cert.CertificateException: No subject alternative names matching IP address 192.5.10.161 found

The client side will report "certificate_unknown" during the SSL handshake.

Based on this i am guessing that jetty is handing the URI of the incoming connection to the SSL handler with the IP address of the connection instead of the hostname.

@sbordet
Copy link
Contributor

sbordet commented Mar 15, 2019

@mcooper7290 I believe you have hit the same problem as #3454.
Can you please configure your SslContextFactory with endpointIdentificationAlgorihtm to null and tell if you still see the issue?

As for IP vs hostname, I think the server always used the IP because it's unlikely that it has DNS setup to know all the client hostnames; in 9.4.14 the hostname check was simply not enforced.

@mcooper7290
Copy link
Author

Yes use setEndpointIdentificationAlgorithm(null) fixes the problem.

We do appreciate the quick response with a fix but as pointed out in #3454 this change in behavior is extremely unfriendly. It should have been implemented through a new interface of some type.

@sbordet
Copy link
Contributor

sbordet commented Mar 15, 2019

@mcooper7290 we are working on that, see #3464.

@joakime
Copy link
Contributor

joakime commented Apr 8, 2019

Closing as work is being done in issue #3464

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants