jetty-project / jetty-alpn Goto Github PK

Implementation of ALPN (Application Layer Protocol Negotiation) Specification for OpenJDK 7 or greater

Java 100.00%

jetty-alpn's Introduction

Jetty ALPN

Implementation of the ALPN (Application Layer Protocol Negotiation) Specification (RFC 7301) for OpenJDK 8.

❗	The ALPN APIs have been backported from Java 9 to OpenJDK 8u252. Therefore, since OpenJDK 8u252 there is no more need for the Jetty ALPN boot jar provided by this project. Please read the following blog entry for more context: https://webtide.com/jetty-alpn-java-8u252/.

🔥	There are Java vendors that produced a 8u251 version that unfortunately is incompatible with the previous OpenJDK version (8u242) and incompatible with OpenJDK 8u252 as well. There is no support for the 8u251 version from any vendor.

How to use ALPN with OpenJDK 8

The following are the options that allow you to use ALPN in your applications.

Option 1 - Enforce OpenJDK 8u252 or later

Enforce the use of OpenJDK 8u252 or later for your project.

Use directly the backported ALPN APIs provided by the OpenJDK 8u252 or later, or libraries that use the backported ALPN APIs.

There is no more need to add the Jetty ALPN boot jar provided by this project to the bootclasspath.

Option 2 - Use the Jetty ALPN Agent

Use the Jetty ALPN Agent 2.0.10 or later.

Add the agent to your command line options for any version of Java 8.

The agent will dynamically detect if the Java 8 version you are running requires the redefinition of the SSL classes (the redefinitions are provided by this project) to implement ALPN. If the Java 8 version you are using is 8u252 or later, the Jetty ALPN Agent will not redefine any class.

When using the Jetty ALPN Agent and OpenJDK 8u252 or later, applications should arrange to use directly, or via some other library such as the Jetty ALPN libraries, the backported ALPN APIs.

Option 3 - Carefully setup the command line

This option requires that you know exactly what Java 8 version your application uses, and change the command line options accordingly.

If you use OpenJDK 8u242 or earlier, you must add the corresponding Jetty ALPN boot jar to the bootclasspath.

If you use OpenJDK 8u252 or later, you must NOT add the Jetty ALPN boot jar to the bootclasspath.

Jetty ALPN libraries

The Jetty Project artifacts jetty-alpn-openjdk8-[client|server], version 9.4.28 or later, provide transparent support for ALPN.

If the OpenJDK version is 8u252 or later, they will use the backported ALPN APIs.

Otherwise, they will use the Jetty ALPN APIs provided by the Jetty ALPN boot jar (this project) that must be therefore present in the bootclasspath.

OpenJDK 8 version to ALPN version mapping

Please see the mapping table.

The table only shows the mapping up to OpenJDK 8u242, the last version that required the ALPN boot jar.

jetty-alpn's People

Contributors

Stargazers

Watchers

jetty-alpn's Issues

ALPN update for JDK8u242

Is there any change in ALPN for JDK8u242? If yes, when can we expect the compatible release?

1.8.0_131 support

And jetty-alpn-agent, of course. The current version works with JDKs up to 121.

Introduce a jdk-to-alpn version mapping file

The main use case for this would be for others to be able to query what alpn-boot jar to use given a jdk version.

This can be a simple property file with the following structure:

<jdk_version>=<alpn_boot_version>

For example:

...
1.8.0_112=8.1.10.v20161026
1.8.0_121=8.1.11.v20170118
1.8.0_131=8.1.11.v20170118
1.8.0_141=8.1.11.v20170118

The tools can easily parse this file with shell scripts, dynamic web pages and the like.

Can it be used with tomcat?

It was say tomcat http2 must use Http11AprProtocol.
I am wondering with jetty-alpn, can tomcat http2 work with Http11NioProtocol or Http11Nio2Protocol?

Jack

OpenJDK 1.8.0_181 b13 support

