How to force HTTPS on a Java application

If your Java application is served over HTTP, visitors may see browser warnings, login forms can be exposed on an unencrypted connection, and search engines may index the insecure version of your site. For most Java hosting setups, the safest approach is to keep the application itself unchanged and force HTTPS at the web server or reverse proxy layer, so every request is redirected to the secure URL before it reaches Tomcat or your private JVM.

In a managed hosting environment with Plesk and a Java stack such as My App Server, this is usually the preferred method. It keeps the HTTPS rule in one place, works for WAR-based applications, JSP and servlet apps, and avoids mixing security logic into your Java code unless you specifically need application-level controls.

Why forcing HTTPS matters for Java applications

Forcing HTTPS ensures that every visitor uses the encrypted version of your application. This is especially important for:

login and session-based applications
contact forms, checkout flows, and account portals
apps that use cookies or authentication headers
any public-facing Java web application that should not be accessible over plain HTTP

When HTTPS is enforced correctly, your application benefits from:

encrypted traffic between browser and server
better user trust and fewer browser warnings
cleaner canonical URLs for SEO
fewer mixed-content issues when all resources load securely

For hosted Java applications, the redirect should normally happen in Apache, in Plesk, or in the front-end web server that passes requests to Tomcat. That is usually simpler and more reliable than trying to redirect every request from inside Java.

Recommended approach in a Plesk-based Java hosting setup

If your hosting platform uses Plesk and a Java extension such as My App Server, the best practice is to:

Install and activate the SSL certificate for the domain.
Make sure the Java application is reachable through the domain over HTTPS.
Set an HTTP-to-HTTPS redirect at the hosting layer.
Verify that the application generates secure URLs and no mixed content remains.

This approach is suitable for private JVM hosting, Tomcat hosting, servlet hosting, and JSP hosting where the app runs behind Apache or through a Plesk-managed service.

Step 1: Install and assign an SSL certificate

Before you force HTTPS, the domain must have a valid SSL/TLS certificate. Without it, browsers will redirect to an HTTPS URL but still display a certificate error.

In Plesk

Open the domain or subscription in Plesk.
Go to the SSL/TLS certificate section.
Install or renew the certificate.
Assign the certificate to the correct domain and, if needed, to the Java application endpoint.

If you use an automated certificate provider, make sure renewal is enabled. A forced HTTPS rule is only useful when the certificate stays valid.

Common checks

The certificate covers the exact hostname users visit.
The certificate chain is complete.
The domain resolves to the correct hosting account.
The secure version of the site opens without certificate warnings.

Step 2: Redirect HTTP traffic to HTTPS

Once the certificate is active, configure a 301 redirect from HTTP to HTTPS. A permanent redirect helps browsers and search engines understand that HTTPS is the preferred version of the site.

Option A: Force HTTPS in Plesk

In many hosting setups, Plesk provides a simple option to redirect all HTTP traffic to HTTPS. This is the easiest method if your Java application is already published through the domain and the web server front end handles the request.

Open the domain in Plesk.
Look for hosting or Apache/web server settings.
Enable the redirect from HTTP to HTTPS if available.
Save changes and test both the root URL and application paths.

This is generally the best choice for users who want a low-maintenance configuration and do not need custom redirect logic.

Option B: Use an .htaccess redirect

If your Java application is served through Apache and your hosting plan allows .htaccess rules, you can force HTTPS with a rewrite rule. This method is often used when you want precise control over the redirect behavior.

Example:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

This rule checks whether the connection is already secure. If not, it redirects the same host and path to the HTTPS version.

Use this approach carefully if your Java app already has rewrite rules for routing to Tomcat or for pretty URLs. Place the HTTPS rule so it runs before application-specific rewrites, or integrate it into the existing rule set.

Option C: Redirect at the Tomcat or application layer

In some setups, especially when a Java application is reached directly through a connector or custom proxy configuration, you may handle the redirect in the app itself. This is usually the least preferred option for simple hosting environments, but it can help if web server access is limited.

