-
Bug
-
Resolution: Done
-
Blocker
-
7.1.0.DR18
-
Blocks Testing
-
-
-
-
-
-
Having set two way SSL Elytron server-ssl-context [1] but with trust-managers with certificate-revocation-list set (and algorithm unset), a client is not able to connect to the server, because the server closes connections.
Debugging reveals that just getAcceptedIssuers method is called on X509CRLExtendedTrustManager and returns null (as set from the subsystem).
There is also unexpected error in server log (twice):
ERROR [org.xnio.nio] (default I/O-3) XNIO000011: Task io.undertow.protocols.ssl.SslConduit$5$1@106b714d failed with an exception: java.lang.RuntimeException: Delegated task threw Exception/Error at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1429) at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265) at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:73) at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:749) at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:646) at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63) at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1046) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588) at org.xnio.nio.WorkerThread.run(WorkerThread.java:468) Caused by: java.lang.NullPointerException at sun.security.ssl.HandshakeMessage$CertificateRequest.<init>(HandshakeMessage.java:1306) at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:963) at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) at sun.security.ssl.Handshaker$1.run(Handshaker.java:919) at sun.security.ssl.Handshaker$1.run(Handshaker.java:916) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369) at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1034) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
The CRL functionality is required by EAP7-203, hence Blocker priority is set.
[1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildFlyElytronSecurity-EnableTwowaySSL%2FTLSinWildFlyforApplications
[2] https://docs.jboss.org/author/display/WFLY/SSL+Configuration+using+Elytron+Subsystem#SSLConfigurationusingElytronSubsystem-UsingaCertificateRevocationList
- is cloned by
-
WFCORE-2821 Elytron two way SSL with CRL set does not work
- Resolved
- is incorporated by
-
JBEAP-10845 (7.1.0) Upgrade to WildFly Core to 3.0.0.Beta23
- Closed
- is related to
-
JBEAP-11221 Elytron CRL do not reflect maximum-cert-path
- Resolved
-
JBEAP-11225 Elytron reload-certificate-revocation-list operation should fail when invalid CRL file is used
- Closed
-
ELY-1166 X509CRLExtendedTrustManager should default to an empty accept issuers list
- Resolved