Hi,

We encounter several issues while upgrading to OpenJDK 1.8.0_181:

Caused by: java.lang.NoSuchMethodError: sun.security.ssl.SSLSessionImpl.<init>(Lsun/security/ssl/ProtocolVersion;Lsun/security/ssl/CipherSuite;Ljava/util/Collection;Lsun/security/ssl/SessionId;Ljava/lang/String;IZ)V
        at sun.security.ssl.ClientHandshaker.serverHello(ClientHandshaker.java:723)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:210)
        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.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1408)
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1316)
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1159)
        ... 19 common frames omitted

According to what I'm understanding, the following commit should be also available for OpenJDK 1.8.0_181 but it isn't: 961d150

selected() not run for cached sessions

If a session is resumed, supports() and protocols() are called, but selected() is never called. It seems that for cached sessions severHello() returns at ClientHandshaker.java:631, whereas ALPN selected() processing starts on line 662.

Support JDK 8u191 / 8u192

there seems to be some incompatible changes in the Handshake handling

affected classes:
sun.security.ssl.ClientHandshaker
sun.security.ssl.ServerHandshaker

alpn-api vulnerability

This is more for https://github.com/eclipse/jetty.alpn.api but I can't open an issue there.

The latest version of the API is 1.1.3.v20160715:
https://mvnrepository.com/artifact/org.eclipse.jetty.alpn/alpn-api/1.1.3.v20160715
But it's flagged as vulnerable by https://github.com/jeremylong/DependencyCheck
I understand this is a false positive since I guess it's checking if the version number is greater or so.

Is there any solution to avoid this flagging? Like releasing a newer version?

See: http4s/blaze#235

Thanks

License of Project

Hello,
Thanks for this project.
I'd like to know under which License this project is distributed ?

Apache ?
LGPL ?
BSD ?
...

Thank you

Compile error with Oracle JDK 8u121

alpn-boot does not compile with jdk8u121 because some method/variable/constructor where removed in sun.security.ssl.SupportedEllipticCurvesExtension and sun.security.ssl.ECDHCrypt.

You can find my maven output here: compile_error_e_jdk8u121.txt

The build worked with older jdk versions.

Xbootclasspath/p question

I am attempting to use alpn-boot and npn-boot in the same project by including multiple entries in -Xbootclasspath/p. The oracle docs (http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html) say to separate multiple entries with a semi-colon. I have done this and am able to get a successful build (which runs test cases that run npn and alpn scenarios) on linux (open-jdk7, oracle-jdk7) but not on windows (oracle-jdk7). Can you advise if this is a supported use case and see if my scenarios below reveal anything problematic?

Here are some scenarios and observations (again only on windows...see version information below)

Only list ALPN jar on -Xbootclasspath/p
-> ALPN tests pass (npn tests are skipped because classes not loaded)
Only list NPN jar on -Xbootclasspath/p
-> NPN tests pass (alpn tests are skipped because classes not loaded)
List ALPN then NPN on -Xbootclasspath/p
-> ALPN tests pass, but NPN tests are run and fail. The NPN classes appear to be loaded but none of the methods NPN methods are invoked. I am using the NextProtoNego.put(engine, new ServerProvider/ClientProvider() ...).
List NPN then ALPN on -Xbootclasspath/p
-> NPN tests pass, but ALPN test run and fail. It seems as though some of the ALPN classes/types fail to load and I get the below exception. It seems as though my checks to detect if alpn-boot and npn-boot are on the classpath need some work (see netty/netty#2835)

java.lang.NoSuchFieldError: EXT_ALPN
at sun.security.ssl.ALPNExtension.(ALPNExtension.java:29)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)

version information

mvn --version
Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T09:51:42-04:00)
Maven home: C:\apache-maven-3.2.2\bin..
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_45\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

SSLProtocolException: Handshake message sequence violation, 1

Hello,

