Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-24571

[GSS](7.4.z) Wrap JDK Security Execeptions and provide a easily understandable message

XMLWordPrintable

      It would be useful if we start catching exceptions from the JDK and then wrapping them and providing a better message, such as you certificate is missing intermediate certificates or such, as per my understanding the certificate (keystore/truststore) needs to contain a chain that goes all the way to a root certificate authority. 

      javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
          at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
          at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320)
          at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
          at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258)
          at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:645)
          at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:464)
          at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:360)
          at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
          at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
          at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
          at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
          at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
          at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
      [...]
      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 java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
          at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
          at java.base/sun.security.validator.Validator.validate(Validator.java:264)
          at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
          at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
          at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
          at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629)
          ... 114 more
      Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
          at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
          at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
          at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
          at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
          ... 120 more
       

      On the EJB-Client side, in the old days we just got an error that said 'no more destinations', which makes sense but does not give any hint as to what the issue might be, this got improved via adding the suppressed messages indicating it timed out and it timed out because the connection was refused.

      org.wildfly.naming.client.ExhaustedDestinationsException: WFNAM00055: No more destinations are available to attempt the operation (2 blacklisted, 0 transiently failed). See suppressed exceptions for details
          at org.wildfly.naming.client.NamingProvider.getPeerIdentityForNamingUsingRetry(NamingProvider.java:94)
           …
          at javax.naming.InitialContext.lookup(InitialContext.java:417)
          Suppressed: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is java.net.ConnectException: Operation timed out]
              at ...use of destination...(http-remoting://localhost2:8080)
           …
          Caused by: java.net.ConnectException: Operation timed out
           …
          Suppressed: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is java.net.ConnectException: Connection refused]
              at ...use of destination...(http-remoting://localhost:8180)
              at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
           …
          Caused by: java.net.ConnectException: Connection refused
       

      The EJB-Client is a different from the security error above, but similar concept in that if we start wrapping or other common exceptions and then giving a message that is more clear and perhaps even assigning an EAP/WF Error ID, it would help reduce customer cases and/or speed them up as customers would have a head start in resolving the issue.  Knowing that many of our customers that see errors are admins and not developers, this would be useful.

      cc rhn-support-cdolphy 

              mshikalw Moulali Shikalwadi
              fjuma1@redhat.com Farah Juma
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: