Why is HTTPS not working after moving a Tomcat application

If HTTPS stopped working after moving a Tomcat application, the problem is usually not the Java app itself. In most hosting setups, SSL is terminated by the web server or a proxy layer in front of Tomcat, while Tomcat serves the application over an internal HTTP connector or a local port. After a migration, a change in domain, certificate, DNS, Apache configuration, or Tomcat connector settings can break the secure connection even when the application still loads over plain HTTP.

In a managed hosting environment with Plesk and a Java hosting feature such as My App Server, the most common causes are a missing SSL certificate on the domain, an incorrect Apache vhost configuration, a mismatch between the domain and the certificate, stale DNS records, or the application generating non-secure links after the move. The good news is that most HTTPS issues can be identified with a small set of checks.

Why HTTPS can break after moving a Tomcat app

When a Tomcat application is moved, several components may change at the same time:

the domain may point to a new hosting account or IP address;
the SSL certificate may not have been copied or reissued;
the Apache reverse proxy settings may differ on the new account;
Tomcat may still listen on the old port or a different connector setup;
the application may still use hardcoded HTTP URLs;
the browser may cache redirects, HSTS rules, or old certificate data.

Tomcat itself does not usually handle public HTTPS directly in shared hosting. In a Plesk-based Java hosting setup, the public secure connection is typically handled by Apache or the panel’s web server layer, while My App Server runs the application on a private JVM or Tomcat instance behind it. This means that a working Tomcat app does not automatically mean that HTTPS is correctly configured.

Check whether the domain points to the correct hosting account

The first thing to verify is DNS. If the domain still points to the old server, visitors may see an old site, a wrong certificate, or a connection error after the migration.

What to check

Confirm that the domain’s A record points to the new hosting IP address.
Check whether there is an AAAA record that sends traffic to a different IPv6 destination.
Make sure the www subdomain also points to the correct place.
Allow time for DNS propagation if the change was made recently.

If the site works in one browser but not another, or works on one network but not another, DNS propagation or cached records are a likely reason. Use an external DNS checker or query the records from your local machine to confirm the current target.

Verify that the SSL certificate is installed for the right domain

After moving a Tomcat application, the certificate often needs to be installed again in the new hosting panel. A certificate is bound to the domain names listed in it, so if the application moved from one hostname to another, the existing certificate may no longer match.

Common certificate problems after migration

the certificate was not imported into the new account;
the certificate does not include the current domain or www alias;
the private key does not match the certificate;
the certificate expired during or after the move;
Let’s Encrypt has not been renewed automatically yet.

In Plesk, open the domain’s SSL/TLS settings and confirm that the certificate is assigned to the correct site. If you use Let’s Encrypt, reissue or renew it after the migration so the current hostname is included. For applications using My App Server, make sure the domain and its web service are mapped correctly before testing the secure URL.

Check Apache and proxy configuration in front of Tomcat

In most hosting platforms, Apache handles HTTPS and passes requests to Tomcat through a connector or proxy. If Apache is not configured correctly after the move, the application may still run but HTTPS may fail, redirect incorrectly, or show mixed content warnings.

What can go wrong

the SSL vhost is missing or disabled;
the domain is only configured for port 80, not 443;
proxy rules no longer point to the correct Tomcat service;
rewrite rules force an endless redirect loop;
the application is behind a reverse proxy but does not detect HTTPS correctly.

If your hosting panel provides a tool for service control or Apache integration, confirm that the domain has both the HTTP and HTTPS configurations active. In a My App Server setup, the app may run in a private JVM with Apache forwarding traffic to it. After a move, that forwarding path must be recreated or checked again.

Look for redirect loops or forced HTTP links

A very common issue is that the application itself still believes it is running on HTTP. As a result, it generates links, redirects, or form actions that point to http:// instead of https://. Some browsers then switch between versions of the site or block secure resources.

Symptoms of this problem

the browser keeps redirecting between HTTP and HTTPS;
the login page loads, but form submission fails;
images, scripts, or CSS files are loaded over HTTP and blocked by the browser;
the app is accessible, but the padlock is missing or warnings appear.

To fix this, check the application settings and templates for hardcoded absolute URLs. If the app uses a base URL or external configuration file, update it to the secure domain. If Tomcat is behind Apache, also make sure the application recognizes the forwarded HTTPS headers and does not rebuild links as plain HTTP.

Confirm Tomcat connector and application port settings

Tomcat can listen on different ports depending on how it is deployed. In a managed Java hosting service, the visible public port is normally handled by Apache, while Tomcat listens internally on a local or private port. If the connector settings were changed during the migration, Apache may no longer reach the application.

Things to verify

Tomcat is running on the expected internal port;
the service is started in the hosting control panel;
the deployed WAR or application directory is in the correct location;
the context path has not changed after import;
the application no longer expects the old server name or port.

If you are using a custom app server or a manually uploaded Tomcat version, confirm that the service configuration matches the version and runtime paths used by the hosting account. The application can appear to work locally inside Tomcat while the public HTTPS endpoint fails because Apache is no longer connected to the right backend.

Check the browser and site for mixed content

Even when the SSL certificate is correct, a site can still appear broken over HTTPS if some resources are loaded over plain HTTP. Modern browsers block many insecure resources on secure pages. This is especially common after a migration when the application still references the old address or a non-secure asset URL.

Typical mixed content sources

stylesheets and JavaScript files with http:// links;
image URLs hardcoded in templates;
external APIs called with the wrong protocol;
redirects to unsecured login or admin pages;
absolute links stored in application configuration.

