Forcing HTTPS on a Java application is one of the simplest ways to improve security, meet browser expectations, and avoid mixed-content issues. In a managed hosting environment, the right approach depends on where your Java app is running: behind Apache in Plesk, inside a Tomcat-based setup, or on a private JVM managed through a control panel extension such as My App Server.
In most cases, you should do two things: configure a valid SSL certificate for the domain and redirect all HTTP traffic to HTTPS. If your application is behind a reverse proxy or Apache, the redirect is usually handled at the web server level. If your app listens directly on a Java/Tomcat port, you may also need to enforce HTTPS in the application itself or through the container configuration.
Why HTTPS matters for Java hosting
HTTPS protects login forms, session cookies, personal data, and API calls between the visitor and your application. It also helps with trust and compatibility, because modern browsers mark non-HTTPS pages as not secure, especially when they collect sensitive information.
For Java hosting, HTTPS is particularly important when you run:
- JSP sites with login pages or user accounts
- Servlet applications that handle forms or sessions
- WAR deployments running on Tomcat
- Applications integrated with third-party payment or authentication services
- Any public-facing app using cookies, tokens, or redirects
If you use a control panel such as Plesk with a Java hosting extension, HTTPS is usually best handled in a layered way: certificate on the domain, redirect at Apache or proxy level, and application settings adjusted so links, cookies, and generated URLs use secure access.
Before you force HTTPS
Make sure these basics are in place first:
- Your domain resolves correctly to the hosting account.
- An SSL/TLS certificate is installed for the domain.
- Your Java application is reachable over HTTP and works normally.
- You know whether traffic reaches the app directly, via Apache, or through a proxy.
In a Plesk-based environment, a typical setup for Java hosting may include Apache on the front end and a private Tomcat or JVM instance behind it. That means the browser connects to Apache on standard ports 80 and 443, while Apache forwards requests internally to the Java application. This is the most practical setup for forcing HTTPS because the redirect can happen before the request reaches your app.
Recommended approach in a managed hosting environment
The most reliable method is:
- Install or assign an SSL certificate for the domain.
- Redirect all HTTP requests to HTTPS at the web server or proxy level.
- Update the Java application so it understands secure requests correctly.
- Test for mixed content and redirect loops.
If you are using a My App Server-style Java hosting service, the goal is not to build a complex enterprise security stack. Instead, the aim is to make sure the public URL always uses HTTPS, while the Java runtime and Apache/Tomcat configuration stay simple and manageable through the hosting panel.
How to force HTTPS on Apache in front of Java
If Apache is serving the domain, this is often the cleanest place to enforce HTTPS. The redirect can be added in the virtual host configuration or, in some hosting panels, through domain-level Apache directives.
Redirect all HTTP traffic to HTTPS
A common Apache rule looks like this:
<VirtualHost *:80>
ServerName example.co.uk
ServerAlias www.example.co.uk
Redirect permanent / https://example.co.uk/
</VirtualHost>
If you need more flexible rewrite logic, you can use mod_rewrite:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Use one approach consistently. Do not combine multiple redirects in different places unless you are sure they will not conflict.
Why Apache-level redirect is preferred
- The browser is redirected before reaching the Java app.
- You avoid duplicating logic inside the application.
- It works well for multiple apps or paths under the same domain.
- It reduces the chance of application-level redirect loops.
In a hosting platform where the Java app runs as a private service, Apache can remain the public entry point while Tomcat handles application logic behind the scenes. That keeps HTTPS enforcement easier to maintain.
Forcing HTTPS in Tomcat-based Java applications
If your Java app is served directly by Tomcat or uses Tomcat-style connectors, you may need to configure the application server to treat requests as secure. In many hosting setups, though, Tomcat is not exposed directly to the internet; Apache or another front-end server handles HTTPS and forwards the request internally.
Set the secure connector attributes correctly
When Tomcat sits behind a proxy, it often needs to know that the original request was HTTPS. Otherwise, generated redirects, absolute URLs, or security checks may behave incorrectly.
Typical connector attributes include:
<Connector port="8080"
protocol="HTTP/1.1"
proxyName="example.co.uk"
proxyPort="443"
scheme="https"
secure="true" />
This tells Tomcat to generate secure URLs and understand that the external request should be treated as HTTPS, even if the internal connection from Apache to Tomcat uses plain HTTP.
Enable redirect inside the application if needed
Some Java frameworks support forced HTTPS through filters, interceptors, or security configuration. This is useful when the application must guarantee HTTPS even if it is moved between hosting environments.
Examples of where this can be done include:
- Spring Security redirect rules
- Servlet filters checking request scheme
- Framework-level URL generation settings
- Session cookie configuration for secure transport
However, in a managed hosting setup, server-level redirect is usually more reliable and easier to maintain than application-only enforcement.
How to force HTTPS in My App Server / Plesk hosting
If your Java application is deployed through a hosting control panel such as Plesk with a Java extension, the workflow is usually straightforward. You install the certificate for the domain, then apply a redirect so all visitors use HTTPS.
Typical checklist in the control panel
- Open the domain in the hosting panel.
- Check that the SSL certificate is valid and assigned to the site.
- Enable permanent HTTP to HTTPS redirection if the panel offers it.
- Confirm that the Java application is still accessible through the secure URL.
- Test login pages, forms, and redirects.
In a My App Server setup, the Java side can run as a private JVM or Tomcat instance, while the public access layer is handled by the web server configuration. This separation is useful because the HTTPS redirect can be managed centrally without changing the WAR file every time the domain or certificate changes.
When to update the Java app itself
Even if the redirect is handled by Apache or Plesk, your Java application may still need small changes:
- Use HTTPS in hardcoded links and canonical URLs.
- Set secure cookies where the app handles authentication.
- Ensure callback URLs from payment or login services use https://.
- Make sure the application does not generate absolute HTTP links.
How to avoid redirect loops
Redirect loops are a common problem when forcing HTTPS in a Java hosting environment. They usually happen when both the reverse proxy and the application try to redirect the same request, or when the app does not correctly detect that the original browser request was already HTTPS.
Common causes
- Apache redirects to HTTPS, but Tomcat thinks the request is still HTTP.
- The app redirects all requests without checking proxy headers or connector settings.
- Multiple rules exist in .htaccess, Apache config, and the Java app.
- The load balancer or proxy strips the original scheme information.
How to fix them
- Use one main redirect layer, preferably Apache or the front-end proxy.
- Configure Tomcat with the correct proxyName, proxyPort, scheme, and secure settings.
- Check whether the application is behind another proxy or CDN.
- Remove duplicate redirect logic from the Java code if the server already handles it.
If your hosting platform gives you control of Apache, start there. If the redirect still behaves incorrectly, inspect how your Java service is published internally and whether the application needs proxy awareness.
Forcing HTTPS with .htaccess
If your hosting account allows .htaccess overrides and Apache is the front end, you can use a simple rule to force HTTPS. This is often suitable for smaller Java applications running under a domain or subdirectory, especially when the app is delivered through Apache and forwarded to Tomcat.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Use this only if your Apache configuration allows it and if the request truly reaches Apache before the Java app. In many Java hosting setups, that is exactly the right layer for the redirect.
Handling application URLs after the redirect
Redirecting to HTTPS is only part of the job. Your Java application should also consistently generate secure URLs so users do not bounce between HTTP and HTTPS.
Check these areas in the application
- Navigation menus and hardcoded links
- Form actions
- Authentication and logout URLs
- External callbacks and webhook endpoints
- SEO tags such as canonical URLs and sitemap links
If your app uses a framework, review its base URL or public URL setting. In many cases, the app should be configured with the HTTPS domain explicitly so that generated links stay secure.
Set secure cookies
If the application stores sessions in cookies, mark them as secure so the browser only sends them over HTTPS. This is important for login systems and any app with user accounts.
Depending on the framework or servlet settings, you may also want to use HttpOnly and SameSite attributes to improve session security. These are not a replacement for HTTPS, but they work well with it.
Mixed content: the issue after HTTPS is enabled
Once HTTPS is forced, the most common remaining issue is mixed content. This happens when the page loads securely over HTTPS but still references images, scripts, stylesheets, or API calls over HTTP.
What to look for
- Hardcoded http:// links in templates
- JavaScript fetching API endpoints using HTTP
- Images loaded from old absolute URLs
- Stylesheets or fonts referenced through non-secure addresses
How to fix it
- Replace http:// with https:// where the resource supports it.
- Use relative URLs when possible.
- Update environment variables or application base settings.
- Rebuild or redeploy the app if templates are packaged in the WAR.
In public-facing Java hosting, mixed content is one of the main reasons a site still appears broken after SSL is installed. The redirect itself may work fine, but browser warnings can remain until all asset URLs are corrected.
Testing your HTTPS setup
After you apply the redirect, test the domain carefully from a browser and, if possible, with command-line tools.
Manual checks
- Open the HTTP version of the site and confirm it moves to HTTPS.
- Check the login page, signup page, and other sensitive screens.
- Verify the lock icon and certificate details in the browser.
- Reload the page and confirm there are no mixed-content warnings.
Technical checks
- Confirm the redirect uses a 301 status for permanent enforcement.
- Check that only one redirect is applied.
- Inspect response headers if your app sets cookies or security headers.
- Test any third-party callback URLs configured in the app.
If you are using Tomcat behind Apache, also verify that the application receives the correct scheme and port values. Incorrect proxy settings can cause logout issues, bad redirects, or insecure URL generation.
Example setup for a Java app behind Apache and Tomcat
A practical hosting pattern looks like this:
- The domain points to the hosting account.
- Apache serves ports 80 and 443.
- SSL is enabled for the domain.
- HTTP requests are redirected to HTTPS.
- Apache forwards the secure request to a private Tomcat or JVM service.
- The Java app generates URLs using the secure public domain.
This model is well suited to small and medium Java applications hosted on shared infrastructure with a private runtime. It gives you control through the panel, keeps deployment straightforward, and avoids unnecessary complexity.
Best practices for UK-facing public applications
For a UK-facing website or application, the important point is not where the application is hosted physically, but that the public experience is secure and consistent. Use a domain that matches your brand, install a valid certificate, and force HTTPS from the first request.
Recommended practices include:
- Use a single preferred host, such as www or non-www, and redirect the other version.
- Force HTTPS at the front-end layer.
- Set secure session cookies.
- Avoid hardcoded HTTP links in the Java code.
- Test all user-facing paths after deployment.
If you manage the app through a hosting control panel, document where the redirect is configured so future changes do not break it. This is especially useful when renewing certificates or moving the app to a new version of Tomcat.
FAQ
Should I force HTTPS in Apache or in the Java application?
Prefer Apache or the front-end proxy if possible. It is simpler, applies before the request reaches the app, and reduces duplicate logic. Use application-level enforcement only when you need it for specific routes or framework behavior.
Do I need to change Tomcat settings when using HTTPS?
Often yes, if Tomcat is behind a proxy. Set proxyName, proxyPort, scheme, and secure attributes so it understands the public HTTPS URL and generates correct links.
Why does my browser still show mixed content after the redirect?
Because some assets or links inside the app are still using HTTP. Update templates, scripts, API endpoints, and canonical URLs to use HTTPS or relative paths.
Can I force HTTPS with .htaccess for a Java app?
Yes, if Apache is the public entry point and .htaccess overrides are allowed. This is a common method in hosting environments where Apache forwards requests to Tomcat or a private JVM service.
What if my Java app keeps redirecting in a loop?
That usually means the proxy and the application disagree about whether the request is secure. Check your Apache rule, Tomcat connector settings, and any framework-level redirect logic.
Does HTTPS affect JSP or servlet applications differently?
The core principle is the same. The main difference is where you enforce the redirect and how the application generates secure URLs. JSP and servlet apps often rely on the container and proxy configuration more than static sites do.
Summary
To force HTTPS on a Java application, install a valid certificate, redirect HTTP to HTTPS at the front-end server or proxy, and make sure the Java runtime knows it is serving secure traffic. In a Plesk-based Java hosting environment with My App Server, this usually means configuring the domain in the panel, using Apache as the public entry point, and adjusting Tomcat or application settings only where needed.
For most small and medium Java, Tomcat, JSP, and servlet deployments, that approach is the best balance between security, maintainability, and simplicity. Once the redirect is in place, check for mixed content, session cookie settings, and correct public URLs to make sure the application behaves properly over HTTPS.