TLS/SSL Configuration

Server authenticates to clients; clients present no certificate.

Add a truststore holding the client certificates you trust, or the CA certificate that issues them, and require client authentication. A certificate issued by a CA is also checked for revocation; see Client certificate revocation.

With clientAuthenticationRequired, a client certificate issued by a CA in the truststore is also checked for revocation, using the sources named in the certificate itself: its OCSP responder (Authority Information Access) first, then its CRL distribution point if OCSP gives no answer. No JVM flags are needed. The check fails closed: the client is rejected when the certificate names no revocation source, when no source can be reached, or when one lists the certificate as revoked. A certificate placed directly in the truststore is trusted as is; it is not checked.

The check runs during the TLS handshake, so the server must be able to reach the OCSP responder or CRL distribution point. One that does not answer holds that client’s handshake until the JDK gives up: 15 seconds each to connect and to read, for OCSP and then again for the CRL. To shorten that, set -Dcom.sun.security.ocsp.timeout, -Dcom.sun.security.ocsp.readtimeout, -Dcom.sun.security.crl.timeout and -Dcom.sun.security.crl.readtimeout (in seconds). Only certificates issued by a CA in the truststore reach this check: a certificate the server cannot verify is rejected without any fetch.

If your CA publishes no CRL or OCSP responder, or the server cannot reach it, turn the check off. This is often the case for CAs that issue short-lived, automatically rotated certificates, such as cert-manager or SPIFFE/SPIRE, which rely on the short lifetime instead of revocation: with the check on, every client is rejected. With the check off, revoking a client means removing its certificate (or its CA) from the truststore, or letting a short-lived certificate expire:

The client sees only certificate_unknown; the server logs the reason at INFO (logger org.apache.tika.server.core.ClientCertificateTrustManager), for example client certificate rejected: CN=client-1: Certificate has been revoked.

Tika does not set TLS protocol or cipher suite policy; the JVM does. By default the server offers what the JVM enables (TLS 1.2 and 1.3 on current JDKs), minus Jetty’s weak-suite exclusions. To restrict it, set the JVM’s own properties when starting the server — for example, TLS 1.3 only:

An explicit allowlist of cipher suites:

In a container, put the flags in JAVA_TOOL_OPTIONS. The jdk.tls.server.* properties apply only where Java is the TLS server, so outbound HTTPS from fetchers and parsers is unaffected. The reverse does not hold: jdk.tls.client.protocols restricts the server too, since Jetty starts from the JVM’s client-side protocol defaults, so the server offers only protocols both properties allow. To ban an algorithm everywhere, client side included, edit jdk.tls.disabledAlgorithms in the JDK’s java.security.

Jetty’s weak-suite exclusions apply on top of jdk.tls.server.cipherSuites: a listed suite whose name ends in _SHA, _SHA1 or _MD5, or starts with TLS_RSA_ or SSL_, or contains _NULL_ or _anon_, is dropped without a warning.

Write the passwords as ${env:NAME} (as in the examples above) and pass them in the environment, so the config file holds no secret. Tika expands ${env:NAME} anywhere in the startup config; a variable that is not set stops startup (Secrets from the environment). Nothing else is expanded: there is no form that reads a file such as /run/secrets/…​. For a secret mounted as a file, export it into the environment in your own entrypoint script.