Open the browser developer tools and look for blocked content warnings. Update the application so that it uses relative URLs or secure absolute URLs. If the site is behind a proxy, make sure Tomcat sees the original secure request and generates the correct links.

Review HSTS, cache and old browser data

Sometimes HTTPS appears broken after a move because the browser remembers the old state. A previous HSTS policy, cached redirect, or stale certificate record can make a browser behave as if the site is still misconfigured.

How to rule this out

test the site in an incognito or private window;
try a different browser or device;
clear the browser cache for the domain;
check whether the domain has an HSTS rule stored in the browser;
test from a network that has not visited the site before.

If the site works elsewhere, the server-side issue may already be fixed and only the local browser state remains. This is common after certificate renewal or DNS changes.

Use Plesk to compare the old and new hosting setup

When you move a Tomcat application to a Plesk-based hosting account, compare the working old environment with the new one as closely as possible. Small differences often cause HTTPS failures.

Compare these items

domain name and aliases;
document root and application path;
SSL certificate assignment;
Apache proxy or rewrite rules;
Java version and My App Server version;
Tomcat service state;
environment variables and application properties.

If your hosting plan includes My App Server, use the control options in Plesk to confirm that the service is enabled and the Java runtime matches the application needs. For small and medium JSP, servlet, or WAR-based applications, the simplest setup is usually the most reliable: one domain, one certificate, one Tomcat service, and a clean proxy path through Apache.

Step-by-step troubleshooting checklist

If HTTPS is not working after moving a Tomcat application, follow this order:

Confirm that the domain points to the correct hosting account and IP address.
Check that the SSL certificate is installed and valid for the current hostname.
Verify that both the root domain and www version are covered if needed.
Make sure Apache is serving the site on port 443 and forwarding to Tomcat correctly.
Restart or recheck the Tomcat/My App Server service from the control panel.
Test for mixed content in the browser developer tools.
Inspect application settings for hardcoded HTTP links or old base URLs.
Try a private browser window to exclude cached redirects or HSTS data.
Review logs for certificate, proxy, or backend connection errors.

If you still cannot identify the cause, compare the site configuration before and after the move. In many cases, the application itself is fine and the problem is in the SSL or reverse proxy layer around it.

Examples of common migration scenarios

The site opens on HTTP, but HTTPS shows a certificate warning

This usually means the certificate is missing, expired, or issued for another domain. Reinstall or reissue the certificate in the hosting panel and check that the correct hostname is included.

HTTPS loads, but the page keeps redirecting

This often happens when the application or Apache tries to force HTTPS while the proxy setup makes Tomcat believe the request is still HTTP. Review rewrite rules and forwarded headers.

The site is secure, but some assets are blocked

This is mixed content. Update all asset URLs to HTTPS or relative paths. The page may work, but the browser will block insecure files.

The application worked before the move, but now nothing opens on HTTPS

Check DNS first, then SSL assignment, then the Apache-to-Tomcat path. A service moved to a new account often needs all three pieces aligned again.

How HTTPS usually works in a Tomcat hosting environment

It helps to understand the request flow. A visitor opens https://your-domain.com. Apache accepts the secure connection, decrypts it using the installed certificate, and then forwards the request to Tomcat or your private JVM service. Tomcat processes the application and returns the response through Apache back to the browser.

If any part of this chain is broken, HTTPS can fail even though Tomcat itself is running. That is why checking the certificate, DNS, Apache configuration, and app URLs is more important than focusing only on the Java service.

When to contact hosting support

Contact support if you have already checked DNS, the certificate, and the application configuration, but HTTPS still fails after migration. It is especially helpful to provide:

the domain name;
the approximate time of the move;
the exact browser error or certificate warning;
screenshots of the issue;
any recent changes in Plesk, Apache, or My App Server;
details about whether HTTP works while HTTPS does not.

With that information, support can verify whether the issue is in DNS, the SSL layer, Apache proxying, or the Tomcat application service.

FAQ

Why does my Tomcat app work on HTTP but not on HTTPS after migration?

Because HTTPS is usually handled by Apache or a proxy layer in front of Tomcat. The app may still run, but the secure web configuration, certificate, or proxy path may be missing or incorrect after the move.

Do I need a separate SSL certificate for Tomcat?

Usually not in a managed hosting setup. The certificate is typically installed on the domain in Plesk, and Apache handles the public HTTPS connection before forwarding traffic to Tomcat.

Can a wrong DNS record break HTTPS?

Yes. If the domain points to the wrong server, users may reach an old installation, a different certificate, or no valid HTTPS service at all.

Why do I see mixed content warnings after moving the app?

The application likely contains absolute links to http:// resources or old domain names. Update them to secure URLs so the browser can load all files without blocking.

What should I check first in Plesk?

Start with the domain’s SSL/TLS settings, then confirm DNS, then verify that the Apache and My App Server services are active and connected correctly.

Conclusion

HTTPS problems after moving a Tomcat application are usually caused by the hosting layer around the app, not by the application code itself. In a Plesk-based Java hosting environment, the key areas to review are DNS, SSL certificate assignment, Apache proxy settings, Tomcat service configuration, and application URLs. When these parts are aligned, a migrated JSP, servlet, or WAR application should work securely again without major changes.

If the secure site still does not load after you check each layer, compare the old and new configuration carefully and test for browser cache or redirect issues. Most migration-related HTTPS errors are straightforward to fix once the exact layer causing the problem is identified.

Why is HTTPS not working after moving a Tomcat application?