If HTTPS stopped working after moving a Java application, the cause is usually not the Java code itself but one of the surrounding services that the application depends on: DNS, SSL certificate binding, Apache reverse proxy settings, Tomcat connector configuration, or the way the domain was recreated in the control panel. In a managed hosting environment, these elements often change during a migration, so the site may still load over HTTP while the secure version fails with a certificate warning, a redirect loop, or a connection error.
This is especially common when the application runs through a control panel such as Plesk and uses a private JVM or Apache Tomcat instance managed by a hosting extension like My App Server. The application may be healthy, but HTTPS will only work if the domain resolves correctly, the certificate matches the hostname, and Apache or the proxy layer forwards traffic to the Java service in the expected way.
Why HTTPS can fail after a Java application move
When a Java app is moved to a new hosting account, a new subscription, or a different service configuration, several things can break at once. Even if the WAR file or servlet application is deployed correctly, HTTPS depends on external configuration. The most common reasons are:
- The domain now points to the wrong IP address or old DNS records are still cached.
- The SSL certificate was not reissued for the current domain or was not assigned to the correct hosting subscription.
- The Apache virtual host or reverse proxy is not listening on port 443 for the domain.
- The Java application uses absolute HTTP links and then gets stuck in a redirect problem.
- Tomcat is serving the app on a private port, but Apache is not forwarding secure traffic correctly.
- The application expects a different hostname, base URL, or context path after the move.
- A mixed-content issue blocks secure resources such as scripts, stylesheets, or API calls.
In hosting support, the first task is usually to confirm whether the problem is at the DNS layer, the SSL layer, or the application layer. That separation saves time because HTTPS errors often look similar even when the root cause is different.
Check whether the domain points to the new hosting account
After migration, the domain must resolve to the correct hosting platform. If the DNS zone still contains an old A record, or if the nameservers have not fully propagated, the browser may reach the old service or a server that does not have the certificate you expect.
What to verify
- The domain A record points to the current hosting IP address.
- Any AAAA record is valid if IPv6 is enabled.
- The www subdomain also points to the correct target.
- There are no conflicting CNAME or proxy records.
- The correct nameservers are active if DNS is hosted elsewhere.
If the application moved to a new account, test both the root domain and the www version. A very common mistake is to update only one host name, while the certificate and redirect rules expect the other.
In UK-facing hosting setups, DNS propagation may take some time depending on the provider and TTL values. If the site worked before the move but HTTPS fails only on some devices or networks, cache or propagation is often involved.
Confirm that the SSL certificate matches the hostname
HTTPS will fail if the certificate does not cover the exact host name users visit. For example, a certificate issued for example.co.uk will not automatically cover www.example.co.uk unless both names were included. The same applies in reverse. After a move, the certificate may still be installed on the old subscription or attached to the wrong domain alias.
Common certificate-related causes
- The certificate was not renewed after the move.
- The certificate was issued for the wrong host name.
- The certificate is installed on the domain, but not on the alias or www subdomain.
- The certificate chain is incomplete.
- The private key no longer matches the certificate.
In Plesk, check that the correct certificate is selected for the domain and that it is assigned to the site you want to secure. If the hosting platform uses an extension such as My App Server, remember that the certificate still belongs to the domain or proxy layer, not to the Tomcat application itself.
If you use Let’s Encrypt, reissue the certificate after the move if the domain structure changed. Also confirm that HTTP validation is possible and that the DNS record points to the new hosting account before requesting issuance.
Check Apache and proxy settings for port 443
In many Java hosting setups, Apache terminates HTTPS and forwards requests to the private JVM or Tomcat service running behind it. That means the browser connects to Apache on port 443, and Apache proxies the request to the internal Java service. If Apache is not configured correctly, the application may still work on HTTP but fail on HTTPS.
Things to inspect in the control panel
- SSL/TLS support is enabled for the domain.
- Port 443 is active for the virtual host.
- Proxy mode or reverse proxy settings are enabled where required.
- The site’s web root and proxy target were not reset during migration.
- No custom rewrite rule blocks HTTPS requests.
If your Java app uses a separate Tomcat port, confirm that the Apache configuration still points to the correct backend service. A migration can change the internal service port, the application path, or the assigned service name. If Apache forwards to the wrong destination, HTTPS may produce a gateway error or an empty response.
Review Tomcat connector and application base URL settings
A Java application that was originally written for direct Tomcat access may need adjustment when placed behind HTTPS and a proxy. If the app generates its own absolute URLs, session links, redirects, or callback URLs, it may still think it is running on HTTP even when the browser uses HTTPS.
Typical Java and Tomcat issues after a move
- The application hardcodes http:// in redirect URLs.
- The app uses the wrong context path after redeployment.
- Tomcat does not trust the proxy headers forwarded by Apache.
- The server sees requests as insecure and sends them back to HTTP.
- Session cookies are missing secure or same-site flags expected by the browser.
If your hosting platform allows service control through Plesk and My App Server, check whether the Tomcat instance was restarted after the configuration change. A restart is often required after connector edits or service updates. Also confirm that the application is not using a custom embedded server setting that overrides the proxy configuration.
In proxy-based setups, the app may need to understand forwarded headers such as X-Forwarded-Proto so it knows the original request came in through HTTPS. If the app ignores those headers, it may generate insecure redirects or incorrect absolute links.
Look for redirect loops
One of the most common symptoms after a move is a redirect loop. The browser tries to open HTTPS, the server sends it back to HTTP, and then the control panel or web server redirects it back to HTTPS again. The result is an endless loop or a browser error about too many redirects.
Why redirect loops happen
- Both Apache and the Java application try to force HTTPS at the same time.
- The app thinks the request is not secure because proxy headers are missing.
- A rewrite rule sends requests to the old host name.
- The application URL was changed during migration, but one redirect rule was not updated.
To troubleshoot, disable one redirect layer temporarily and test again. Decide whether HTTPS enforcement should happen at the web server level or inside the application. In managed hosting, it is usually cleaner to enforce the redirect in Apache or the control panel and let the Java app focus on business logic.
Check for mixed content after switching to HTTPS
Sometimes HTTPS is technically working, but the browser shows warnings or blocks parts of the page because the Java app still loads resources over HTTP. This is called mixed content. It often appears after a move if the application stores the old base URL in configuration files, database records, or environment variables.
Common mixed content examples
- Images loaded from http:// links.
- JavaScript or CSS files referenced with insecure URLs.
- API endpoints still configured with HTTP.
- Login forms or callbacks pointing to the old host name.
Use the browser developer tools to identify blocked content. Update all external links to use https:// or, where appropriate, relative paths. If the application generates URLs dynamically, check the base URL setting in the app configuration, Tomcat environment, or application properties.
Verify the hosting service status and Java app server configuration
When a Java app is hosted through a panel-based service, the application usually depends on a service that can be started, stopped, or restarted independently. If that service is not running, HTTPS may show a web server error even though the certificate is correct.
In a My App Server setup, it is important to verify the service state in the control panel. A move may require you to reattach the application to the service, reinstall a supported Java version, or adjust the custom app server settings.
What to check in the service control area
- The Java/Tomcat service is running.
- The selected Java version is available and compatible with the application.
- The app server was assigned to the correct domain.
- The service was restarted after changing SSL or proxy settings.
- The application logs do not show startup errors.
If the hosting platform offers several ready-made Java or Tomcat versions, confirm that the instance used after the move matches the application requirements. A change in Java version rarely breaks HTTPS directly, but it can break the app startup, and that can look like an SSL problem to the end user.
Step-by-step checklist to fix HTTPS after a move
Use the following sequence to isolate the issue quickly:
- Open the domain in a browser and confirm whether the error is a certificate warning, redirect loop, timeout, or page asset problem.
- Check DNS records for the root domain and www subdomain.
- Confirm that the domain points to the new hosting account.
- Inspect the SSL certificate assignment in the control panel.
- Make sure the certificate covers every hostname used by the application.
- Verify that Apache or the proxy layer listens on port 443.
- Check that the Java service or Tomcat instance is running.
- Review redirect rules in Apache, Plesk, and the application itself.
- Test for mixed content in the browser console.
- Restart the web server or Java service if configuration changes were applied.
If the issue remains unresolved after these checks, compare the current configuration with the old environment. Migration problems often come from one missing host alias, one outdated redirect, or one certificate not being reassigned after import.
Examples of common scenarios
The site opens on HTTP, but HTTPS says the certificate is wrong
This usually means the SSL certificate was not installed for the current domain or the browser is reaching a different server because DNS still points elsewhere. Check the domain alias, www record, and certificate assignment first.
The browser shows too many redirects after the move
Most likely Apache and the Java application both try to force HTTPS, or the app does not recognize forwarded HTTPS headers. Review rewrite rules and proxy settings.
HTTPS opens, but images and scripts are blocked
This is a mixed content issue. Update hardcoded http:// links in the application, templates, or database content. Also verify the base URL settings.
The app returns a 502 or 503 only on HTTPS
That often points to proxy or backend service configuration. Confirm that Apache forwards requests correctly to the Tomcat instance and that the Java service is running under the current account.
Best practices after migrating a Java application
To avoid HTTPS problems in future moves, keep the application and hosting configuration aligned:
- Use relative URLs where possible instead of hardcoded host names.
- Keep DNS records documented before and after the migration.
- Reissue SSL certificates whenever the host names change.
- Test both the non-www and www versions of the domain.
- Confirm proxy and redirect behavior after every deployment.
- Store application base URL settings in a place that can be updated easily.
- Restart the Java service after changing connector or environment settings.
For Tomcat hosting and JSP or servlet applications, a small change in proxy or certificate handling can affect login flows, session handling, and callback URLs. A short post-move checklist is usually enough to catch these issues before users notice them.
FAQ
Why did HTTPS stop working even though the Java app still runs?
Because HTTPS is usually handled by DNS, Apache, the SSL certificate, and the proxy layer, not only by the Java application. The app may be fine while the secure connection setup is broken.
Do I need to reinstall Tomcat after moving the site?
Not always. If the app server settings moved correctly, a reinstall may not be necessary. However, you may need to reassign the service, verify the Java version, or restart the instance after migration.
Can a wrong DNS record break SSL?
Yes. If the domain resolves to the wrong server, the browser may see a different certificate or an older configuration, which leads to SSL warnings or failed validation.
Why does HTTP work but HTTPS fails?
HTTP may work because it only requires the web server to answer on port 80. HTTPS adds certificate validation, port 443, and secure proxy handling, so more pieces must be correct.
What should I check first in Plesk?
Start with the domain’s DNS resolution, then confirm the certificate assignment, SSL/TLS support, and any redirect or proxy settings. If the app uses My App Server, also verify that the Java service is running.
Can mixed content appear only after a migration?
Yes. If the application stored the old site URL or protocol in its configuration, the move can expose insecure links that were not visible before.
Conclusion
If HTTPS is not working after moving a Java application, the problem is usually one of three areas: DNS points to the wrong place, the SSL certificate is not assigned correctly, or Apache and Tomcat are not forwarding secure traffic as expected. In a managed hosting environment with Plesk and a private Java service, those layers must work together for secure access to function properly.
By checking DNS, certificate coverage, proxy behavior, redirect rules, and application URL settings in order, you can usually find the issue quickly. For Java, Tomcat, JSP, and servlet hosting, the best results come from keeping the domain, certificate, and service configuration aligned after every move.