Typical Java-side logic checks whether the request is secure and then sends a redirect to the HTTPS URL. For example, a filter or servlet can inspect the request scheme and respond with a permanent redirect.

However, for hosted Tomcat and private JVM environments, server-level redirects are usually cleaner because they:

apply before the app code runs
avoid duplicate logic across multiple applications
reduce the risk of redirect loops
keep security configuration separate from business code

Example Java redirect filter

If you need application-level control, a simple filter can force HTTPS for all requests. This is useful when the hosting layout does not allow Apache-side redirects or when you want an extra safety layer inside the application.

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HttpsRedirectFilter implements Filter {
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse res = (HttpServletResponse) response;

        String xForwardedProto = req.getHeader("X-Forwarded-Proto");
        boolean secure = req.isSecure() || "https".equalsIgnoreCase(xForwardedProto);

        if (!secure) {
            String redirectUrl = "https://" + req.getServerName() + req.getRequestURI();
            String query = req.getQueryString();
            if (query != null && !query.isEmpty()) {
                redirectUrl += "?" + query;
            }
            res.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
            res.setHeader("Location", redirectUrl);
            return;
        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
    }
}

Use this only if you understand how your hosting platform forwards requests. In some managed environments, Apache or the reverse proxy terminates SSL before the request reaches Tomcat, so the application may see the connection as non-secure unless headers such as X-Forwarded-Proto are passed correctly.

How this works with My App Server and Tomcat hosting

In a Java hosting platform with My App Server, the application is typically deployed inside a private JVM or managed Tomcat instance. The HTTP-to-HTTPS redirect still belongs at the front end, not inside the Java runtime, unless there is a special application requirement.

Typical flow:

The browser requests http://example.com/app.
Apache or the hosting layer receives the request.
The server returns a 301 redirect to https://example.com/app.
The browser repeats the request over HTTPS.
The secure request reaches the Java app or Tomcat backend.

This setup is especially practical for small and medium applications that need:

one Java app per hosting account or subscription
easy control through Plesk
selection of the Java version
simple deploy of WAR, JSP, and servlet applications
separate service control for the app server

If your platform allows changing Java or Tomcat versions, you can still keep the HTTPS logic outside the runtime. That way, switching from one supported version to another does not affect your redirect behavior.

Avoiding mixed content after enabling HTTPS

After you force HTTPS, the application should load all assets over secure URLs. If some pages still reference HTTP resources, browsers may show mixed content warnings or block those resources.

Check for these common sources of mixed content

hard-coded image, CSS, or JavaScript URLs
absolute links using http:// in templates or JSP files
API calls made to insecure endpoints
assets loaded from third-party services without HTTPS

Fixes

Use relative URLs where possible.
Update hard-coded links to https://.
Use the current request scheme when generating links.
Update environment or framework settings if they build URLs automatically.

For Java web apps, also review how the app constructs absolute links in redirects, email templates, and canonical tags. If the app is behind a proxy, make sure it trusts forwarded HTTPS headers when appropriate.

Prevent redirect loops

A common problem after enforcing HTTPS is a redirect loop. This happens when the server keeps thinking the request is insecure, even after the browser is already using HTTPS.

Typical causes

the HTTPS certificate is installed, but the backend still sees HTTP
proxy headers are missing or misconfigured
both Apache and the Java app are redirecting at the same time
the app checks the wrong request variable for secure connections

How to avoid it

Use only one primary redirect rule.
Confirm whether SSL terminates at Apache or at the application server.
Check that X-Forwarded-Proto is passed correctly if a reverse proxy is used.
Test with a clean browser session or private window.

If you manage the Java service through Plesk, service control settings and the application route should be verified after each configuration change. This helps ensure that the redirect is applied at the right layer.

SEO and canonical URL considerations

