When HTTPS stops working after moving a JSP application, the cause is usually not the JSP code itself, but the way the new hosting account is handling the domain, SSL certificate, Apache proxy rules, or the Tomcat / private JVM setup behind the scenes. In most cases, the application is still reachable over HTTP, while HTTPS fails because the certificate is missing, the hostname does not match, the domain is not pointing to the right service, or the secure connection is not being forwarded correctly from Apache to Tomcat.
On a managed hosting platform with Plesk and a Java hosting solution such as My App Server, you normally have two layers involved: Apache serves the public web traffic and forwards application requests to the Java service, while Tomcat or another JVM processes the JSP application. After a migration, either layer can be out of sync with the SSL configuration. This article explains the most common reasons HTTPS breaks after a move, how to check each one, and how to restore secure access to your JSP application.
Why HTTPS may fail after moving a JSP application
After a migration, HTTPS can stop working for several reasons at once. The most common ones are:
- The SSL certificate was not installed on the new hosting account.
- The certificate does not include the exact domain name used by visitors.
- The DNS records still point to the old server or to a different IP address.
- Apache is not configured to serve the secure virtual host for the domain.
- The application was moved to Tomcat, but HTTPS requests are not being passed correctly through the reverse proxy.
- The app is generating HTTP links instead of HTTPS links after the migration.
- The old environment used a different port, connector, or application server path.
If the site opens on http:// but not on https://, always check the certificate and DNS first. If the browser shows a certificate warning, that usually means the certificate is missing, expired, installed for the wrong hostname, or the browser is reaching the wrong server.
Check whether the domain points to the new hosting account
Before changing anything in Plesk or Tomcat, confirm that the domain is resolving to the new hosting account. If DNS still points elsewhere, HTTPS may show the old certificate, a default certificate, or no secure site at all.
What to verify
- The domain’s A record points to the current hosting IP.
- The www hostname also points correctly, if you use it.
- Any AAAA record is correct if IPv6 is enabled.
- There are no conflicting DNS records from the old provider.
After a migration, DNS propagation may take some time. If the site works for some users but not others, this is a strong sign that some resolvers still cache the old IP address. In that case, wait for DNS to settle and verify the TTL values on the zone.
Typical sign of a DNS problem
If HTTPS opens a different site, shows an unrelated certificate, or lands on a default hosting page, the browser is probably reaching the wrong server. In that case, SSL troubleshooting will not help until DNS is corrected.
Confirm that an SSL certificate is installed for the exact hostname
A very common issue after moving a JSP application is that the certificate was issued for one hostname, but users are visiting another. SSL certificates are hostname-specific. A certificate for example.co.uk does not automatically cover www.example.co.uk unless it was issued for both names, and it will not cover a subdomain unless that name is included too.
Check these points in Plesk
- The certificate is installed for the correct domain subscription.
- The domain and www alias use the same certificate if both are in use.
- The certificate is not expired.
- The certificate chain is complete.
- The private key matches the certificate.
If your application is accessed through a subdomain such as app.example.co.uk, make sure the certificate was issued for that exact name or for a wildcard that covers it. A common migration mistake is installing a certificate for the root domain while the application is published on a subdomain.
What happens if the certificate is missing
Browsers may show warnings like connection is not private, certificate name mismatch, or site can’t provide a secure connection. In some setups, the browser may refuse to load the page entirely. If the application is behind Apache and Tomcat, the browser may never reach Tomcat because the secure connection fails first at Apache.
Make sure Apache is serving the secure virtual host
On a hosted Java platform, Apache typically terminates the SSL connection and then forwards traffic to the application server. If the HTTPS virtual host was not created properly during the move, the browser may not be able to reach the application even though Tomcat is running normally.
Things to check in a Plesk-based setup
- SSL/TLS support is enabled for the domain.
- The certificate is assigned to the correct domain.
- The secure web hosting settings are active.
- Apache is not redirecting HTTPS traffic to an incorrect target.
- No custom .htaccess rule is breaking the secure host.
When using managed hosting with a Java app server, Apache often acts as the public entry point. If Apache is misconfigured, the JSP application may still run internally, but external visitors will not be able to establish a valid HTTPS connection.
Watch for redirect loops
Another common symptom is a redirect loop between HTTP and HTTPS. This can happen when the application forces HTTPS, Apache also forces HTTPS, or a proxy setting creates a repeated redirect. In that case, the browser may show a too many redirects error. The solution is to make sure only one layer handles the redirect logic.
Check the Tomcat or private JVM setup after migration
If your JSP application runs on a private JVM or a separate Tomcat instance through My App Server, the secure access path may have changed after the move. The app may still start, but the connector, port mapping, or proxy target may not match the new hosting account.
What to verify in the Java service
- The Java service is started and healthy.
- The correct Tomcat version is installed.
- The application is deployed in the right path.
- The HTTP connector used by Apache matches the service configuration.
- No stale port or host value remains from the old server.
With My App Server, you may manage your own Apache Tomcat instance or another supported Java service inside the hosting account. That flexibility is useful for JSP and servlet applications, but it also means migration errors can come from the Java layer as well as the web server layer. If the app was previously running on a different port, or if a custom app server configuration was used, the new environment must be updated to match.
Typical migration mismatch
For example, the old hosting account may have forwarded HTTPS requests to a Tomcat connector on one port, while the new account uses a different connector or a different reverse proxy rule. The result can be a site that loads insecurely, returns a blank page, or fails only on secure URLs.
Check whether the application is generating insecure URLs
Sometimes HTTPS itself is working, but the JSP application still behaves as if it is on plain HTTP. After migration, absolute links, redirects, cookies, or form actions may still point to http:// instead of https://.
Common application-level causes
- Hard-coded base URLs in JSP pages or configuration files.
- Redirects built from the wrong request scheme.
- Framework settings that still assume HTTP.
- Mixed content: images, scripts, or styles loaded over HTTP.
- Session cookies missing the Secure flag when needed.
Mixed content is especially important. Even if the main page opens on HTTPS, browsers may block insecure JavaScript, CSS, or API calls. This is often mistaken for an SSL problem, but the real issue is that part of the page still uses HTTP URLs.
How to fix it
- Use relative URLs where possible.
- Update the application’s base URL to HTTPS.
- Search JSP files and config files for hard-coded http:// links.
- Check any reverse proxy headers used by the app.
- Update external integrations that still call the old HTTP address.
If the app is behind Apache and Tomcat, the application may need to trust the X-Forwarded-Proto header or similar proxy headers to detect that the original request was secure. Without that, some frameworks generate HTTP links even though the user connected through HTTPS.
Review redirect rules in .htaccess or application configuration
After migration, redirect rules sometimes remain from the old setup and conflict with the new SSL configuration. This is common when moving a JSP application from one host to another with different Apache settings.
Look for these problems
- Redirects from HTTPS back to HTTP.
- Rules that force one host name while the certificate covers another.
- Multiple rewrite rules that create loops.
- Legacy redirect logic based on a fixed port or server name.
Review both the web root configuration and any application-level redirect logic. A redirect that worked on the old server can fail on the new one if the SSL termination point or host mapping is different.
Understand the role of My App Server and Plesk in SSL handling
In this hosting model, Plesk manages the domain, SSL certificate, and Apache site configuration, while My App Server manages the Java runtime and Tomcat-based application service. That separation is practical, but it also means troubleshooting should be done in layers.
Use this order when diagnosing the issue
- Confirm DNS resolves to the current account.
- Confirm the SSL certificate is installed for the correct hostname.
- Confirm Apache has SSL enabled for the domain.
- Confirm the Java service is running.
- Confirm Apache forwards requests to the correct app server target.
- Confirm the application generates HTTPS-safe URLs.
This approach prevents wasted time. A certificate problem will never be fixed by restarting Tomcat, and a Tomcat port mismatch will not be solved by reissuing the SSL certificate. The issue is often a combination of a web-level and app-level setting.
Practical troubleshooting steps
If HTTPS is not working after moving your JSP application, go through the following checklist:
- Open the site in a browser and note the exact error message.
- Check whether the issue affects the root domain, the www hostname, or a subdomain.
- Verify DNS points to the correct hosting account.
- Confirm the certificate is installed and assigned in Plesk.
- Make sure the certificate covers the exact hostname being used.
- Check whether SSL/TLS support is enabled for the domain.
- Inspect Apache or .htaccess redirect rules for loops or forced HTTP.
- Confirm the Tomcat or private JVM service is running normally.
- Review the application for hard-coded HTTP links or proxy assumptions.
- Test the site in a private browser window to avoid cached redirects.
If you recently changed nameservers, allow time for propagation before concluding that SSL is broken. If you recently changed the app server configuration, compare the current Tomcat setup with the old one and verify that the service port, host name, and deployment path are correct.
Examples of common error messages and what they usually mean
“Your connection is not private”
This usually means the certificate is missing, expired, untrusted, or issued for the wrong hostname.
“NET::ERR_CERT_COMMON_NAME_INVALID”
The certificate does not match the domain or subdomain being visited.
“Too many redirects”
A redirect loop exists between HTTP and HTTPS, or between www and non-www.
“Site can’t be reached” on HTTPS only
The SSL virtual host may not be configured correctly, or the secure port is not being served properly by Apache.
HTTPS loads, but pages or assets fail
This often indicates mixed content or application URLs that still point to HTTP.
How to avoid HTTPS issues during future migrations
The easiest way to prevent this problem is to plan SSL and Java settings as part of the migration, not afterward. For JSP applications, the secure site and the application server should be checked together.
- Export the current SSL certificate and private key if the migration permits it.
- Document the exact domain names used by the application.
- Record the original Tomcat or JVM port mapping.
- List any Apache rewrite rules and proxy settings.
- Test both HTTP and HTTPS immediately after the move.
- Verify that the app generates secure links and secure cookies.
In a Plesk-managed Java hosting environment, it is helpful to keep a short migration checklist for DNS, SSL, Apache, and the application server. That saves time when moving JSP, servlet, or WAR-based applications between hosting accounts.
FAQ
Why does HTTP work but HTTPS fails after moving my JSP app?
HTTP may still work because the domain is reachable and Apache is serving the site, but HTTPS depends on a correct SSL certificate, secure virtual host configuration, and correct DNS. If any of those are missing, HTTPS can fail while HTTP still loads.
Can a JSP application itself break HTTPS?
The JSP code usually does not break HTTPS at the transport layer, but it can create mixed content, wrong redirects, or hard-coded HTTP links. Those issues make the site appear insecure or partially broken after the move.
Do I need to reinstall the SSL certificate after migration?
Often yes, or at least reassign it in the new Plesk subscription. Even if you keep the same certificate, it must be installed on the new hosting account and associated with the correct domain name.
What if my site uses www and non-www?
Both hostnames must be covered by the certificate if both are accessible. If one of them redirects to the other, make sure the redirect target is the hostname included in the certificate.
Can My App Server handle HTTPS for my Java app?
My App Server is designed to help you manage Java hosting, Tomcat, and a private JVM within a hosting account, while Apache and Plesk handle the public web and SSL layer. In practice, HTTPS must be configured correctly across both layers for the application to work as expected.
Why do I get a redirect loop after the migration?
A redirect loop usually means more than one rule is trying to enforce HTTPS or the application is not recognizing the original scheme correctly. Check Apache rules, .htaccess, and any app-level proxy settings.
Conclusion
When HTTPS stops working after moving a JSP application, the root cause is usually one of four things: DNS still points to the wrong place, the SSL certificate is missing or mismatched, Apache is not serving the secure host correctly, or the Tomcat / private JVM configuration does not match the new environment. In many migrations, the issue is a combination of all four.
For a JSP or servlet application hosted through Plesk and My App Server, the safest approach is to verify DNS, SSL, Apache, and the Java service in that order. Once the domain resolves correctly, the certificate matches the exact hostname, and the application server receives traffic from Apache as expected, HTTPS should work normally again.