Search code examples
javassljettyhttp2

Jetty http2 client to ignore self-signed cert

I have an http2 server at https://ec2-52-57-54-142.eu-central-1.compute.amazonaws.com/ with a self-signed cert. And I have a jetty http2 client that simply posts things to it. For some reason, I'm not getting ignoring self-signed cert to work. Here's a snippet of relevant code

SslContextFactory factory = new SslContextFactory(true);
factory.setTrustAll(true);
factory.setValidateCerts(false);
factory.setValidatePeerCerts(false);
factory.setEndpointIdentificationAlgorithm(null);

SSLContext sslContext = factory.getSslContext();
if(null == sslContext) {
    sslContext = SSLContext.getInstance("TLS");
}
TrustManager[] verifiers = new TrustManager[] {...// some dummy trust manager that always passes};
sslContext.init(null, verifiers, null);
factory.setSslContext(sslContext);

HttpClientTransportOverHTTP2 httpClientTransportOverHTTP2
            = new HttpClientTransportOverHTTP2(new HTTP2Client());
HttpClient httpClient = new HttpClient(httpClientTransportOverHTTP2, factory);


Request request = httpClient.POST(destination);
ContentProvider contentProvider = new InputStreamContentProvider(new StringInputStream(payload));
request.content(contentProvider);
ContentResponse response = request.send();

And I get these stacktrace

Caused by: java.util.concurrent.ExecutionException: java.nio.channels.ClosedChannelException
    at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118)
    at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101)
    at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:652)
    at my code
    ... 34 more
Caused by: java.nio.channels.ClosedChannelException
    at org.eclipse.jetty.io.WriteFlusher.onClose(WriteFlusher.java:498)
    at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onIncompleteFlush(SslConnection.java:409)
    at org.eclipse.jetty.io.AbstractEndPoint$2.onIncompleteFlush(AbstractEndPoint.java:54)
    at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:322)
    at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:140)
    at org.eclipse.jetty.http2.HTTP2Flusher.process(HTTP2Flusher.java:243)
    at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
    at org.eclipse.jetty.util.IteratingCallback.succeeded(IteratingCallback.java:365)
    at org.eclipse.jetty.http2.HTTP2Flusher.succeeded(HTTP2Flusher.java:258)
    at org.eclipse.jetty.io.WriteFlusher$PendingState.complete(WriteFlusher.java:269)
    at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:394)
    at org.eclipse.jetty.io.ssl.SslConnection$1.run(SslConnection.java:101)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
    ... 1 more

When I step through things with a debugger, I see something about NOT_HANDSHAKE in one of the connection objects.

I really don't care about verifying anything. I just want to connect over HTTP2/TLS. I searched for many different terms, but they all end up with more or less the same thing (setTrustAll, custom TrustManager, etc)

Any help? Thanks!

P.S. Jetty version 9.3.12

Solution

  • Your client code is correct, although redundant. It is enough to do:

        SslContextFactory sslContextFactory = new SslContextFactory(true);

    HTTP2Client http2Client = new HTTP2Client();
    HttpClient httpClient = new HttpClient(new HttpClientTransportOverHTTP2(http2Client), sslContextFactory);
    httpClient.start();

    ContentResponse response = httpClient.GET("https://ec2-52-57-54-142.eu-central-1.compute.amazonaws.com/");

    If you enable DEBUG logging on the Jetty HTTP/2 client, you will see that the client receives:

    2016-10-05 09:20:33.102:DBUG:oejhp.Parser:qtp1897115967-15: Parsed GO_AWAY frame header from java.nio.HeapByteBuffer[pos=9 lim=35 cap=16384]
2016-10-05 09:20:33.103:DBUG:oejh.HTTP2Session:qtp1897115967-15: Received GoAwayFrame@3bc447d3,0/INADEQUATE_SECURITY_ERROR/Unknown error code

    So the problem is that the server thinks that the security is inadequate (the GOAWAY frame arrives with error code INADEQUATE_SECURITY_ERROR).

    At this point, the problem is on the server. You have to figure out why the server thinks the security is inadequate. Probably just a matter of configuration on the server.