For public websites, forcing HTTPS is also part of basic SEO hygiene. Search engines prefer one canonical version of the site, and the secure version should usually be the one indexed.

Best practices

Use a 301 redirect from HTTP to HTTPS.
Update the site’s canonical tags to HTTPS.
Make internal links point directly to HTTPS URLs.
Update sitemap URLs to use HTTPS.
Verify the preferred domain version in your application and hosting settings.

If the Java application generates links dynamically, ensure that its base URL configuration is set to HTTPS. This reduces duplicate content issues and makes the site easier to crawl.

Troubleshooting checklist

If HTTPS is not being forced correctly, use this checklist:

Is a valid SSL certificate installed for the domain?
Does the HTTPS version of the site open successfully?
Is the redirect enabled in Plesk or Apache?
Are there competing redirect rules in .htaccess or the app?
Is the Java application behind a proxy or front-end server?
Does the app trust forwarded HTTPS headers?
Are all URLs in the app updated to use HTTPS?
Is the redirect a 301, not a temporary redirect, for permanent enforcement?

If the problem appears only after deployment, review recent changes to Tomcat configuration, Apache rewrite rules, or the application’s context path. In hosted Java environments, small changes in proxy or connector settings can affect how the app detects secure requests.

When to use server-level vs application-level redirects

Use server-level redirects when:

the domain is managed through Plesk
Apache is in front of Tomcat or the JVM
you want one rule for the whole site
the same domain serves multiple app paths

Use application-level redirects when:

you cannot edit web server rules
the app is deployed in a special routing setup
you need conditional behavior based on app logic
you want an extra enforcement layer inside the Java app

For most hosted Java applications, server-level redirection is simpler and easier to maintain. Application-level enforcement is best treated as a fallback or additional safeguard.

FAQ

Should I force HTTPS in Tomcat or in Apache?

In most hosting setups, force HTTPS in Apache or in the control panel first. That keeps the redirect outside the Java code and makes it work for all paths under the domain. Use Tomcat or Java-level redirects only if the server layer cannot be changed.

Will forcing HTTPS break my Java application?

It should not, as long as the SSL certificate is installed correctly and the app is aware of secure requests when it generates URLs. Problems usually come from mixed content, proxy settings, or conflicting redirects.

Do I need to change my Java code to use HTTPS?

Not always. If the redirect is handled at the hosting layer, the code may not need any changes. However, you may still need to update hard-coded URLs, canonical links, and any logic that builds absolute links or checks the request scheme.

What is the difference between a 301 and a 302 redirect?

A 301 redirect is permanent and is usually the right choice when you want all HTTP traffic to move to HTTPS. A 302 is temporary and is typically not recommended for a permanent security change.

Why does my Java app still think the request is HTTP after SSL is enabled?

This usually means SSL is terminated before the request reaches the app, such as at Apache or a proxy. In that case, the application may need to read forwarded headers like X-Forwarded-Proto to understand that the original request was secure.

Can I force HTTPS for only part of my Java site?

Yes, but it is usually better to enforce HTTPS for the entire public application. Partial HTTPS can create inconsistent behavior, mixed content, and unnecessary complexity.

Does forcing HTTPS help with SEO?

Yes. It helps establish a single preferred URL version, improves user trust, and aligns with modern browser expectations. Make sure internal links, canonical tags, and sitemaps also use HTTPS.

Conclusion

To force HTTPS on a Java application, the most reliable method is usually to install a valid SSL certificate and configure a permanent redirect from HTTP to HTTPS at the hosting or web server layer. In a Plesk-based Java hosting environment with My App Server, this works well for Tomcat, JSP, servlet, and private JVM deployments because the redirect is handled before the application code runs.

After enabling the redirect, check for mixed content, confirm that forwarded headers are correct if you use a proxy, and make sure the application’s generated URLs point to HTTPS. With the right setup, your Java app will load securely, behave consistently, and present the correct public URL to users and search engines.

How to force HTTPS on a Java application