From time to time I got the following exception during a connection. Could you tell me what is the cause of the error? Is there a way to solve it?

build	25-Jan-2018 06:05:33	2018-01-25T05:05:33.758+0000  [HttpClient@1767523455-28] WARN  org.eclipse.jetty.io.SelectorManager - Exception while notifying connection SslConnection@6ff29fc0{NEED_UNWRAP,eio=-1/-1,di=-1}=>ALPNClientConnection@50fc8c8b<-SocketChannelEndPoint@4e7e8fa3{localhost/127.0.0.1:54396<->/127.0.0.1:54396,CLOSED,fill=-,flush=-,to=2/0}{io=0/0,kio=-1,kro=-1}->SslConnection@6ff29fc0{NEED_UNWRAP,eio=-1/-1,di=-1}=>ALPNClientConnection@50fc8c8b
build	25-Jan-2018 06:05:33	org.eclipse.jetty.io.RuntimeIOException: javax.net.ssl.SSLHandshakeException: Handshake message sequence violation, 1
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.NegotiatingClientConnection.onOpen(NegotiatingClientConnection.java:73) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:249) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:322) [jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:213) [jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ManagedSelector.access$1600(ManagedSelector.java:60) [jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ManagedSelector$CreateEndPoint.run(ManagedSelector.java:650) [jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) [jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) [jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151]
build	25-Jan-2018 06:05:33	Caused by: javax.net.ssl.SSLHandshakeException: Handshake message sequence violation, 1
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:804) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1054) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.NegotiatingClientConnection.onOpen(NegotiatingClientConnection.java:64) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		... 8 more
build	25-Jan-2018 06:05:33	Caused by: javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 1
build	25-Jan-2018 06:05:33		at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1487) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:653) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1054) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.NegotiatingClientConnection.onOpen(NegotiatingClientConnection.java:64) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		... 8 more
build	25-Jan-2018 06:05:33	Caused by: javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 1
build	25-Jan-2018 06:05:33		at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:200) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.Handshaker$1.run(Handshaker.java:966) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.Handshaker$1.run(Handshaker.java:963) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416) ~[?:1.8.0_151]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:747) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1054) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		at org.eclipse.jetty.io.NegotiatingClientConnection.onOpen(NegotiatingClientConnection.java:64) ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
build	25-Jan-2018 06:05:33		... 8 more

Thank you in advance!

jetty-alpn incompatible with OpenJDK 8u251

The readme for this project appears to be mistaken - 8u251 does not backport the ALPN APIs, instead it's broken by the removal of SSLSessionImpl.nullSession:

Caused by: java.lang.NoSuchFieldError: nullSession
	at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1350)
	at sun.security.ssl.Handshaker.kickstart(Handshaker.java:1074)
	at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1479)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1346)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
	at com.amazonaws.http.conn.ssl.SdkTLSSocketFactory.connectSocket(SdkTLSSocketFactory.java:142)

See:

This line:

jetty-alpn/alpn-boot/src/main/java/sun/security/ssl/ClientHandshaker.java

Line 1350 in 279b4ae

SessionId sessionId = SSLSessionImpl.nullSession.getSessionId();

Needs to be changed to:

        SessionId sessionId = new SessionId(new byte[0]);

Possible version incompatibility

square/okhttp#4423 (comment)

Flagging, but might be red herring at the moment.

ALPN API should allow throwing IOException or SSLException

On its foundation, the problem is simple: in the event that protocol selection fails, an ALPN.Provider wants to throw an exception. An SSLException is attractive as existing error handling can appropriately deal with the exception.

Netty

Netty is currently throwing SSLHandshakeException if protocol selection fails within ServerProvider.select() or ClientProvider.selected(). I initially thought that Netty was doing something unreasonable, as it uses Generic tricks/Unsafe to throw the checked exception from select().

However, due to the Sun SSL Handler all exceptions thrown are wrapped, but a select few (including SSLHandshakeException) maintain their type.

