Confluence Server and External API TLS Certificate Truststore Integration

Question

Confirm whether Confluence Server or Data Center validates outbound TLS connections to external APIs using the JRE cacerts truststore, the operating system certificate store, or both. The integration boundary involves Confluence initiating HTTPS requests to a third-party service while the Base URL setting may resolve to a different hostname internally than externally.

Confluence inherits host DNS configuration from the underlying operating system, and the JVM may cache DNS records according to networkaddress.cache.ttl. Certificate failures typically appear as SSLHandshakeException or PKIX path building failed messages, but it is unclear which truststore entry governs the hostname check when internal loopback resolution differs from the public DNS record.

Which truststore does Confluence consult for outbound certificate validation? Is the certificate hostname verified against the Base URL value, the resolved IP address, or the external DNS name? Does a DNS TTL change require restarting Confluence to take effect for existing application links?

Tasadduq Burney · Answer

Outbound TLS Validation MechanismConfluence Server and Data Center validate outbound TLS connections using the JRE cacerts truststore by default. They do not natively consult the operating system certificate store unless specific custom security providers are configured in the JVM arguments. When Confluence initiates an HTTPS request to an external API, the Java Virtual Machine (JVM) relies on its internal trust store to verify the certificate chain.

Hostname Verification and DNS Resolution
p>The certificate hostname is verified against the external DNS name resolved during the request, not the Confluence Base URL value itself. If the Base URL resolves to an internal IP that differs from the public DNS record, the TLS handshake may fail unless the certificate's Subject Alternative Name (SAN) or Common Name (CN) explicitly includes the internal hostname.

Truststore: The JRE cacerts (typically at $JAVA_HOME/lib/security/cacerts) is the source of truth for trusted CAs.
  Hostname Check: The JVM compares the hostname of the request URL against the identities presented in the TLS certificate.
  DNS Caching: The JVM caches DNS records based on the networkaddress.cache.ttl property defined in java.security.

TTL and Connection Persistence
A DNS TTL change does not necessarily require a restart of Confluence to take effect for existing application links, but it depends on the networkaddress.cache.ttl setting. If the TTL is set to -1 (infinite), a restart is required to clear the cache. If set to a finite value, the JVM will refresh the record automatically after the duration expires.

Verification Steps
To confirm which truststore Confluence is using, check the startup scripts for the following JVM argument:
ps -ef | grep jjavax.net.ssl.trustStore
If this flag is absent, Confluence is using the default JRE cacerts. To diagnose handshake failures, you can enable SSL debugging by adding the following flag to your CATALINA_OPTS:
-Djavax.net.debug=ssl,handshake

Confluence Server and External API TLS Certificate Truststore Integration

1 answer

Outbound TLS Validation Mechanism

Hostname Verification and DNS Resolution

TTL and Connection Persistence

Your perspective belongs here.

0 question comments