Client certificate support is broken in 2.176.1+ by changes in Jetty.

When running jenkins with winstone/jetty configured to require client cert auth most (all?) client certs will fail validation with an error such as:

java.security.cert.CertificateException: No subject alternative names matching IP address x.x.x.x.x found

This error message is only visible if debug logging is enabled: JAVA_OPTS= -Djavax.net.debug=ssl:handshake

We have tracked this down to the Winstone 5.2 upgrade in 2.176.1 (https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/lts.yml#L2518) which in turn was caused by a change in jetty 9.4.15+

The summary of the issue is that Jetty changed the default behavior of their SslContextFactory to improve cert verification for their HttpClient implementation. Since both the Http server and client functions in jetty use the same SslContextFactory this broke the https server use case.

Jetty decided to address this bug by creating SslContextFactory.Server and .Client subclasses in v9.4.18+. But the broken behavior remains in the parent SslContextFactory which is what winstone is using: https://github.com/eclipse/jetty.project/pull/3480

There are several bug/issue reports against the Jetty project for this:

• https://github.com/eclipse/jetty.project/issues/3454
• https://github.com/eclipse/jetty.project/issues/3554

It appears that there are two possible fixes in winstone:

1. Switch from using SslContextFactory -> SslContextFactory.Server
2. or, set endpointIdentificationAlgorithm to "null" in the existing use of SslContextFactory

Here is an example from the apache/felix project of how they fixed this bug by switching to the new Server subclass introduced by jetty #3480 (v9.4.18+): https://github.com/apache/felix/pull/199/files

I have been unable to find a workaround for this such as setting the "endpointIdentificationAlgorithm" property to 'null' using JAVA_OPTS. The only fix we've found is to pin our use of jenkins to v2.164.3