Jetty

Jetty has a filter that only exposes "system classes" from the bootstrap class loader. Although it is supposed to be possible to configure what classes are "system classes," we had considerable trouble getting it to work. Even if we figured out a recipe to get Jetty working, Jetty is not the only container performing such tricks. Most importantly, the failure mode is that the ALPN-using application code loads a different ALPN class than the one that exists in the bootstrap class loader. This means that registering the ALPN provider appears to work and we can verify that the ALPNExtension is loaded, but nothing functions because ALPN is no longer a true singleton.

A much more reliable method for users that Just Works™ (although uglier for library developers) is to use reflection to get the ALPN Class from the bootstrap class loader (by passing "null" as the ClassLoader). This will succeed if and only if ALPN boot is in the bootclasspath. Since ALPN.ServerProvider and similar may be hidden just like ALPN, you have to use java.lang.reflect.Proxy to implement them.

Netty + Jetty

Netty's current hack works today, but it is unable to be used with Proxy, and thus is harder to run within Jetty and other containers. Proxy notices that a checked exception was thrown from a method not throwing checked exceptions and wraps the SSLHandshakeException in UndeclaredThrowableException. The UndeclaredThrowableException is then subsequently wrapped in a RuntimeException by the SSL code.

I have investigated fixing Netty to no longer throw a checked exception and no longer throw an exception at all, but these did not prove very feasible. I have investigated further hacks on top of the current set, and although there are some options, they are highly unpalatable.

I've already confirmed that ALPN boot would need no changes to support checked exceptions from select()/selected() Provider methods. Given the other constraints involved it seems the best approach is to change the ALPN API to allow throwing SSLException.

Unexpected http request response

Hello!

I do not really know where should i ask question like that.

Test url: "https://yandex.ru/"
Java http client: okhttp

Problem:
if i request that url via latest jdk8 ( 8u221 ) and latest alpn ( alpn-boot-8.1.13.v20181017.jar ) -> i get 403 response.
if i run absolutely the same code via jdk 8u152 and alpn ( alpn-boot-8.1.11.v20170118.jar ) -> i get 200 response as expected.

In both cases request goes via http2 ( as expected ).

I am very interested - how can that be possible?
If i use another test url ( e.g. "https://www.google.ru" ) -> i always get success response ( as expected ).
If i do not use alpn ( and, respectively, http2 ) -> request goes via http1.1 -> also success response with both java versions.

What do you think?
Thanks.

version info for java 1.7.71 and 1.7.72

The version information for NPN was updated on the jetty website for java 7u71 and 7u72 here http://www.eclipse.org/jetty/documentation/current/npn-chapter.html. Is this needed for ALPN?

How to fail handshake due to no compatible protocols

What is the correct way to get jetty-alpn to generate the no_application_protocol alert as detailed in the ALPN RFC?

Jetty ALPN does not allow the return of the select method to be null (see the call site).

The javadoc in alpn-api select method also states null is not allowed as a return value:

        /**
         * Callback invoked to let the server application select
         * a protocol among the ones sent by the client.
         *
         * @param protocols the protocols sent by the client
         * @return the protocol selected by the server application;
         * must not be null
         */
        public String select(List<String> protocols);

Jetty-alpn 8.1.13 is incompatible with the latest jdk8u252-ga build

Hi,

I find out Jetty-alpn 8.1.13 is incompatible with the latest jdk8u252-ga available at 04/14. The Jetty-alpn fails to build due to null session object static final SSLSessionImpl nullSession has been removed from SSLSessionImpl class since 8u252.

    [javac]src/sun/security/ssl/ClientHandshaker.java:1350: error: cannot find symbol
    [javac]         SessionId sessionId = SSLSessionImpl.nullSession.getSessionId();
    [javac]                                             ^
    [javac]   symbol:   variable nullSession

Error when concurrent call during TLS initialization

Hello,

I got the following error when I execute concurrent calls as a first call.

