1

I'm having some issues in enabling OCSP stapling in Jetty 9 and I really hope that someone can help me here...hopefully!

For my tests I purchased an SSL certificate from PositiveSSL (Comodo), which gave me a valid/trusted certificate. The domain in this example is "dev.mydomain.com", and it will simply point to my local ip (127.0.0.1).

I then transformed the provided certificate into the Java keystore format.

# Convert certificate to pkcs12
openssl pkcs12 -export -out dev.mydomain.com.pkcs12 -inkey dev.mydomain.com.key -in dev_mydomain_com.crt

# Create java keystore
keytool -importkeystore -srckeystore dev.mydomain.com.pkcs12 -srcstoretype pkcs12 -destkeystore dev.mydomain.com.keystore -deststoretype JKS

This is the simplified Java code I used for creating the Jetty server, activate the certificate, listen on the 443 port (https), and in theory activate OCSP:

Server _server = new Server(); // org.eclipse.jetty.server.Server

HttpConfiguration httpsConfig = new HttpConfiguration();
HttpConnectionFactory http1 = new HttpConnectionFactory(httpsConfig);

SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setKeyStorePath("dev.mydomain.com.keystore");
sslContextFactory.setKeyStorePassword("mypass");
sslContextFactory.setKeyManagerPassword("mypass");

// sslContextFactory.setValidateCerts(true); // tested
sslContextFactory.setEnableOCSP(true);

SslConnectionFactory ssl = new SslConnectionFactory(sslContextFactory, http1.getProtocol());

// SSL Connector
ServerConnector sslConnector = new ServerConnector(_server, ssl, http1);

sslConnector.setHost("127.0.0.1");
sslConnector.setPort(443);

_server.addConnector(sslConnector);

_server.start();
_server.join();

On Java VM startup I'm also enabling these system properties:

Security.setProperty("ocsp.enable", "true");
System.setProperty("jdk.tls.server.enableStatusRequestExtension", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");

After several tries, I tried also importing the certificate chain into the keystore, but it didn't make any difference on the outcome.

keytool -import -trustcacerts -alias ca -file COMODORSAAddTrustCA.crt -keystore dev.mydomain.com.keystore
keytool -import -trustcacerts -alias dv -file COMODORSADomainValidationSecureServerCA.crt -keystore dev.mydomain.com.keystore
keytool -import -trustcacerts -alias te -file AddTrustExternalCARoot.crt -keystore dev.mydomain.com.keystore

To test whether OCSP was correctly enabled I used a tool called sslyze, but whatever I tried to do the response for OCSP was always negative:

OCSP Stapling - NOT SUPPORTED - Server did not send back an OCSP response

Here is the full output of sslyze:

C:\Tools\sslyze-1_4_1>sslyze --certinfo dev.mydomain.com:443


 AVAILABLE PLUGINS
 -----------------

  OpenSslCipherSuitesPlugin
  RobotPlugin
  CertificateInfoPlugin
  FallbackScsvPlugin
  SessionRenegotiationPlugin
  HeartbleedPlugin
  CompressionPlugin
  OpenSslCcsInjectionPlugin
  SessionResumptionPlugin
  HttpHeadersPlugin



 CHECKING HOST(S) AVAILABILITY
 -----------------------------

   dev.mydomain.com:443                       => 127.0.0.1




 SCAN RESULTS FOR DEV.MYDOMAIN.COM:443 - 127.0.0.1
 ------------------------------------------------

 * Certificate Information:
     Content
       SHA1 Fingerprint:                  7c398c59bac3a231efc9823c6958a7bc711bfc0e
       Common Name:                       dev.mydomain.com
       Issuer:                            COMODO RSA Domain Validation Secure Server CA
       Serial Number:                     103185809289011988533713848804380317148
       Not Before:                        2018-04-18 00:00:00
       Not After:                         2019-04-18 23:59:59
       Signature Algorithm:               sha256
       Public Key Algorithm:              RSA
       Key Size:                          2048
       Exponent:                          65537 (0x10001)
       DNS Subject Alternative Names:     ['dev.mydomain.com', 'www.dev.mydomain.com']

     Trust
       Hostname Validation:               OK - Certificate matches dev.mydomain.com
       Android CA Store (8.1.0_r9):       FAILED - Certificate is NOT Trusted: unable to get local issuer certificate
       iOS CA Store (11):                 FAILED - Certificate is NOT Trusted: unable to get local issuer certificate
       macOS CA Store (High Sierra):      FAILED - Certificate is NOT Trusted: unable to get local issuer certificate
       Mozilla CA Store (2018-01-14):     FAILED - Certificate is NOT Trusted: unable to get local issuer certificate
       Windows CA Store (2018-02-09):     FAILED - Certificate is NOT Trusted: unable to get local issuer certificate
       Symantec 2018 Deprecation:         OK - Not a Symantec-issued certificate
       Received Chain:                    dev.mydomain.com
       Verified Chain:                    ERROR - Could not build verified chain (certificate untrusted?)
       Received Chain Contains Anchor:    ERROR - Could not build verified chain (certificate untrusted?)
       Received Chain Order:              OK - Order is valid
       Verified Chain contains SHA1:      ERROR - Could not build verified chain (certificate untrusted?)

     Extensions
       OCSP Must-Staple:                  NOT SUPPORTED - Extension not found
       Certificate Transparency:          WARNING - Only 2 SCTs included but Google recommends 3 or more

     OCSP Stapling
                                          NOT SUPPORTED - Server did not send back an OCSP response


 SCAN COMPLETED IN 0.78 S
 ------------------------

Sorry for the long post, but I tried to provide as much details as possible!

Thank you! Yuvi

YuviDroid
  • 1,546
  • 11
  • 12
  • Does your certificate contain a *Authority Information Access extension (OCSPSigning)*? – Joakim Erdfelt Apr 18 '18 at 20:19
  • @JoakimErdfelt yes, it contains: Authority Info Access Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL=http://ocsp.comodoca.com – YuviDroid Apr 19 '18 at 06:56
  • Does your server have access to the OCSPSigning URL? Have you tried setting the `SslContextFactory.setOcspResponderURL()` as well? – Joakim Erdfelt Apr 19 '18 at 14:40
  • Thanks for the answer. Yes, I tried also setting manually the URL but still it was never called. I'm using my PC as server, and no outgoing connection is being blocked. :( – YuviDroid Apr 19 '18 at 16:00

1 Answers1

0

There is really not much that Jetty does with the OSCP configuration values.

The 3 key configuration values ...

1. Enable OCSP

SslContextFactory.setEnableOCSP(true)

That configuration simply sets the ocsp.enable JVM Security property.

2. Set OCSP Responder URL

SslContextFactory.setOcspResponderURL(ocspResponderURL)

If setEnableOSCP(true) and the OcspResponderURL is set, then the ocsp.responderURL JVM Security property is set.

The Jetty Code

    if (_enableOCSP)
    {
        // Enable On-Line Certificate Status Protocol (OCSP) support
        Security.setProperty("ocsp.enable", "true");

        if (_ocspResponderURL != null)
        {
            // Override location of OCSP Responder
            Security.setProperty("ocsp.responderURL", _ocspResponderURL);
        }
    }

These 2 are JVM level configurations, and at this point its the JVM's responsibility to add the OCSP stuff to the TLS/SSL negotiation.

3. Custom Certificate Validator

SslContextFactory.setValidateCerts(true)

If this is set, then the values of the other two are passed into a custom Eclipse Jetty CertificateValidator.

More Jetty Code

if (isValidateCerts())
{
    CertificateValidator validator = new CertificateValidator(trustStore, crls);
    validator.setMaxCertPathLength(getMaxCertPathLength());
    validator.setEnableCRLDP(isEnableCRLDP());
    validator.setEnableOCSP(isEnableOCSP());
    validator.setOcspResponderURL(getOcspResponderURL());
    validator.validate(keyStore, x509C);
}

This is a server side component that just validates the certificates that the server will use on startup. It only occurs once, when the keystore/truststore is loaded.

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • Now I get, "Unable to validate certificate: the trustAnchors parameter must be non-empty." which took me here: https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty but I've tried a bunch of stuff there and none of it has worked yet. – GlenPeterson Apr 14 '22 at 17:52