When HTTPS stops working after moving a Tomcat application, the problem is usually not with Tomcat itself, but with the SSL certificate, DNS records, Apache proxy rules, or the way the application is bound to the new hosting environment. In a managed hosting setup with Plesk and My App Server, the most common cause is that the app was moved successfully, but the HTTPS endpoint was not fully reconnected to the new domain, port, or certificate configuration.
If your Tomcat app opens over HTTP but fails over HTTPS, shows a certificate warning, redirects in a loop, or returns a 404/502 after migration, the issue is normally one of the following: SSL was not installed on the domain, the certificate does not match the hostname, DNS still points to the old location, Apache is not proxying requests correctly to Tomcat, or the application itself has hardcoded URLs that still reference the previous server.
Why HTTPS breaks after a Tomcat migration
Moving a Java application changes more than just files. A Tomcat application often depends on the domain name, certificate, web server proxy configuration, and JVM/service settings. If any of these are left behind or recreated differently on the new account, HTTPS may stop working even though the application files are present.
In a hosting control panel environment, Tomcat usually runs behind Apache. Apache handles the SSL connection on port 443 and forwards traffic to the app server. That means HTTPS problems are often caused by the front-end web server configuration rather than the Tomcat WAR itself.
Common reasons include
- The SSL certificate was not reissued or reinstalled for the new domain.
- The domain points to the wrong DNS destination.
- The application still redirects to the old hostname or a non-HTTPS URL.
- Apache virtual host settings were not updated after the move.
- The Tomcat service is running, but the app is not mapped correctly in Plesk.
- The certificate chain is incomplete or the browser does not trust the configured SSL setup.
- The app depends on absolute links, callbacks, or external services that still use the previous address.
Check whether the domain points to the new hosting account
The first step is to confirm that the domain is resolving to the correct server. If DNS still points to the old environment, HTTPS may fail even if the app is properly deployed on the new account.
What to verify
- The A record points to the current hosting platform.
- Any AAAA record for IPv6 is valid and intentional.
- The domain and www subdomain resolve consistently.
- DNS changes have had enough time to propagate.
If you recently moved the application, test both the base domain and www version. A very common issue is that one hostname works and the other still uses an old DNS target or an old certificate.
If the site loads over HTTP but not HTTPS, DNS may be correct while SSL is still missing. If neither HTTP nor HTTPS works, the issue is more likely DNS, web server routing, or a failed service mapping.
Confirm that SSL is installed on the new domain
After moving a Tomcat application, you may need to activate SSL again for the domain in the control panel. In a Plesk-based hosting environment, SSL is usually managed per domain, not per application. That means the certificate must be assigned to the correct site before HTTPS can work.
Check the following
- The certificate is installed for the exact hostname the browser is using.
- The certificate includes the base domain and any required subdomains.
- The certificate is not expired.
- The intermediate certificate chain is complete.
- The certificate was applied to the correct vhost or subscription.
If the application was moved to a different subscription or domain in Plesk, do not assume the previous SSL settings came with it automatically. Reassign the certificate if needed.
Typical SSL mismatch examples
- example.co.uk is secured, but www.example.co.uk is not.
- The certificate was issued for the old domain name, not the new one.
- The browser shows a name mismatch because the app is accessed through a different hostname.
Make sure Apache is proxying HTTPS traffic to Tomcat correctly
In managed Tomcat hosting, Apache usually terminates SSL and forwards requests to Tomcat through a local connector. If this handoff is broken, HTTPS may return errors even though Tomcat is active.
This matters especially after migration, because the domain mapping, proxy target, or application context path may have changed.
Symptoms of a proxy problem
- HTTPS returns 502 Bad Gateway.
- The browser connects, but the application does not load.
- Static pages work, but the Java app area fails.
- Only HTTP works, while HTTPS gives an error page from Apache.
If you use My App Server, verify that the application is still attached to the correct domain and that the service is running. The Tomcat instance should be active, and the Apache front end should be able to reach it through the expected internal connector.
Useful checks in Plesk
- Review the domain’s hosting settings.
- Confirm that the application is assigned to the correct document root or context.
- Check that the app server service is started.
- Verify any custom Apache directives that were used before the move.
Look for redirect loops and forced HTTPS settings
Another frequent cause is a redirect loop. This happens when Apache, Tomcat, or the application itself tries to force HTTPS in a way that conflicts with another layer. After a migration, one server may redirect HTTP to HTTPS while another layer still thinks the request is already secure.
How redirect loops appear
- The browser keeps refreshing without loading the page.
- You see too many redirects or a connection reset error.
- Logging in works on HTTP but fails on HTTPS.
- Links switch between http and https repeatedly.
Check whether SSL termination is done by Apache and whether the Tomcat application is reading the forwarded protocol correctly. Some Java applications need to know that the original request arrived over HTTPS, even if Tomcat itself receives it from Apache as an internal proxy request.
What to review in the application
- Hardcoded redirects to the old domain.
- Environment-specific base URLs.
- Framework settings that force secure cookies or HTTPS-only routing.
- Callback URLs for payment, login, or API integrations.
If the app uses Spring, JSF, or another Java framework, check whether it trusts proxy headers such as X-Forwarded-Proto. A migration can change how these headers are passed from Apache to Tomcat.
Check the Tomcat application context and hostname
HTTPS may appear broken when the real issue is that the application is still tied to the old context path or hostname. This is common when a WAR was deployed under a different name, or when the app assumes a fixed base URL.
Review these application details
- Does the WAR file name match the new context path?
- Does the app use absolute links in templates, emails, or redirects?
- Does the configuration file still point to the old domain?
- Are session cookies set for the correct hostname and secure mode?
For example, if the application was previously available at http://old-domain.example and now lives at https://new-domain.example, any hardcoded reference to the old address can break login pages, assets, or API requests.
Verify the SSL certificate from the browser and server side
To identify the exact cause, inspect the certificate details in the browser and compare them with the domain that should be serving the site. A valid SSL setup must match the hostname used by visitors.
Check for the following
- Certificate common name or SAN entries match the domain.
- The certificate is valid for the requested hostname.
- The certificate has not expired.
- The full chain is presented correctly.
- There are no warnings about mixed content.
Mixed content is also important after a migration. Even if HTTPS loads correctly, the browser may block images, scripts, CSS, or API calls that still use HTTP. This is especially common in Java applications that generate absolute asset URLs or reference external endpoints.
Check for mixed content after the move
Mixed content does not always stop HTTPS from loading, but it can make the application appear broken or partially insecure. After a Tomcat migration, the page may open, but some functions fail because resources are still requested over HTTP.
Examples of mixed content issues
- JavaScript files are loaded over HTTP and blocked by the browser.
- Images or stylesheets reference the old URL.
- AJAX calls use an unsecured endpoint.
- Third-party integrations still call the previous address.
Update all application URLs to use relative paths where possible, or switch them to the correct HTTPS base URL. In Java applications, this often includes configuration files, JSP templates, properties files, and generated links.
Steps to fix HTTPS after moving a Tomcat application
If you need a practical checklist, follow these steps in order. This will resolve most HTTPS issues after a Tomcat move in a hosted environment.
- Confirm the domain resolves to the new hosting account.
- Check that the SSL certificate is installed for the correct hostname.
- Ensure the certificate is assigned to the right domain in Plesk.
- Verify that the Tomcat or My App Server service is running.
- Test the application over HTTP and HTTPS separately.
- Inspect browser certificate warnings for name mismatch or trust errors.
- Review Apache proxy settings and any custom virtual host directives.
- Look for redirect loops caused by forced HTTPS rules.
- Search the application for hardcoded old domain references.
- Clear browser cache and test in an incognito window.
If the application uses a separate JVM or custom app server setup, also confirm that the service configuration was migrated cleanly. In a managed hosting environment, service status and domain binding are just as important as the deployed WAR file.
How My App Server affects HTTPS behavior
With My App Server, you can install and manage a private Tomcat or JVM instance inside the hosting account. This is practical for Java, JSP, and servlet applications, but HTTPS still depends on the domain-level SSL configuration and the Apache front end.
That means the app server can be working correctly while HTTPS fails because the domain itself is not configured properly. The move may have succeeded at the Java layer, but the web layer still needs to be updated.
Important points in this setup
- Tomcat runs as the application layer, not the SSL terminator.
- Apache typically handles the public HTTPS connection.
- The SSL certificate belongs to the domain, not to Tomcat alone.
- Service control and domain mapping must both be correct.
This separation is useful because it gives you more control over Java version and application deployment, but it also means that SSL problems are often outside the app itself.
When to check logs
If the issue is not obvious, check the web server and application logs. Logs can show whether the request reaches Apache, whether Apache forwards it to Tomcat, and whether the application rejects the request because of hostname, protocol, or session settings.
Look for patterns such as
- SSL handshake failures.
- Proxy errors between Apache and Tomcat.
- 404 errors for the wrong context path.
- Repeated redirects to the same URL.
- Application errors caused by missing secure configuration.
Log review is especially helpful when the browser only shows a generic error page. A precise error in the logs usually points to the layer that needs correction.
Best practices for future Tomcat moves
To reduce HTTPS problems during future migrations, keep the domain, SSL, and application configuration documented together. A Java app often works best when the hosting and application settings are moved as a complete unit rather than as files alone.
Recommended practices
- Use the same domain name after migration whenever possible.
- Keep SSL certificates active and reapply them to the new hosting subscription.
- Avoid hardcoded absolute URLs in the application.
- Use relative links and configurable base URLs.
- Check Apache proxy and redirect settings after every move.
- Test both the base domain and www version.
- Confirm that the Java service starts correctly after deployment.
For Tomcat and JSP applications, a clean migration usually means confirming three layers: DNS, web server SSL, and the Java service itself. If all three are aligned, HTTPS should work normally.
FAQ
Why does HTTP work but HTTPS fails after moving my Tomcat app?
Usually because SSL is not installed on the new domain, the certificate does not match the hostname, or Apache is not forwarding secure traffic correctly to Tomcat.
Can the Tomcat app itself cause HTTPS problems?
Yes, if it contains hardcoded redirects, old domain references, or framework settings that do not work behind an SSL proxy. However, the root cause is often in DNS or the web server layer.
Do I need to reinstall the SSL certificate after a migration?
Often yes. Even if the certificate file is unchanged, it may need to be reassigned to the new domain or subscription in the control panel.
Why am I getting a certificate name mismatch?
The certificate does not match the hostname that visitors are using. This can happen if the app moved to a new domain, the www version is missing, or the old certificate is still attached.
Why do I see too many redirects after enabling HTTPS?
This usually means more than one layer is forcing HTTPS, or Tomcat does not know that the original request was already secure after Apache terminated SSL.
What should I check first in Plesk?
Check the domain’s SSL assignment, the hosting settings, the application mapping, and the status of the Java service managed by My App Server.
Conclusion
HTTPS problems after moving a Tomcat application are usually caused by the surrounding hosting configuration rather than the Java code itself. In a Plesk-based hosting environment with My App Server, the main things to verify are DNS, certificate assignment, Apache proxy behavior, redirect rules, and the application’s own hostname settings.
Once the domain resolves correctly, the SSL certificate is installed for the right hostname, and Tomcat is properly connected through the control panel, HTTPS should start working again. If the site still fails, the fastest path is to review logs and compare the old and new configurations layer by layer.