If your Tomcat application is public-facing, forcing HTTPS is one of the simplest ways to protect logins, sessions, form submissions, and API traffic. In a managed hosting setup with Plesk and a Java hosting extension such as My App Server, you usually want HTTPS to be enforced at the edge, before traffic reaches Tomcat. That keeps your application configuration cleaner and reduces the chance of mixed content or accidental HTTP access.
There are two common parts to the setup: first, make sure your SSL certificate is installed and working for the domain; second, redirect all HTTP requests to HTTPS so visitors always use the secure version of your site. For Tomcat apps, you can do this in Tomcat itself, in Apache, or in Plesk depending on how your hosting account is configured.
Why forcing HTTPS matters for Tomcat applications
Tomcat often serves JSP, servlet, and WAR-based applications that handle authentication, user profiles, admin panels, or payment-related data. If HTTP remains available, users may still land on an unsecured version of the site unless you deliberately redirect them. That can create security issues and inconsistent browser behaviour.
Forcing HTTPS helps you:
- protect credentials and session cookies from interception;
- avoid duplicate URLs for the same content;
- meet browser expectations for secure forms and modern web features;
- reduce mixed content warnings when the app loads assets over HTTPS;
- standardise the public URL used by your Java application.
If you are using a private JVM or Tomcat instance through a hosting control panel, the easiest and most stable approach is usually to terminate SSL on Apache or the web server layer and then forward secure traffic to Tomcat locally.
Before you add the redirect
Check the following first:
- The domain resolves correctly to your hosting account.
- An SSL certificate is installed for the domain and any relevant aliases.
- Your application loads over HTTPS without certificate warnings.
- Tomcat is serving the application correctly on the expected context path.
- You know where the redirect should be configured: Apache, Plesk, or Tomcat.
If your application is behind Apache and Tomcat is running privately, the redirect should normally happen in Apache or Plesk rather than inside Tomcat. That is the most predictable setup for hosted environments.
Recommended approach in a hosted Tomcat setup
For most shared or managed hosting accounts, the preferred pattern is:
- Install the SSL certificate for the domain.
- Make sure the website responds on port 443.
- Redirect all HTTP requests on port 80 to HTTPS.
- Ensure the application knows it is behind HTTPS if Apache proxies requests to Tomcat.
This approach works well with My App Server because you keep Tomcat focused on running the Java application, while Apache or the control panel handles public web traffic and certificate enforcement.
How to force HTTPS in Plesk
If your hosting account uses Plesk, the simplest method is usually to enable the built-in redirection option for the domain. The exact menu labels may vary, but the logic is the same.
Step 1: Confirm the SSL certificate
Open the domain settings in Plesk and confirm that an SSL certificate is assigned to the domain. If the certificate is missing, HTTPS redirection will send visitors to a secure URL that does not work correctly.
Step 2: Enable HTTPS redirect
Look for an option such as Permanent SEO-safe 301 redirect from HTTP to HTTPS, Redirect to HTTPS, or a similar checkbox in the hosting or SSL/TLS settings. Enable it and save the changes.
Step 3: Test both URLs
Open both of these in a browser:
- http://yourdomain.example
- https://yourdomain.example
The HTTP version should immediately forward to the HTTPS version with no certificate warnings.
Step 4: Check subpaths and application context
If your Java app runs under a context path such as /app or /myapp, test that the redirect preserves the path and query string. For example:
- http://yourdomain.example/myapp
- http://yourdomain.example/myapp/login
Both should end up on the HTTPS equivalent.
How to force HTTPS with Apache
If Apache is serving the public domain in front of Tomcat, you can add a redirect in the Apache vhost or the site configuration. This is a common setup in managed hosting environments because Apache handles the certificate and forwards only the necessary requests to Tomcat.
Basic Apache redirect rule
A typical redirect uses the request scheme and hostname, then sends the user to the same URL on HTTPS. In Apache configuration, the logic is usually based on a rewrite rule or a virtual host redirect.
A common pattern is:
- detect when the request is not HTTPS;
- send a 301 redirect to the same URI on https://;
- preserve the path and query string.
If you are using rewrite rules, the redirect should be placed in the HTTP virtual host or the site-level configuration, not inside the Tomcat web application, unless you have a specific reason to do so.
What the redirect should preserve
When forcing HTTPS, make sure the redirect keeps:
- the original path;
- the query string;
- the correct host name;
- any canonical domain choice, such as www or non-www.
This is important for login links, search pages, and deep links into your application.
Typical Apache considerations for Tomcat apps
If Apache proxies requests to a private Tomcat instance, the application may need to know that the original request was secure. Otherwise, it can generate insecure absolute URLs or incorrect redirects. In that case, Apache should forward the scheme correctly and Tomcat should trust the proxy headers from the local web server.
Look out for these issues:
- the app keeps redirecting between HTTP and HTTPS;
- login cookies are not marked as secure;
- generated links still point to HTTP;
- the app reports the wrong scheme or port.
How to force HTTPS inside Tomcat
In some setups, especially if Tomcat is exposed directly or you have a custom application server configuration, you may choose to handle HTTPS-related behaviour inside Tomcat. This is less common in managed hosting when Apache is in front, but it is still useful to understand.
Tomcat connector and proxy awareness
Tomcat can be configured to understand that secure traffic is being terminated elsewhere. When Apache or another front-end handles SSL, Tomcat should receive the right proxy information so that the application knows the original request was HTTPS.
That usually involves settings related to:
- proxy name;
- proxy port;
- scheme;
- secure flag;
- redirect port if relevant.
If these are not aligned, the app can create bad redirects or show mixed secure and insecure URLs.
Using web.xml security constraints
If you want to require HTTPS for specific parts of your Java application, you can use a security constraint in web.xml. This is useful for areas such as:
- admin pages;
- login endpoints;
- account management sections;
- checkout or submission forms.
This method tells Tomcat that the requested pages must be accessed securely. However, in a hosted environment, it is still usually better to combine application-level security with a server-level HTTP to HTTPS redirect.
When not to rely only on Tomcat
Using Tomcat alone to force HTTPS can be less reliable if:
- Apache is already serving the site publicly;
- the certificate is installed at the web server layer;
- multiple domains or aliases point to the same app;
- you need a simple global redirect for every request.
For most hosting accounts, the public redirect belongs in the web server or control panel, while Tomcat handles application logic.
Example setup for a My App Server Tomcat application
If you are using My App Server in a Plesk-based hosting environment, the practical workflow is usually:
- Install the Java application or Tomcat instance.
- Assign the domain and make sure it is reachable over HTTP and HTTPS.
- Install or attach the SSL certificate in the domain settings.
- Enable the HTTPS redirect in Plesk or Apache.
- Confirm that the app is aware of the secure connection if it generates links or redirects.
This setup is especially useful for JSP hosting, servlet hosting, and smaller Java applications that need a private JVM without the complexity of a full enterprise application platform.
Common My App Server benefits for HTTPS handling
- Separate JVM for the application
- Choice of Java version where available
- Managed service control through the hosting panel
- Easy deployment for WAR-based apps
- Practical proxy-based SSL termination through Apache or the control panel
That structure keeps the SSL configuration manageable while still giving you direct control over the Tomcat application itself.
Redirecting www to non-www, or the other way around
When you force HTTPS, it is a good time to decide on a canonical host name. For example, you may want all traffic to resolve to either https://example.co.uk or https://www.example.co.uk. This avoids duplicate indexing and makes certificate management simpler.
Choose one primary version and redirect all other variants to it:
- http to https;
- www to non-www, or non-www to www;
- alternate hostnames or aliases to the main URL.
Keep the redirect chain short. Ideally, a visitor should be redirected once and end up on the final secure URL.
How to avoid redirect loops
A common problem after forcing HTTPS is the redirect loop. This happens when one layer thinks the request is insecure while another layer already redirected it, or when proxy headers are not passed correctly.
Check these points first
- Do not apply the same redirect in both Apache and Tomcat unless you know the exact request flow.
- Make sure the application trusts the proxy information from Apache.
- Confirm that the site is not redirecting from HTTPS back to HTTP anywhere in the app.
- Verify that canonical host rules do not conflict with the HTTPS rule.
If you see a browser warning such as “too many redirects,” review the redirect logic layer by layer. In hosted Java environments, one redirect at the edge is usually enough.
Mixed content after enabling HTTPS
Even after HTTPS is working, your page may still load images, scripts, stylesheets, or API calls over HTTP. Browsers may block these resources or show a warning. This is common in older JSP or servlet applications that hard-code absolute URLs.
What to update
- replace hard-coded http:// asset links with relative or HTTPS URLs;
- check template files, JSP fragments, and Java-generated links;
- review third-party scripts and external widgets;
- test forms, redirects, and AJAX endpoints.
If possible, use relative URLs for internal resources. That reduces the chance of mixed content and makes future changes easier.
Testing your HTTPS redirect
After you configure the redirect, test more than just the homepage. Check a few different URL types to ensure the rule behaves correctly.
Recommended test cases
- homepage HTTP to HTTPS
- deep application page HTTP to HTTPS
- URL with query string
- login page
- static assets if they are directly linked
- canonical domain with and without www
Also test in at least one private browsing session to reduce the impact of cached redirects or old cookies.
Best practices for Tomcat apps on managed hosting
For a small or medium Java application hosted with Tomcat, the safest HTTPS setup is usually simple and explicit:
- use one main public URL;
- install a valid SSL certificate for that host name;
- redirect all HTTP traffic to HTTPS with a 301 redirect;
- configure Tomcat to respect proxy headers if Apache terminates SSL;
- keep application links relative where possible;
- test after every certificate or routing change.
This keeps your hosting environment easy to maintain and helps avoid application-level confusion about scheme, port, and host name.
FAQ
Should I force HTTPS in Apache or Tomcat?
In most hosted environments, force HTTPS in Apache or Plesk rather than in Tomcat. Tomcat should usually focus on the Java application, while the web server handles public redirects and SSL termination.
Do I need a redirect if the site already works on HTTPS?
Yes. If HTTP still loads, visitors may access the unsecured version. A redirect ensures all users are moved to the secure URL automatically.
What redirect code should I use?
Use a permanent redirect, usually 301, for a standard HTTPS migration. That is the most SEO-friendly option for public sites.
Why does my Tomcat app still generate HTTP links after enabling SSL?
Tomcat or the application may not know that SSL is being terminated by Apache or another front-end. Check the proxy settings and ensure the app is aware of the secure scheme.
Can I force HTTPS for only part of the application?
Yes. Tomcat supports HTTPS requirements for specific paths through application security rules. This is useful for login or admin sections, although a global redirect is still recommended for the public site.
What if I use a custom Java application server through My App Server?
The same principle applies. Install the certificate on the public web layer, redirect HTTP to HTTPS, and make sure the application respects the forwarded secure request details.
Conclusion
Forcing HTTPS on a Tomcat application is usually straightforward when you separate responsibilities properly. Let Apache, Plesk, or the site-level configuration handle the public redirect, then make sure Tomcat understands that secure traffic is being forwarded correctly. This is the most reliable approach for hosted Java applications, especially when using My App Server for private JVM and Tomcat hosting.
Once the redirect is in place, test the domain, the application paths, and any login or form pages. If you also clean up mixed content and choose one canonical host name, your Java application will present a consistent secure URL to users and search engines.