You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Palmer <jo...@gmail.com> on 2019/04/01 19:29:42 UTC
how to enable OCSP for Tomcat w OpenSSL
What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
8.5.38 using Openssl ?
I'm sure I'm missing something simple and obvious (once pointed out) but
I've been struggling with this all morning).
1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
support - the X64 dll from
tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
(will this even work with NIO2 ? - I don't HAVE to use NIO2)
(i'd prefer to have this working with OpenSSl for a couple of reasons).
(extra points for a configuration to allow it to use Axways (formerly
Tumbleweed) Desktop Validator for its OCSP-caching features).
2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
(I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
options for the tomat service).
I can't see anything indicating OCSP checks in the logs for either.
(when the tc-native-1.dll is present, the logs show it being used:
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
[1.6.5].
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true].
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
INFO [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-openssl-nio2-192.168.1.16-443"] connector has been configured
to support negotiation to [h2] via ALPN
INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
)
for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
tomcat service I see logging for key & trust stores being loaded, etc. in
tomcat8-stdout(date).log
the server requesting a client cert, the Client cert being received and
finding a trusted root for it ("Found trusted certificate:"),
but nothing about revocation checking....
(I do see:
check handshake state: certificate_verify[15]
update handshake state: certificate_verify[15]
but I'm not sure that's revocation checking...).
for OpenSLL, I'mnot sure how to enable equivalent logging....by enabling
pretty much ALL the logging
org.apache.coyote.http2.level=ALL
org.apache.level=ALL
org.apache.catalina.session.level=ALL
I can see the truststore ("Added client CA cert") being loaded but not much
else about certificates.
Wireshark shows me OCSP calls for the SERVER cert, presumable from the
browswer (fireFox).
(I'm testing this on a personal computer, tomcat and browser on the same
computer).
If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing them.
the Connector part of the server xml.config file is (ip address and server
name etc removed):
<Connector
address="a.b.c.d"
port="443"
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
maxThreads="150"
SSLEnabled="true"
scheme="https"
secure="true"
>
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
/>
<SSLHostConfig
protocols="+TLSv1.2+TLSv1.3"
honorCipherOrder="true"
certificateVerification="REQUIRED"
truststoreFile="C:/certs/trustStore.pfx"
truststoreType="PKCS12"
truststorePassword="abcdef"
>
<Certificate
certificateKeystoreFile="C:/certs/(server).pfx"
certificateKeystoreType="PKCS12"
certificateKeystorePassword="abcdef"
/>
</SSLHostConfig>
</Connector>
Re: how to enable OCSP for Tomcat w OpenSSL
Posted by Alex O'Ree <al...@apache.org>.
This thread was super useful. thanks for sharing
On Wed, Apr 17, 2019 at 3:29 PM John Palmer <jo...@gmail.com> wrote:
> I'm still struggling with getting APR/OpenSSL to do the OCSP check.
>
> I'd appreciate some tips:
> versions: Java 8 (1.8.0_202), 64-bit, tomcat 8.5.38, APR 1.2.21
> using APR/OpenSSL (the tc-native-1.dll binary for Windows, compiled w OCSP
> support - the X64 dll from
> tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
>
> I can't get certificate revocation checking, specifically OCSP to happen
> from the APR/OpenSSL code;
> it seems to be happening instead from the Java (JSSE) code instead.
>
> I suspect a logic error is setting the OpenSSL revocation configuration
> (callback?) code to be set, then reset with the JSSE revocation
> configuration (due to the Catlina log excerpts shown below).
> I've tried following the APR initialization logic in the tomcat 8.5.35
> source, (but I get lost)...
> OpenSSLContext.java has
> SSLContext.setCertVerifyCallback()
> I suspect this is getting called correctly, then getting stepped on by the
> JSSE configuration being called (when it should be skipped).
>
> But I may just have something misconfigured.
>
>
> steps to reproduce:
>
> First, get Java revocation checking working without tc-native:
> UNcomment ocsp.enable=true in the Java\jre\lib\security\java.security file
> add
> revocationEnabled="true"
> certificateVerification="require"
> to the SSLHostConfig / Connector section of the server.xml config file.
>
>
> add -Djava.security.debug="certpath" to the Tomcat Java options (shows the
> JSSE cert validation - including OCSP if any - in the std-err log)
> or
> -Djava.security.debug="certpath ocsp" (adds hexdumps of the OCSP REQUEST
> and RESPONSE. Generally not needed)
> (add -Djavax.net.ssl.trustStore=NONE to prevent the default truststore from
> being loaded - just because it clutters the std-out log)
>
> added to loggin.properties to see some of what Tomcat is logging:
> org.apache.tomcat.util.net.openssl.level=ALL
> org.apache.tomcat.util.net.level=ALL
> org.apache.tomcat.jni.level=ALL
>
> Restart tomcat,
> access via a browser with an appropriate cert (or OpenSSL or other client
> with options to send a client cert).
>
> You now can see JSSE doing OCSP checks in the (tocat)stderr logs (wireshark
> confirms this).
>
> stop tomcat, copy the tc-native-1.dll compiled with OCSP support, restart
> tomcat...
> access via browser (or client) with a cert etc...
>
> You'll see the tomcat stderr logs show that JSSE is STILL doing the OCSP
> checks.
>
> Catalina and stdout logs show that APR/OpenSSL is loading the server and
> trusted certs, doing the SSL handshakes etc, but not the certificate
> verification. this seems to be falling through to the JSSE certificate
> verification..
> (and that JSSE is ALSO loading the trusted certs (and the server cert, I
> think).
>
>
>
> the Catlina log shows that the APR/OpenSSL stuff is loading and configuring
> properly first:
>
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
> based Apache Tomcat Native library [1.2.21] using APR version [1.6.5].
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true].
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
> configuration: useAprConnector [false], useOpenSSL [true]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> The ["https-openssl-nio2-A.B.C.D-443"] connector has been configured to
> support negotiation to [h2] via ALPN
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["https-openssl-nio2-A.B.C.D-443"]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are
> active are : [[TLSv1.3, TLSv1.2]]
> org.apache.tomcat.util.net
> .openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE
> jsse.openssl.effectiveCiphers
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are
> active are : [[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
> TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM,
> TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM,
> TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_AES_256_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384, TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384,
> TLS_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
> TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, TLS_PSK_WITH_AES_256_CCM_8,
> TLS_PSK_WITH_AES_256_CCM, TLS_PSK_WITH_AES_256_CBC_SHA384,
> TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_256_CBC_SHA,
> TLS_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_ARIA_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_PSK_DHE_WITH_AES_128_CCM_8, TLS_DHE_PSK_WITH_AES_128_CCM,
> TLS_DHE_RSA_WITH_AES_128_CCM_8, TLS_DHE_RSA_WITH_AES_128_CCM,
> TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
> TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
> TLS_SRP_SHA_WITH_AES_128_CBC_SHA, TLS_AES_128_GCM_SHA256,
> TLS_RSA_PSK_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_AES_128_GCM_SHA256, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256,
> TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256, TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256,
> TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_PSK_WITH_AES_128_CCM_8,
> TLS_PSK_WITH_AES_128_CCM, TLS_PSK_WITH_AES_128_CBC_SHA256,
> TLS_PSK_WITH_AES_128_GCM_SHA256, TLS_PSK_WITH_AES_128_CBC_SHA,
> TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_ARIA_128_GCM_SHA256]]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
> [ciphers] are not supported by the SSL engine and have been skipped:
> [[TLS_DH_DSS_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DH_RSA_WITH_AES_256_CBC_SHA256, TLS_DH_DSS_WITH_AES_256_CBC_SHA256,
> TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA,
> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_AES_128_CCM_8_SHA256,
> TLS_AES_128_CCM_SHA256, TLS_DH_DSS_WITH_AES_128_GCM_SHA256,
> TLS_DH_RSA_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DH_DSS_WITH_AES_128_CBC_SHA256, TLS_DH_RSA_WITH_AES_128_CBC_SHA,
> TLS_DH_DSS_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256]]
>
> BUT then is ALSO processed for the JSSE equivalents:
>
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are
> active are : [[TLSv1.2]]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
> [protocols] are not supported by the SSL engine and have been skipped:
> [[TLSv1.3]]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are
> active are : [[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA]]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
> [ciphers] are not supported by the SSL engine and have been skipped:
> [[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_256_CCM,
> TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM,
> TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM,
> TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
> TLS_DH_DSS_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_AES_256_CBC_SHA,
> TLS_DH_RSA_WITH_AES_256_CBC_SHA256, TLS_DH_DSS_WITH_AES_256_CBC_SHA256,
> TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384, TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384,
> TLS_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
> TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA,
> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_AES_256_CCM_8,
> TLS_PSK_WITH_AES_256_CCM, TLS_PSK_WITH_AES_256_CBC_SHA384,
> TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_256_CBC_SHA,
> TLS_PSK_WITH_CHACHA20_POLY1305_SHA256,
> TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_ARIA_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
> TLS_PSK_DHE_WITH_AES_128_CCM_8, TLS_DHE_PSK_WITH_AES_128_CCM,
> TLS_DHE_RSA_WITH_AES_128_CCM_8, TLS_DHE_RSA_WITH_AES_128_CCM,
> TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
> TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
> TLS_SRP_SHA_WITH_AES_128_CBC_SHA, TLS_AES_128_CCM_8_SHA256,
> TLS_AES_128_CCM_SHA256, TLS_AES_128_GCM_SHA256,
> TLS_RSA_PSK_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_AES_128_GCM_SHA256, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
> TLS_DH_DSS_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
> TLS_DH_RSA_WITH_AES_128_CBC_SHA256, TLS_DH_DSS_WITH_AES_128_CBC_SHA256,
> TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_DSS_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256,
> TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256, TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256,
> TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA,
> TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_AES_128_CCM_8,
> TLS_PSK_WITH_AES_128_CCM, TLS_PSK_WITH_AES_128_CBC_SHA256,
> TLS_PSK_WITH_AES_128_GCM_SHA256, TLS_PSK_WITH_AES_128_CBC_SHA,
> TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_ARIA_128_GCM_SHA256]]
> org.apache.tomcat.util.net
> .openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE
> jsse.openssl.effectiveCiphers
>
> (this claims to be dropping TSLv1.3, since Java 8 doesn't support it.. but
> testing shows TSL 1.3 and 1.2 both work)
>
>
> followed by entries for "Added client CA cert" for each trusted cert in my
> truststore
>
> stdout log shows (apparently) JSSE (also) loading the trusted certs and the
> server cert...
>
> on accessing via a browser with a working personal cert, stderr log shows
> (apparently) JSSE doing the certificate verification:
> lots of lines starting with certpath:
> plenty of lines showing -Using checkerX (checker 1 through 6, 7 if
> revocationChecker is true):
> certpath: -Using checker1 ...
> [sun.security.provider.certpath.UntrustedChecker]
> certpath: -Using checker2 ...
> [sun.security.provider.certpath.AlgorithmChecker]
> certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker]
> certpath: -Using checker4 ...
> [sun.security.provider.certpath.ConstraintsChecker]
> certpath: -Using checker5 ...
> [sun.security.provider.certpath.PolicyChecker]
> certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker]
> certpath: -Using checker7 ...
> [sun.security.provider.certpath.RevocationChecker]
>
> Catlina log shows APR/OpenSSL verification errors, referencing the java
> stuff, reinforcing my opinion that the APR/OpenSSL verificaiton isn't
> happening, that instead it's deferring to the JSSE verification:
>
> 16-Apr-2019 16:59:14.540 FINE [https-openssl-nio2-a.b.c.d-443-exec-7]
> org.apache.tomcat.util.net.openssl.OpenSSLContext$1.verify Certificate
> verification failed
> sun.security.validator.ValidatorException: PKIX path validation failed:
> java.security.cert.CertPathValidatorException: Could not determine
> revocation status
> at sun.security.validator.PKIXValidator.doValidate(Unknown Source)
> at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
> at sun.security.validator.Validator.validate(Unknown Source)
> at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
> at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(Unknown
> Source)
> at
> org.apache.tomcat.util.net
> .openssl.OpenSSLContext$1.verify(OpenSSLContext.java:347)
> at org.apache.tomcat.jni.SSL.readFromSSL(Native Method)
> at
> org.apache.tomcat.util.net
> .openssl.OpenSSLEngine.pendingReadableBytesInSSL(OpenSSLEngine.java:637)
> at
> org.apache.tomcat.util.net
> .openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:568)
> at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel.handshakeUnwrap(SecureNio2Channel.java:548)
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:318)
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel.handshake(SecureNio2Channel.java:216)
> at
> org.apache.tomcat.util.net
> .Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1660)
> at
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> org.apache.tomcat.util.net
> .AbstractEndpoint.processSocket(AbstractEndpoint.java:1051)
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:99)
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:92)
> at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
> at sun.nio.ch.Invoker$2.run(Unknown Source)
> at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.security.cert.CertPathValidatorException: Could not
> determine revocation status
> at
> sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown
> Source)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown
> Source)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown
> Source)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown
> Source)
> at java.security.cert.CertPathValidator.validate(Unknown Source)
> ... 26 more
> Caused by: java.security.cert.CertPathValidatorException: Could not
> determine revocation status
> at
> sun.security.provider.certpath.RevocationChecker.buildToNewKey(Unknown
> Source)
> at
>
> sun.security.provider.certpath.RevocationChecker.verifyWithSeparateSigningKey(Unknown
> Source)
> at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
> Source)
> at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
> Source)
> at sun.security.provider.certpath.RevocationChecker.check(Unknown
> Source)
> at sun.security.provider.certpath.RevocationChecker.check(Unknown
> Source)
> ... 31 more
>
> 16-Apr-2019 16:59:14.540 FINE [https-openssl-nio2-a.b.c.d-443-exec-7]
> org.apache.tomcat.util.net.openssl.OpenSSLEngine.checkLastError OpenSSL
> error: [337100934] message: [error:1417C086:SSL
> routines:tls_process_client_certificate:certificate verify failed]
>
>
> the Connector part of the server xml.config file is (ip address and server
> name etc removed):
>
> <Connector
> address="a.b.c.d"
> port="443"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> maxThreads="150"
> SSLEnabled="true"
> maxConnections="-1"
> scheme="https"
> secure="true"
> >
> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
> />
> <SSLHostConfig
> protocols="+TLSv1.2+TLSv1.3"
> honorCipherOrder="true"
> revocationEnabled="true"
> certificateVerification="REQUIRED"
> truststoreFile="C:/certs/trustStore.pfx"
> truststoreType="PKCS12"
> truststorePassword="abcdef"
> >
> <Certificate
> certificateKeystoreFile="C:/certs/(server).pfx"
> certificateKeystoreType="PKCS12"
> certificateKeystorePassword="abcdef"
> />
> </SSLHostConfig>
> </Connector>
>
>
> On Thu, Apr 4, 2019 at 7:47 PM John Palmer <jo...@gmail.com> wrote:
>
> > Well, after much research and experimentation I got OCSP working with the
> > JSSE flaovor, NIO2 connector (renamed the OCSP-enabled tc-native-1.dll
> so
> > it isn't used and JSSE is used instead).
> >
> > 2 things had to be set:
> > 1: server.xml: add to the SSLHostConfig section (inside the Connector
> > section)
> > revocationEnabled="true"
> > certificateVerification="require"
> >
> > 2: java.security file in the (java)\jre\lib\security folder:
> > uncomment the line: ocsp.enable=true
> > (you get a "can't connect securely to this page" in IE if you forget.)
> > (if there's a way to do this with the Java options used by the tomcat
> > service(eg -D(something)ocsp.enable="true", I'd appreciate someone
> > telling me).
> >
> > by adding -Djava.security.debug="certpath ocsp" to the Java options used
> > by the tomcat service (Windows)... I have logging showing the OCSP
> checking
> > etc....
> > and wireshark shows me the OCSP calls (there MAY be some caching being
> > done by the java (or possibly Windows CAPI) code, not all the expected
> OSCP
> > requests seem to always be there).
> >
> > by restoring the NON-OCSP-enabled tc-native-1.dll, I found that the same
> > settings allow the same java calls to work the same way....
> >
> > and by restoring the OCSP-enabled tc-native-1.dll... those still work.
> >
> > Apparently there is some OTHER setting or configuration needed for the
> > OCSP-enabled tc-native-1.dll to work... and I haven't found it yet.
> >
> > I'm trying to understand from the tc-native source what I might be
> > missing, but apparently I'm overlooking it.
> >
> >
> > helpful suggestions are welcomed.
> >
> > On Wed, Apr 3, 2019 at 12:32 PM John Palmer <jo...@gmail.com>
> wrote:
> >
> >> I appreciate your response....
> >>
> >> > Setting `certificateVerification="require"` on your Connector
> >>
> >> I changed
> >> `certificateVerification="REQUIRED"
> >> to
> >> `certificateVerification="require"`
> >>
> >> still not seeing any OCSP calls in wireshark for this
> >>
> >> I did find out how to enable logging better (by adding either of these
> >> to logging.properties):
> >> org.apache.tomcat.util.net.openssl.level=ALL
> >> org.apache.tomcat.util.net.level=ALL
> >>
> >> and I can see logs confirming that the trust store is being used:
> >> OpenSSLContext.init Added client CA cert:...) ;
> >>
> >> with logging set to org.apache.tomcat.level=ALL
> >> I see confirmation that the certificateVerification is being parsed,
> >> apparently correctly.
> >>
> >> but I still don't see any evidence in the tomcat/catlina logs or in
> >> wireshark that anything is happening to accomplish this.
> >>
> >>
> >>
> >> On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland <cs...@apache.org>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On Mon, Apr 1, 2019 at 3:30 PM John Palmer <jo...@gmail.com>
> >>> wrote:
> >>>
> >>> > What, if anything, needs to be configured to ENABLE (preferably
> >>> REQUIRE)
> >>> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
> >>> > 8.5.38 using Openssl ?
> >>>
> >>>
> >>> Setting `certificateVerification="require"` on your Connector and
> using a
> >>> client certificate that has an OCSP URI should be it. See
> >>>
> >>>
> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
> >>> for more information on how to configure it.
> >>>
> >>>
> >>> >
> >>>
> >>>
> >>> > I'm sure I'm missing something simple and obvious (once pointed out)
> >>> but
> >>> > I've been struggling with this all morning).
> >>> >
> >>> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w
> >>> OCSP
> >>> > support - the X64 dll from
> >>> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
> >>> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
> >>> >
> >>>
> >>> It will work, but only if you're using the openssl implementation.
> >>>
> >>>
> >>> > (i'd prefer to have this working with OpenSSl for a couple of
> reasons).
> >>> > (extra points for a configuration to allow it to use Axways (formerly
> >>> > Tumbleweed) Desktop Validator for its OCSP-caching features).
> >>> >
> >>> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
> >>> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
> >>> > options for the tomat service).
> >>> >
> >>> >
> >>> > I can't see anything indicating OCSP checks in the logs for either.
> >>> >
> >>>
> >>> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much
> of
> >>> anything when it's in use, so there's not much indication that it's
> >>> working
> >>> there.
> >>>
> >>>
> >>> >
> >>> > (when the tc-native-1.dll is present, the logs show it being used:
> >>> > INFO [main]
> >>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> >>> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR
> >>> version
> >>> > [1.6.5].
> >>> > INFO [main]
> >>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> >>> > APR capabilities: IPv6 [true], sendfile [true], accept filters
> [false],
> >>> > random [true].
> >>> > INFO [main]
> >>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> >>> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> >>> > INFO [main]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL
> >>> > OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
> >>> > INFO [main]
> >>> >
> >>>
> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> >>> > The ["https-openssl-nio2-192.168.1.16-443"] connector has been
> >>> configured
> >>> > to support negotiation to [h2] via ALPN
> >>> > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
> >>> > ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
> >>> > )
> >>> >
> >>> >
> >>> > for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
> >>> > tomcat service I see logging for key & trust stores being loaded,
> etc.
> >>> in
> >>> > tomcat8-stdout(date).log
> >>> > the server requesting a client cert, the Client cert being received
> and
> >>> > finding a trusted root for it ("Found trusted certificate:"),
> >>> > but nothing about revocation checking....
> >>> > (I do see:
> >>> > check handshake state: certificate_verify[15]
> >>> > update handshake state: certificate_verify[15]
> >>> >
> >>> > but I'm not sure that's revocation checking...).
> >>> >
> >>> > for OpenSLL, I'mnot sure how to enable equivalent logging....by
> >>> enabling
> >>> > pretty much ALL the logging
> >>> > org.apache.coyote.http2.level=ALL
> >>> > org.apache.level=ALL
> >>> > org.apache.catalina.session.level=ALL
> >>> > I can see the truststore ("Added client CA cert") being loaded but
> not
> >>> much
> >>> > else about certificates.
> >>> >
> >>> >
> >>> > Wireshark shows me OCSP calls for the SERVER cert, presumable from
> the
> >>> > browswer (fireFox).
> >>> > (I'm testing this on a personal computer, tomcat and browser on the
> >>> same
> >>> > computer).
> >>> > If there are equivalent OCSP calls for the CLIENT cert, I'm not
> seeing
> >>> > them.
> >>> >
> >>> >
> >>> > the Connector part of the server xml.config file is (ip address and
> >>> server
> >>> > name etc removed):
> >>> >
> >>> > <Connector
> >>> > address="a.b.c.d"
> >>> > port="443"
> >>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >>> > maxThreads="150"
> >>> > SSLEnabled="true"
> >>> > scheme="https"
> >>> > secure="true"
> >>> > >
> >>> > <UpgradeProtocol
> >>> className="org.apache.coyote.http2.Http2Protocol"
> >>> > />
> >>> > <SSLHostConfig
> >>> > protocols="+TLSv1.2+TLSv1.3"
> >>> > honorCipherOrder="true"
> >>> > certificateVerification="REQUIRED"
> >>> > truststoreFile="C:/certs/trustStore.pfx"
> >>> > truststoreType="PKCS12"
> >>> > truststorePassword="abcdef"
> >>> > >
> >>> > <Certificate
> >>> > certificateKeystoreFile="C:/certs/(server).pfx"
> >>> > certificateKeystoreType="PKCS12"
> >>> > certificateKeystorePassword="abcdef"
> >>> > />
> >>> > </SSLHostConfig>
> >>> > </Connector>
> >>> >
> >>>
> >>
>
Re: how to enable OCSP for Tomcat w OpenSSL
Posted by John Palmer <jo...@gmail.com>.
I'm still struggling with getting APR/OpenSSL to do the OCSP check.
I'd appreciate some tips:
versions: Java 8 (1.8.0_202), 64-bit, tomcat 8.5.38, APR 1.2.21
using APR/OpenSSL (the tc-native-1.dll binary for Windows, compiled w OCSP
support - the X64 dll from
tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
I can't get certificate revocation checking, specifically OCSP to happen
from the APR/OpenSSL code;
it seems to be happening instead from the Java (JSSE) code instead.
I suspect a logic error is setting the OpenSSL revocation configuration
(callback?) code to be set, then reset with the JSSE revocation
configuration (due to the Catlina log excerpts shown below).
I've tried following the APR initialization logic in the tomcat 8.5.35
source, (but I get lost)...
OpenSSLContext.java has
SSLContext.setCertVerifyCallback()
I suspect this is getting called correctly, then getting stepped on by the
JSSE configuration being called (when it should be skipped).
But I may just have something misconfigured.
steps to reproduce:
First, get Java revocation checking working without tc-native:
UNcomment ocsp.enable=true in the Java\jre\lib\security\java.security file
add
revocationEnabled="true"
certificateVerification="require"
to the SSLHostConfig / Connector section of the server.xml config file.
add -Djava.security.debug="certpath" to the Tomcat Java options (shows the
JSSE cert validation - including OCSP if any - in the std-err log)
or
-Djava.security.debug="certpath ocsp" (adds hexdumps of the OCSP REQUEST
and RESPONSE. Generally not needed)
(add -Djavax.net.ssl.trustStore=NONE to prevent the default truststore from
being loaded - just because it clutters the std-out log)
added to loggin.properties to see some of what Tomcat is logging:
org.apache.tomcat.util.net.openssl.level=ALL
org.apache.tomcat.util.net.level=ALL
org.apache.tomcat.jni.level=ALL
Restart tomcat,
access via a browser with an appropriate cert (or OpenSSL or other client
with options to send a client cert).
You now can see JSSE doing OCSP checks in the (tocat)stderr logs (wireshark
confirms this).
stop tomcat, copy the tc-native-1.dll compiled with OCSP support, restart
tomcat...
access via browser (or client) with a cert etc...
You'll see the tomcat stderr logs show that JSSE is STILL doing the OCSP
checks.
Catalina and stdout logs show that APR/OpenSSL is loading the server and
trusted certs, doing the SSL handshakes etc, but not the certificate
verification. this seems to be falling through to the JSSE certificate
verification..
(and that JSSE is ALSO loading the trusted certs (and the server cert, I
think).
the Catlina log shows that the APR/OpenSSL stuff is loading and configuring
properly first:
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library [1.2.21] using APR version [1.6.5].
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-openssl-nio2-A.B.C.D-443"] connector has been configured to
support negotiation to [h2] via ALPN
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-openssl-nio2-A.B.C.D-443"]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are
active are : [[TLSv1.3, TLSv1.2]]
org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE
jsse.openssl.effectiveCiphers
org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are
active are : [[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM,
TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM,
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384,
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384, TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, TLS_PSK_WITH_AES_256_CCM_8,
TLS_PSK_WITH_AES_256_CCM, TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_256_CBC_SHA,
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_PSK_DHE_WITH_AES_128_CCM_8, TLS_DHE_PSK_WITH_AES_128_CCM,
TLS_DHE_RSA_WITH_AES_128_CCM_8, TLS_DHE_RSA_WITH_AES_128_CCM,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_WITH_AES_128_CBC_SHA, TLS_AES_128_GCM_SHA256,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256, TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256,
TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_PSK_WITH_AES_128_CCM_8,
TLS_PSK_WITH_AES_128_CCM, TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_PSK_WITH_AES_128_GCM_SHA256, TLS_PSK_WITH_AES_128_CBC_SHA,
TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_ARIA_128_GCM_SHA256]]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
[ciphers] are not supported by the SSL engine and have been skipped:
[[TLS_DH_DSS_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
TLS_DH_RSA_WITH_AES_256_CBC_SHA256, TLS_DH_DSS_WITH_AES_256_CBC_SHA256,
TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_AES_128_CCM_8_SHA256,
TLS_AES_128_CCM_SHA256, TLS_DH_DSS_WITH_AES_128_GCM_SHA256,
TLS_DH_RSA_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DH_DSS_WITH_AES_128_CBC_SHA256, TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_DSS_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256]]
BUT then is ALSO processed for the JSSE equivalents:
org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are
active are : [[TLSv1.2]]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
[protocols] are not supported by the SSL engine and have been skipped:
[[TLSv1.3]]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are
active are : [[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA]]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified
[ciphers] are not supported by the SSL engine and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_256_CCM,
TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM,
TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM,
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
TLS_DH_DSS_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_AES_256_CBC_SHA,
TLS_DH_RSA_WITH_AES_256_CBC_SHA256, TLS_DH_DSS_WITH_AES_256_CBC_SHA256,
TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384,
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384, TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_AES_256_CCM_8,
TLS_PSK_WITH_AES_256_CCM, TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_256_CBC_SHA,
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256,
TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384, TLS_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
TLS_PSK_DHE_WITH_AES_128_CCM_8, TLS_DHE_PSK_WITH_AES_128_CCM,
TLS_DHE_RSA_WITH_AES_128_CCM_8, TLS_DHE_RSA_WITH_AES_128_CCM,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_WITH_AES_128_CBC_SHA, TLS_AES_128_CCM_8_SHA256,
TLS_AES_128_CCM_SHA256, TLS_AES_128_GCM_SHA256,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
TLS_DH_DSS_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
TLS_DH_RSA_WITH_AES_128_CBC_SHA256, TLS_DH_DSS_WITH_AES_128_CBC_SHA256,
TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256, TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256,
TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_AES_128_CCM_8,
TLS_PSK_WITH_AES_128_CCM, TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_PSK_WITH_AES_128_GCM_SHA256, TLS_PSK_WITH_AES_128_CBC_SHA,
TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256, TLS_PSK_WITH_ARIA_128_GCM_SHA256]]
org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE
jsse.openssl.effectiveCiphers
(this claims to be dropping TSLv1.3, since Java 8 doesn't support it.. but
testing shows TSL 1.3 and 1.2 both work)
followed by entries for "Added client CA cert" for each trusted cert in my
truststore
stdout log shows (apparently) JSSE (also) loading the trusted certs and the
server cert...
on accessing via a browser with a working personal cert, stderr log shows
(apparently) JSSE doing the certificate verification:
lots of lines starting with certpath:
plenty of lines showing -Using checkerX (checker 1 through 6, 7 if
revocationChecker is true):
certpath: -Using checker1 ...
[sun.security.provider.certpath.UntrustedChecker]
certpath: -Using checker2 ...
[sun.security.provider.certpath.AlgorithmChecker]
certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker]
certpath: -Using checker4 ...
[sun.security.provider.certpath.ConstraintsChecker]
certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker]
certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker]
certpath: -Using checker7 ...
[sun.security.provider.certpath.RevocationChecker]
Catlina log shows APR/OpenSSL verification errors, referencing the java
stuff, reinforcing my opinion that the APR/OpenSSL verificaiton isn't
happening, that instead it's deferring to the JSSE verification:
16-Apr-2019 16:59:14.540 FINE [https-openssl-nio2-a.b.c.d-443-exec-7]
org.apache.tomcat.util.net.openssl.OpenSSLContext$1.verify Certificate
verification failed
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: Could not determine
revocation status
at sun.security.validator.PKIXValidator.doValidate(Unknown Source)
at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
at sun.security.validator.Validator.validate(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(Unknown
Source)
at
org.apache.tomcat.util.net.openssl.OpenSSLContext$1.verify(OpenSSLContext.java:347)
at org.apache.tomcat.jni.SSL.readFromSSL(Native Method)
at
org.apache.tomcat.util.net.openssl.OpenSSLEngine.pendingReadableBytesInSSL(OpenSSLEngine.java:637)
at
org.apache.tomcat.util.net.openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:568)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at
org.apache.tomcat.util.net.SecureNio2Channel.handshakeUnwrap(SecureNio2Channel.java:548)
at
org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:318)
at
org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:216)
at
org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1660)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:1051)
at
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:99)
at
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:92)
at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
at sun.nio.ch.Invoker$2.run(Unknown Source)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertPathValidatorException: Could not
determine revocation status
at
sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown
Source)
at
sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown
Source)
at
sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown
Source)
at
sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown
Source)
at java.security.cert.CertPathValidator.validate(Unknown Source)
... 26 more
Caused by: java.security.cert.CertPathValidatorException: Could not
determine revocation status
at
sun.security.provider.certpath.RevocationChecker.buildToNewKey(Unknown
Source)
at
sun.security.provider.certpath.RevocationChecker.verifyWithSeparateSigningKey(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.check(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.check(Unknown
Source)
... 31 more
16-Apr-2019 16:59:14.540 FINE [https-openssl-nio2-a.b.c.d-443-exec-7]
org.apache.tomcat.util.net.openssl.OpenSSLEngine.checkLastError OpenSSL
error: [337100934] message: [error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed]
the Connector part of the server xml.config file is (ip address and server
name etc removed):
<Connector
address="a.b.c.d"
port="443"
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
maxThreads="150"
SSLEnabled="true"
maxConnections="-1"
scheme="https"
secure="true"
>
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
/>
<SSLHostConfig
protocols="+TLSv1.2+TLSv1.3"
honorCipherOrder="true"
revocationEnabled="true"
certificateVerification="REQUIRED"
truststoreFile="C:/certs/trustStore.pfx"
truststoreType="PKCS12"
truststorePassword="abcdef"
>
<Certificate
certificateKeystoreFile="C:/certs/(server).pfx"
certificateKeystoreType="PKCS12"
certificateKeystorePassword="abcdef"
/>
</SSLHostConfig>
</Connector>
On Thu, Apr 4, 2019 at 7:47 PM John Palmer <jo...@gmail.com> wrote:
> Well, after much research and experimentation I got OCSP working with the
> JSSE flaovor, NIO2 connector (renamed the OCSP-enabled tc-native-1.dll so
> it isn't used and JSSE is used instead).
>
> 2 things had to be set:
> 1: server.xml: add to the SSLHostConfig section (inside the Connector
> section)
> revocationEnabled="true"
> certificateVerification="require"
>
> 2: java.security file in the (java)\jre\lib\security folder:
> uncomment the line: ocsp.enable=true
> (you get a "can't connect securely to this page" in IE if you forget.)
> (if there's a way to do this with the Java options used by the tomcat
> service(eg -D(something)ocsp.enable="true", I'd appreciate someone
> telling me).
>
> by adding -Djava.security.debug="certpath ocsp" to the Java options used
> by the tomcat service (Windows)... I have logging showing the OCSP checking
> etc....
> and wireshark shows me the OCSP calls (there MAY be some caching being
> done by the java (or possibly Windows CAPI) code, not all the expected OSCP
> requests seem to always be there).
>
> by restoring the NON-OCSP-enabled tc-native-1.dll, I found that the same
> settings allow the same java calls to work the same way....
>
> and by restoring the OCSP-enabled tc-native-1.dll... those still work.
>
> Apparently there is some OTHER setting or configuration needed for the
> OCSP-enabled tc-native-1.dll to work... and I haven't found it yet.
>
> I'm trying to understand from the tc-native source what I might be
> missing, but apparently I'm overlooking it.
>
>
> helpful suggestions are welcomed.
>
> On Wed, Apr 3, 2019 at 12:32 PM John Palmer <jo...@gmail.com> wrote:
>
>> I appreciate your response....
>>
>> > Setting `certificateVerification="require"` on your Connector
>>
>> I changed
>> `certificateVerification="REQUIRED"
>> to
>> `certificateVerification="require"`
>>
>> still not seeing any OCSP calls in wireshark for this
>>
>> I did find out how to enable logging better (by adding either of these
>> to logging.properties):
>> org.apache.tomcat.util.net.openssl.level=ALL
>> org.apache.tomcat.util.net.level=ALL
>>
>> and I can see logs confirming that the trust store is being used:
>> OpenSSLContext.init Added client CA cert:...) ;
>>
>> with logging set to org.apache.tomcat.level=ALL
>> I see confirmation that the certificateVerification is being parsed,
>> apparently correctly.
>>
>> but I still don't see any evidence in the tomcat/catlina logs or in
>> wireshark that anything is happening to accomplish this.
>>
>>
>>
>> On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland <cs...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Apr 1, 2019 at 3:30 PM John Palmer <jo...@gmail.com>
>>> wrote:
>>>
>>> > What, if anything, needs to be configured to ENABLE (preferably
>>> REQUIRE)
>>> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
>>> > 8.5.38 using Openssl ?
>>>
>>>
>>> Setting `certificateVerification="require"` on your Connector and using a
>>> client certificate that has an OCSP URI should be it. See
>>>
>>> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
>>> for more information on how to configure it.
>>>
>>>
>>> >
>>>
>>>
>>> > I'm sure I'm missing something simple and obvious (once pointed out)
>>> but
>>> > I've been struggling with this all morning).
>>> >
>>> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w
>>> OCSP
>>> > support - the X64 dll from
>>> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
>>> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
>>> >
>>>
>>> It will work, but only if you're using the openssl implementation.
>>>
>>>
>>> > (i'd prefer to have this working with OpenSSl for a couple of reasons).
>>> > (extra points for a configuration to allow it to use Axways (formerly
>>> > Tumbleweed) Desktop Validator for its OCSP-caching features).
>>> >
>>> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
>>> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
>>> > options for the tomat service).
>>> >
>>> >
>>> > I can't see anything indicating OCSP checks in the logs for either.
>>> >
>>>
>>> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
>>> anything when it's in use, so there's not much indication that it's
>>> working
>>> there.
>>>
>>>
>>> >
>>> > (when the tc-native-1.dll is present, the logs show it being used:
>>> > INFO [main]
>>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>>> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR
>>> version
>>> > [1.6.5].
>>> > INFO [main]
>>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>>> > APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
>>> > random [true].
>>> > INFO [main]
>>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>>> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
>>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
>>> > OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
>>> > INFO [main]
>>> >
>>> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
>>> > The ["https-openssl-nio2-192.168.1.16-443"] connector has been
>>> configured
>>> > to support negotiation to [h2] via ALPN
>>> > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
>>> > ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
>>> > )
>>> >
>>> >
>>> > for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
>>> > tomcat service I see logging for key & trust stores being loaded, etc.
>>> in
>>> > tomcat8-stdout(date).log
>>> > the server requesting a client cert, the Client cert being received and
>>> > finding a trusted root for it ("Found trusted certificate:"),
>>> > but nothing about revocation checking....
>>> > (I do see:
>>> > check handshake state: certificate_verify[15]
>>> > update handshake state: certificate_verify[15]
>>> >
>>> > but I'm not sure that's revocation checking...).
>>> >
>>> > for OpenSLL, I'mnot sure how to enable equivalent logging....by
>>> enabling
>>> > pretty much ALL the logging
>>> > org.apache.coyote.http2.level=ALL
>>> > org.apache.level=ALL
>>> > org.apache.catalina.session.level=ALL
>>> > I can see the truststore ("Added client CA cert") being loaded but not
>>> much
>>> > else about certificates.
>>> >
>>> >
>>> > Wireshark shows me OCSP calls for the SERVER cert, presumable from the
>>> > browswer (fireFox).
>>> > (I'm testing this on a personal computer, tomcat and browser on the
>>> same
>>> > computer).
>>> > If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing
>>> > them.
>>> >
>>> >
>>> > the Connector part of the server xml.config file is (ip address and
>>> server
>>> > name etc removed):
>>> >
>>> > <Connector
>>> > address="a.b.c.d"
>>> > port="443"
>>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>> > maxThreads="150"
>>> > SSLEnabled="true"
>>> > scheme="https"
>>> > secure="true"
>>> > >
>>> > <UpgradeProtocol
>>> className="org.apache.coyote.http2.Http2Protocol"
>>> > />
>>> > <SSLHostConfig
>>> > protocols="+TLSv1.2+TLSv1.3"
>>> > honorCipherOrder="true"
>>> > certificateVerification="REQUIRED"
>>> > truststoreFile="C:/certs/trustStore.pfx"
>>> > truststoreType="PKCS12"
>>> > truststorePassword="abcdef"
>>> > >
>>> > <Certificate
>>> > certificateKeystoreFile="C:/certs/(server).pfx"
>>> > certificateKeystoreType="PKCS12"
>>> > certificateKeystorePassword="abcdef"
>>> > />
>>> > </SSLHostConfig>
>>> > </Connector>
>>> >
>>>
>>
Re: how to enable OCSP for Tomcat w OpenSSL
Posted by John Palmer <jo...@gmail.com>.
Well, after much research and experimentation I got OCSP working with the
JSSE flaovor, NIO2 connector (renamed the OCSP-enabled tc-native-1.dll so
it isn't used and JSSE is used instead).
2 things had to be set:
1: server.xml: add to the SSLHostConfig section (inside the Connector
section)
revocationEnabled="true"
certificateVerification="require"
2: java.security file in the (java)\jre\lib\security folder:
uncomment the line: ocsp.enable=true
(you get a "can't connect securely to this page" in IE if you forget.)
(if there's a way to do this with the Java options used by the tomcat
service(eg -D(something)ocsp.enable="true", I'd appreciate someone telling
me).
by adding -Djava.security.debug="certpath ocsp" to the Java options used
by the tomcat service (Windows)... I have logging showing the OCSP checking
etc....
and wireshark shows me the OCSP calls (there MAY be some caching being done
by the java (or possibly Windows CAPI) code, not all the expected OSCP
requests seem to always be there).
by restoring the NON-OCSP-enabled tc-native-1.dll, I found that the same
settings allow the same java calls to work the same way....
and by restoring the OCSP-enabled tc-native-1.dll... those still work.
Apparently there is some OTHER setting or configuration needed for the
OCSP-enabled tc-native-1.dll to work... and I haven't found it yet.
I'm trying to understand from the tc-native source what I might be missing,
but apparently I'm overlooking it.
helpful suggestions are welcomed.
On Wed, Apr 3, 2019 at 12:32 PM John Palmer <jo...@gmail.com> wrote:
> I appreciate your response....
>
> > Setting `certificateVerification="require"` on your Connector
>
> I changed
> `certificateVerification="REQUIRED"
> to
> `certificateVerification="require"`
>
> still not seeing any OCSP calls in wireshark for this
>
> I did find out how to enable logging better (by adding either of these to
> logging.properties):
> org.apache.tomcat.util.net.openssl.level=ALL
> org.apache.tomcat.util.net.level=ALL
>
> and I can see logs confirming that the trust store is being used:
> OpenSSLContext.init Added client CA cert:...) ;
>
> with logging set to org.apache.tomcat.level=ALL
> I see confirmation that the certificateVerification is being parsed,
> apparently correctly.
>
> but I still don't see any evidence in the tomcat/catlina logs or in
> wireshark that anything is happening to accomplish this.
>
>
>
> On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland <cs...@apache.org>
> wrote:
>
>> Hi,
>>
>> On Mon, Apr 1, 2019 at 3:30 PM John Palmer <jo...@gmail.com> wrote:
>>
>> > What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
>> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
>> > 8.5.38 using Openssl ?
>>
>>
>> Setting `certificateVerification="require"` on your Connector and using a
>> client certificate that has an OCSP URI should be it. See
>>
>> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
>> for more information on how to configure it.
>>
>>
>> >
>>
>>
>> > I'm sure I'm missing something simple and obvious (once pointed out) but
>> > I've been struggling with this all morning).
>> >
>> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w
>> OCSP
>> > support - the X64 dll from
>> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
>> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
>> >
>>
>> It will work, but only if you're using the openssl implementation.
>>
>>
>> > (i'd prefer to have this working with OpenSSl for a couple of reasons).
>> > (extra points for a configuration to allow it to use Axways (formerly
>> > Tumbleweed) Desktop Validator for its OCSP-caching features).
>> >
>> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
>> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
>> > options for the tomat service).
>> >
>> >
>> > I can't see anything indicating OCSP checks in the logs for either.
>> >
>>
>> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
>> anything when it's in use, so there's not much indication that it's
>> working
>> there.
>>
>>
>> >
>> > (when the tc-native-1.dll is present, the logs show it being used:
>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
>> > [1.6.5].
>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>> > APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
>> > random [true].
>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
>> > OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
>> > INFO [main]
>> > org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
>> > The ["https-openssl-nio2-192.168.1.16-443"] connector has been
>> configured
>> > to support negotiation to [h2] via ALPN
>> > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
>> > ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
>> > )
>> >
>> >
>> > for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
>> > tomcat service I see logging for key & trust stores being loaded, etc.
>> in
>> > tomcat8-stdout(date).log
>> > the server requesting a client cert, the Client cert being received and
>> > finding a trusted root for it ("Found trusted certificate:"),
>> > but nothing about revocation checking....
>> > (I do see:
>> > check handshake state: certificate_verify[15]
>> > update handshake state: certificate_verify[15]
>> >
>> > but I'm not sure that's revocation checking...).
>> >
>> > for OpenSLL, I'mnot sure how to enable equivalent logging....by enabling
>> > pretty much ALL the logging
>> > org.apache.coyote.http2.level=ALL
>> > org.apache.level=ALL
>> > org.apache.catalina.session.level=ALL
>> > I can see the truststore ("Added client CA cert") being loaded but not
>> much
>> > else about certificates.
>> >
>> >
>> > Wireshark shows me OCSP calls for the SERVER cert, presumable from the
>> > browswer (fireFox).
>> > (I'm testing this on a personal computer, tomcat and browser on the same
>> > computer).
>> > If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing
>> > them.
>> >
>> >
>> > the Connector part of the server xml.config file is (ip address and
>> server
>> > name etc removed):
>> >
>> > <Connector
>> > address="a.b.c.d"
>> > port="443"
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> > maxThreads="150"
>> > SSLEnabled="true"
>> > scheme="https"
>> > secure="true"
>> > >
>> > <UpgradeProtocol
>> className="org.apache.coyote.http2.Http2Protocol"
>> > />
>> > <SSLHostConfig
>> > protocols="+TLSv1.2+TLSv1.3"
>> > honorCipherOrder="true"
>> > certificateVerification="REQUIRED"
>> > truststoreFile="C:/certs/trustStore.pfx"
>> > truststoreType="PKCS12"
>> > truststorePassword="abcdef"
>> > >
>> > <Certificate
>> > certificateKeystoreFile="C:/certs/(server).pfx"
>> > certificateKeystoreType="PKCS12"
>> > certificateKeystorePassword="abcdef"
>> > />
>> > </SSLHostConfig>
>> > </Connector>
>> >
>>
>
Re: how to enable OCSP for Tomcat w OpenSSL
Posted by John Palmer <jo...@gmail.com>.
I appreciate your response....
> Setting `certificateVerification="require"` on your Connector
I changed
`certificateVerification="REQUIRED"
to
`certificateVerification="require"`
still not seeing any OCSP calls in wireshark for this
I did find out how to enable logging better (by adding either of these to
logging.properties):
org.apache.tomcat.util.net.openssl.level=ALL
org.apache.tomcat.util.net.level=ALL
and I can see logs confirming that the trust store is being used:
OpenSSLContext.init Added client CA cert:...) ;
with logging set to org.apache.tomcat.level=ALL
I see confirmation that the certificateVerification is being parsed,
apparently correctly.
but I still don't see any evidence in the tomcat/catlina logs or in
wireshark that anything is happening to accomplish this.
On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland <cs...@apache.org> wrote:
> Hi,
>
> On Mon, Apr 1, 2019 at 3:30 PM John Palmer <jo...@gmail.com> wrote:
>
> > What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
> > 8.5.38 using Openssl ?
>
>
> Setting `certificateVerification="require"` on your Connector and using a
> client certificate that has an OCSP URI should be it. See
>
> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
> for more information on how to configure it.
>
>
> >
>
>
> > I'm sure I'm missing something simple and obvious (once pointed out) but
> > I've been struggling with this all morning).
> >
> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
> > support - the X64 dll from
> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
> >
>
> It will work, but only if you're using the openssl implementation.
>
>
> > (i'd prefer to have this working with OpenSSl for a couple of reasons).
> > (extra points for a configuration to allow it to use Axways (formerly
> > Tumbleweed) Desktop Validator for its OCSP-caching features).
> >
> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
> > options for the tomat service).
> >
> >
> > I can't see anything indicating OCSP checks in the logs for either.
> >
>
> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
> anything when it's in use, so there's not much indication that it's working
> there.
>
>
> >
> > (when the tc-native-1.dll is present, the logs show it being used:
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
> > [1.6.5].
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
> > random [true].
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
> > OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
> > INFO [main]
> > org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> > The ["https-openssl-nio2-192.168.1.16-443"] connector has been configured
> > to support negotiation to [h2] via ALPN
> > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
> > ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
> > )
> >
> >
> > for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
> > tomcat service I see logging for key & trust stores being loaded, etc. in
> > tomcat8-stdout(date).log
> > the server requesting a client cert, the Client cert being received and
> > finding a trusted root for it ("Found trusted certificate:"),
> > but nothing about revocation checking....
> > (I do see:
> > check handshake state: certificate_verify[15]
> > update handshake state: certificate_verify[15]
> >
> > but I'm not sure that's revocation checking...).
> >
> > for OpenSLL, I'mnot sure how to enable equivalent logging....by enabling
> > pretty much ALL the logging
> > org.apache.coyote.http2.level=ALL
> > org.apache.level=ALL
> > org.apache.catalina.session.level=ALL
> > I can see the truststore ("Added client CA cert") being loaded but not
> much
> > else about certificates.
> >
> >
> > Wireshark shows me OCSP calls for the SERVER cert, presumable from the
> > browswer (fireFox).
> > (I'm testing this on a personal computer, tomcat and browser on the same
> > computer).
> > If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing
> > them.
> >
> >
> > the Connector part of the server xml.config file is (ip address and
> server
> > name etc removed):
> >
> > <Connector
> > address="a.b.c.d"
> > port="443"
> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > maxThreads="150"
> > SSLEnabled="true"
> > scheme="https"
> > secure="true"
> > >
> > <UpgradeProtocol
> className="org.apache.coyote.http2.Http2Protocol"
> > />
> > <SSLHostConfig
> > protocols="+TLSv1.2+TLSv1.3"
> > honorCipherOrder="true"
> > certificateVerification="REQUIRED"
> > truststoreFile="C:/certs/trustStore.pfx"
> > truststoreType="PKCS12"
> > truststorePassword="abcdef"
> > >
> > <Certificate
> > certificateKeystoreFile="C:/certs/(server).pfx"
> > certificateKeystoreType="PKCS12"
> > certificateKeystorePassword="abcdef"
> > />
> > </SSLHostConfig>
> > </Connector>
> >
>
Re: how to enable OCSP for Tomcat w OpenSSL
Posted by Coty Sutherland <cs...@apache.org>.
Hi,
On Mon, Apr 1, 2019 at 3:30 PM John Palmer <jo...@gmail.com> wrote:
> What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
> tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
> 8.5.38 using Openssl ?
Setting `certificateVerification="require"` on your Connector and using a
client certificate that has an OCSP URI should be it. See
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
for more information on how to configure it.
>
> I'm sure I'm missing something simple and obvious (once pointed out) but
> I've been struggling with this all morning).
>
> 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
> support - the X64 dll from
> tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
> (will this even work with NIO2 ? - I don't HAVE to use NIO2)
>
It will work, but only if you're using the openssl implementation.
> (i'd prefer to have this working with OpenSSl for a couple of reasons).
> (extra points for a configuration to allow it to use Axways (formerly
> Tumbleweed) Desktop Validator for its OCSP-caching features).
>
> 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
> (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
> options for the tomat service).
>
>
> I can't see anything indicating OCSP checks in the logs for either.
>
There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
anything when it's in use, so there's not much indication that it's working
there.
>
> (when the tc-native-1.dll is present, the logs show it being used:
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
> [1.6.5].
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
> random [true].
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
> OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018]
> INFO [main]
> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> The ["https-openssl-nio2-192.168.1.16-443"] connector has been configured
> to support negotiation to [h2] via ALPN
> INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
> ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
> )
>
>
> for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
> tomcat service I see logging for key & trust stores being loaded, etc. in
> tomcat8-stdout(date).log
> the server requesting a client cert, the Client cert being received and
> finding a trusted root for it ("Found trusted certificate:"),
> but nothing about revocation checking....
> (I do see:
> check handshake state: certificate_verify[15]
> update handshake state: certificate_verify[15]
>
> but I'm not sure that's revocation checking...).
>
> for OpenSLL, I'mnot sure how to enable equivalent logging....by enabling
> pretty much ALL the logging
> org.apache.coyote.http2.level=ALL
> org.apache.level=ALL
> org.apache.catalina.session.level=ALL
> I can see the truststore ("Added client CA cert") being loaded but not much
> else about certificates.
>
>
> Wireshark shows me OCSP calls for the SERVER cert, presumable from the
> browswer (fireFox).
> (I'm testing this on a personal computer, tomcat and browser on the same
> computer).
> If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing
> them.
>
>
> the Connector part of the server xml.config file is (ip address and server
> name etc removed):
>
> <Connector
> address="a.b.c.d"
> port="443"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> maxThreads="150"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> >
> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
> />
> <SSLHostConfig
> protocols="+TLSv1.2+TLSv1.3"
> honorCipherOrder="true"
> certificateVerification="REQUIRED"
> truststoreFile="C:/certs/trustStore.pfx"
> truststoreType="PKCS12"
> truststorePassword="abcdef"
> >
> <Certificate
> certificateKeystoreFile="C:/certs/(server).pfx"
> certificateKeystoreType="PKCS12"
> certificateKeystorePassword="abcdef"
> />
> </SSLHostConfig>
> </Connector>
>