Tomcat expects certificates in a Java KeyStore (JKS) format rather than the PEM format most CAs issue by default, which means a conversion step is usually needed before installation.
Converting and importing
keytool -importkeystore -srckeystore yourcert.p12 -srcstoretype PKCS12 \
-destkeystore keystore.jks -deststoretype JKSIf you don't already have a PKCS12 (.p12/.pfx) file, generate one from your PEM certificate and key with OpenSSL first (openssl pkcs12 -export ...), then convert that into a JKS keystore as shown.
Configuring Tomcat to use it
In server.xml, configure the HTTPS connector to reference your keystore file path, keystore password, and the correct key alias — Tomcat won't discover the keystore automatically, and a mismatched password or alias here is the most common cause of a Tomcat instance failing to start after adding SSL configuration.
What to do if Tomcat fails to start after adding your certificate configuration
A Tomcat startup failure after adding SSL configuration is most commonly caused by an incorrect keystore path, a wrong keystore password, or a malformed connector configuration in server.xml — checking Tomcat's own catalina.out log file typically shows the specific underlying error clearly.
How Tomcat's keystore-based approach differs from Apache and Nginx's file-based certificates
Tomcat stores certificates within a Java KeyStore (JKS) file rather than referencing separate PEM certificate and key files the way Apache and Nginx do — this means importing a certificate obtained elsewhere into Tomcat typically requires converting it into JKS format first, using the keytool utility bundled with Java.
What keytool commands are needed to import a certificate obtained from a public CA
Importing a CA-issued certificate into a Java keystore requires first importing the CA's root and intermediate certificates, then importing your own certificate, using keytool's -import flag with the -alias matching whatever alias was used when the original keystore and CSR were generated.
How Tomcat's connector configuration differs between older and newer major versions
Tomcat 8.5 and later support a simplified SSL configuration directly in server.xml without requiring the older, more verbose SSLHostConfig syntax some earlier documentation still references — checking your specific Tomcat version against current official documentation avoids following an outdated configuration pattern.
Why placing Tomcat behind a reverse proxy is common practice for production HTTPS
Many production Tomcat deployments place Nginx or Apache in front as a reverse proxy handling TLS termination, letting Tomcat itself run plain HTTP internally — this offloads certificate management to more commonly used, better-documented tooling while still benefiting from Tomcat's Java application capabilities.
What Tomcat version-specific documentation differences mean for following this guide accurately
Given how much Tomcat's SSL configuration syntax has evolved across major versions, always cross-referencing the specific configuration syntax against Apache's official documentation for your exact installed version avoids applying outdated guidance that might not match your specific Tomcat version's expected format.
How to verify Tomcat is in practice serving your certificate correctly after configuration
Connecting immediately to your Tomcat server's HTTPS port with OpenSSL's s_client, the same technique used throughout this site, confirms the certificate is in fact being served correctly rather than assuming a successful Tomcat startup alone means the SSL configuration is functioning as intended.
A closing note on when placing Tomcat behind a reverse proxy makes more sense than direct configuration
For most production deployments, placing Nginx or Apache in front of Tomcat to handle TLS termination, rather than configuring Tomcat's own SSL outright as covered in this guide, is increasingly the more common and often simpler approach — worth considering as an alternative if you're setting up a new deployment from scratch.
Loading comments…