Are you running Tomcat with HTTPS and still wondering if you are actually safe?
Plenty of teams have flipped the switch on SSL in Tomcat 6 and called it a day. The padlock shows up, the boss smiles, and traffic looks scrambled in the sniffer. But that default setup often leaves old protocols on, weak ciphers available, leaky headers exposed, and cookies that tell a little too much. If you are serving real users, or just want to keep your test data from ending up in someone else’s laptop, you want stronger TLS and headers than the out of the box defaults.
Let’s make this practical and keep it friendly.
Why bother hardening TLS on Tomcat if it already works?
Because “works” is not the same as “safe.” Old clients will try to use weak algorithms. Some SSL stacks still offer export grade ciphers. Many deployments leave SSLv2 reachable, which is basically a welcome mat for anyone with a script. On top of that, modern browsers prefer better suites when you make them available, and Java 6 with the right policy files can speak AES without breaking a sweat. Turning the right knobs gives you stronger crypto, fewer downgrade risks, and a better posture with almost no visible change to users.
It also makes audits much less awkward.
JSSE or APR with OpenSSL, which one should you pick?
Tomcat can secure traffic through the standard JSSE path or through the native APR layer that hooks to OpenSSL. JSSE keeps everything inside the JVM and is usually simpler. APR can give you better performance and a broader set of ciphers because you lean on the system OpenSSL. If you already ship a native stack or you are comfortable managing OpenSSL files and paths, APR is a solid choice. If you want fewer moving parts and a quick win, JSSE is fine. Either way, aim for the same goals: modern protocol selection, a sane cipher list, and clean certificate handling.
Pick one and tune it, not both at once.
Certificates and keystores that will not bite you
The basics still get teams. For JSSE, you store your private key and server certificate in a JKS or PKCS12 keystore. PKCS12 makes it easier to import material that came from OpenSSL. Go with RSA 2048 keys, sign with SHA1 not MD5, and keep your private material offline except when you load the server. If your CA gave you an intermediate, do not forget to include the chain. Browsers without the intermediate in their store will throw warnings and your help desk will hear about it. On APR, point Tomcat at the certificate file, the private key file, and the chain file. Same rules on key size and chain order apply.
Self signed is fine for dev, not for production.
Turn off the fossils
Make sure the connector does not speak SSLv2. Prefer TLSv1 and if you must, allow SSLv3 only for older clients. Drop anything labeled EXPORT. Drop anything that says NULL or ANON. Keep AES suites first if your Java has the Unlimited Strength policy files installed. Three DES is acceptable as a compatibility backup. RC4 is still common and fast today, though keep it behind AES in your preference list. The exact syntax depends on JSSE vs APR, but the idea is the same. Fewer choices, better choices, and a clear order.
Your future self will thank you.
Mutual TLS when passwords are not enough
If your app is internal, or you deal with partners that can manage certificates, client auth is a powerful layer. Set the connector to request or require client certificates and point Tomcat to a trust store that holds the issuing CA. Map the subject to an application user on login, and you get strong identity with no password reuse. It is not for public sites, and the onboarding cost is real, but for sensitive consoles and B2B endpoints it can replace shared secrets and it makes phishing attacks a lot less interesting.
Keep revocation in mind, plan who can issue and who can kill a cert.
Headers that help today
Start with the easy wins. For pages behind login, send Cache-Control: no-store and Pragma: no-cache and set an Expires date in the past. This keeps browsers from writing sensitive pages to disk. For file downloads you want to cache, set explicit max age. Cookies that hold session IDs should carry the Secure flag and the HttpOnly flag. HttpOnly has been around for a while and cuts off simple script access to cookies. It is not magic, but it removes one path for stolen sessions.
If you test with the IE8 beta that just landed, you can add X-Content-Type-Options: nosniff to stop type guessing on downloads. Early content filters that try to block script can be toggled with X-XSS-Protection on that browser family too. These are still settling, so keep them on your radar and test before turning them on for everyone. If your app lives inside iframes and has cookie trouble with older IE, a simple P3P header can help with third party cookie prompts. It is old tech, but it avoids support tickets.
Small headers carry big weight.
Tomcat knobs that leak less
Reduce what you tell the world. Make sure the connector does not add the X-Powered-By header. Tomcat can also expose its flavor in the Server banner, which often reads Apache Coyote. The cleanest fix is to put Apache httpd or a smart proxy in front and set your own server string. Customize error pages so users do not see stack traces or the default Tomcat cat when something goes wrong. Turn off directory listings on static paths. Stop Tomcat from adding the session ID to URLs by forcing cookie based sessions and rejecting URL rewriting. Longer random session IDs are cheap protection, so keep them long and make them secure only.
Silent servers are harder to poke.
Force HTTPS every time
Users will bookmark whatever they see first. If that is HTTP, your session might hop across the wire in clear text before a redirect kicks in. Define a security constraint in your web descriptor with a transport set to confidential for the paths that matter, usually the whole app. If you run httpd in front, redirect every clear request to HTTPS right away and keep cookies scoped to secure. The idea is simple, no one rides without a seatbelt.
One redirect at the door is better than mixed behavior.
Performance notes that keep users happy
Crypto got faster with current hardware and the JVM keeps getting better. With keep alive on and session reuse enabled, handshake cost drops a lot. Offload if you must, but for many apps Tomcat can carry HTTPS itself just fine. Turn on gzip for text content to save bandwidth, and test your biggest pages with and without it. Watch your access logs and your GC logs under load to make sure you do not hit pauses from big bursts of handshakes. If you choose APR, match your OpenSSL version with your system libraries and test package updates in a staging box first. Surprises on crypto libraries make very long nights.
Measure first, then tweak.
Quick checklist for hardening Tomcat TLS and headers
- Disable SSLv2 and prefer TLSv1. Keep SSLv3 only if you need it for legacy clients.
- Drop EXPORT, NULL, and anonymous ciphers. Put AES suites first, 3DES as backup.
- Use RSA 2048 keys with SHA1 and include the full certificate chain.
- Pick JSSE or APR and tune it. Do not run both for the same connector.
- Secure cookies with Secure and HttpOnly flags. Avoid putting session IDs in URLs.
- Cache rules for private pages: Cache Control no store, Pragma no cache, past Expires.
- Optional modern headers: X Content Type Options nosniff for IE8 tests, P3P if you need third party cookies in old IE.
- Hide banners. No X Powered By, mask or rewrite the Server header, custom error pages.
- Force HTTPS via security constraints or a front end redirect. Keep one clear rule.
- Test with multiple browsers and a network sniffer to verify protocol and ciphers used.
None of this requires fancy tools or a rewrite, it is about choosing strong defaults and trimming noisy details. The big wins come from closing the old doors and announcing less about your stack. Tomcat gives you the switches, and today’s browsers can handle the safer choices. Set aside an afternoon, follow the checklist, and ship with confidence.
Security grows from simple choices made early and kept consistent.