If only one call is executed alone and then concurrent calls are executed it works fine.

I suspect a thread safety error during the initialization of an object.
I am using the following environment

jdk1.8.0_152
ALPN boot 8.1.11.v20170118
Jetty 9.4.8

javax.ws.rs.ProcessingException: 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
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:284)
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:278)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$2(JerseyInvocation.java:787)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:229)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414)
	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:785)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:438)
	at org.glassfish.jersey.client.proxy.WebResourceFactory.invoke(WebResourceFactory.java:355)
	at com.ingenico.gs.esf.http.jetty.client.ClientProxyProvider.invokeRemoteProxy(ClientProxyProvider.java:27)
	at com.ingenico.gs.esf.http.jetty.client.RetryableProxyService.invoke(RetryableProxyService.java:98)
	at com.sun.proxy.$Proxy143.signature(Unknown Source)
	at com.ingenico.gs.esf.http.jetty.authentication.AuthenticationKeyManagementClient.lambda$newKeyIfAbsent$3(AuthenticationKeyManagementClient.java:148)
	at com.ingenico.gs.esf.cache.api.Cache.computeIfAbsent(Cache.java:104)
	at com.ingenico.gs.esf.http.jetty.authentication.AuthenticationKeyManagementClient.newKeyIfAbsent(AuthenticationKeyManagementClient.java:147)
	at com.ingenico.gs.esf.http.jetty.authentication.AuthenticationKeyManagementClient.getKey(AuthenticationKeyManagementClient.java:131)
	at com.ingenico.gs.esf.http.jetty.authentication.AuthenticationKeyManagementClient.getRequestSignatureKey(AuthenticationKeyManagementClient.java:100)
	at com.ingenico.gs.esf.http.api.hmac.SignatureService.sign(SignatureService.java:95)
	at com.ingenico.gs.esf.http.api.client.filter.RequestSignatureFilter.filter(RequestSignatureFilter.java:52)
	at org.glassfish.jersey.client.ClientFilteringStages$RequestFilteringStage.apply(ClientFilteringStages.java:108)
	at org.glassfish.jersey.client.ClientFilteringStages$RequestFilteringStage.apply(ClientFilteringStages.java:96)
	at org.glassfish.jersey.process.internal.Stages.process(Stages.java:171)
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:278)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$2(JerseyInvocation.java:787)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:229)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414)
	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:785)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:438)
	at org.glassfish.jersey.client.proxy.WebResourceFactory.invoke(WebResourceFactory.java:355)
	at com.sun.proxy.$Proxy140.ping(Unknown Source)
	at com.ingenico.gs.esf.http.jetty.testtools.server.SetupTest.lambda$null$0(SetupTest.java:152)
	at java.lang.Thread.run(Thread.java:748)
Caused by: 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
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1595)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:220)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
	at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:390)
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:282)
	... 34 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
	at sun.security.validator.Validator.validate(Validator.java:260)
	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1577)
	... 49 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
	... 55 more

ALPN is not compatible with both Java 8 and 9

I have updated my dependencies to use the following Maven dependencies to work with Java 9.

        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-alpn-java-server</artifactId>
            <version>${jetty.version}</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-alpn-java-client</artifactId>
            <version>${jetty.version}</version>
        </dependency>

It works well with Java 9. However, it does not work with Java 8 since the classes has been compile with target 9 (see the following snippet from the pom.xml of jetty-alpn-java-server).

<build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.9</source>
                    <target>1.9</target>
                    <release>9</release>
                </configuration>
            </plugin>
        </plugins>
    </build>

I got the following error using Java 8.

java.lang.UnsupportedClassVersionError: org/eclipse/jetty/alpn/java/server/JDK9ServerALPNProcessor has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0

	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:49)

I use Java 8_144 and 9.0.1 with Jetty 9.4.7.

Could you build the jar with target 1.8 such that it also works with Java 8 projects?