If your Java application worked over HTTPS before the move, but the secure connection stopped working after migration, the cause is usually not the Java code itself. In most cases the problem is related to the SSL certificate, DNS records, Apache/Tomcat proxy settings, port binding, or a mismatch between the domain name and the address used by the application after the transfer.
In a managed hosting environment with Plesk and a Java setup such as My App Server, HTTPS is often handled by Apache in front of your Tomcat or private JVM instance. That means the certificate, hostname, and web server configuration must all match after the application is moved. If one part is still pointing to the old hosting environment, HTTPS can fail even when the Java app is running correctly.
Why HTTPS breaks after moving a Java application
When a Java application is moved to a new hosting account, server, or document root, several layers may need to be updated at the same time. HTTPS can stop working for one of these reasons:
- The SSL certificate was not reissued or reinstalled for the new domain setup.
- The domain DNS still points to the old server or is partially updated.
- Apache is not configured to serve the site on port 443.
- The virtual host for the domain was recreated, but SSL settings were not copied.
- Tomcat is listening only on HTTP, while SSL termination is expected at Apache.
- The application redirects to an old hostname, IP address, or non-HTTPS URL.
- The certificate common name or SAN does not cover the current domain or subdomain.
- A reverse proxy, load balancer, or CDN is still using the old backend target.
For Java hosting and Tomcat hosting, the most important thing to understand is that HTTPS is often not controlled inside the application itself. In many hosting setups, Apache handles the SSL connection and forwards traffic to Tomcat over HTTP or AJP. If the Apache-side SSL configuration is incomplete, the application may still load on HTTP but fail on HTTPS.
Check whether the domain points to the new hosting account
After migration, start by confirming that the domain resolves to the correct server. If DNS is still pointing to the old hosting environment, the browser may reach the wrong machine and show certificate errors, redirect loops, or no HTTPS response at all.
What to verify
- The A record points to the current server IP.
- The AAAA record, if present, points to the correct IPv6 address or is removed if unused.
- The domain and www subdomain both resolve consistently.
- Any DNS propagation delay has passed.
If you recently moved the application, DNS changes can take time to become visible everywhere. During that period, some visitors may still reach the old server while others hit the new one. This can make HTTPS look unstable when the issue is actually split DNS propagation.
In Plesk, verify the domain’s DNS zone and ensure it matches the current hosting setup. If the DNS zone is managed externally, check the registrar or external DNS provider instead.
Confirm that the SSL certificate matches the current hostname
A very common reason for HTTPS failure after moving a Java application is a certificate mismatch. The certificate must cover the exact domain name used by visitors. If the app used to run on one hostname and now runs on another, the old certificate may no longer be valid for the new address.
Common certificate problems
- The certificate was issued for example.com, but the site is now accessed via www.example.com.
- The application moved from a subdomain to the main domain, or the other way around.
- The certificate expired during or after the migration.
- The certificate was not installed on the new hosting subscription.
- The server is still presenting a default certificate instead of the site certificate.
In a Plesk environment, make sure SSL/TLS support is enabled for the domain and that the correct certificate is selected. If you use Let’s Encrypt or another automatic issuer, renew or reissue the certificate after the move if needed. This is especially important if the hosting account or domain mapping changed.
If the browser shows a warning such as certificate not valid for this domain, the fix is usually on the server configuration side, not in the Java application.
Check how Apache and Tomcat are handling HTTPS
In Java hosting setups based on My App Server, HTTPS is often terminated by Apache while Tomcat serves the application behind it. That means Apache is responsible for accepting secure connections on port 443, and Tomcat receives the request after Apache has already decrypted it.
If the app works on HTTP but not HTTPS, the Apache virtual host may be missing one of the following:
- SSL is enabled for the domain.
- The correct certificate and private key are attached.
- Port 443 is configured in the hosting stack.
- The proxy rules forward requests to the correct Tomcat instance.
- The rewrite rules preserve the HTTPS scheme when needed.
Typical hosting scenario
A practical example is a WAR application deployed in Tomcat through the control panel. Apache receives the request on https://yourdomain.tld, then passes it to Tomcat on a local port. If Apache is not configured for SSL, or if the proxy target changed during migration, the secure site may stop responding even though the Java service is running normally in Plesk.
Use the control panel service tools to confirm that the Apache service is active and that your Java service is running. If the application server was recreated or redeployed, check whether the SSL-enabled virtual host still points to the correct backend.
Verify the My App Server and Java service configuration
When a Java application is moved inside the same hosting account or to a new subscription, the My App Server configuration can change. This may affect the port, working directory, runtime version, or service mapping. HTTPS problems may appear because the application is no longer reachable through the same internal route.
Things to review in My App Server
- The Java/Tomcat version is installed and running.
- The service is started after the move.
- The app is bound to the expected domain or subdomain.
- The application path and deploy location are correct.
- The internal port used by the app server has not changed unexpectedly.
- No custom configuration is redirecting traffic to an old URL.
If you use a custom app server or manually uploaded Java version, confirm that the runtime path is still valid after migration. A broken startup configuration can make the application appear online on the server, but inaccessible through the HTTPS site URL.
Look for redirect loops and wrong base URLs
Another common issue after migration is an application that keeps redirecting between HTTP and HTTPS, or between different hostnames. This often happens when the application stores an old base URL in its configuration file, environment variables, or framework settings.
Symptoms of redirect-related HTTPS failure
- The browser keeps loading the same page repeatedly.
- The site opens on HTTP and then switches back to the old hostname.
- The app forces HTTPS before the SSL configuration is actually ready.
- Login pages or admin panels fail after the domain move.
Review application settings for:
- Hardcoded URLs in configuration files.
- Spring, Struts, JSP, or servlet redirect rules.
- Framework properties that define the public site URL.
- Proxy or forwarded headers used to detect HTTPS.
If your app depends on the request scheme, it may need to trust the reverse proxy headers sent by Apache. In some setups, the Java application sees the request as HTTP even though the visitor used HTTPS. If your framework is configured to enforce secure URLs, this mismatch can trigger incorrect redirects.
Check port and proxy settings
HTTPS requires port 443 to be available and correctly configured on the web server layer. A move can change how ports are assigned or how the domain is routed to the Java service.
What to check
- Port 443 is open and used by Apache or the front-end web server.
- The Java app is not trying to bind directly to 443 without the necessary privileges or configuration.
- No other service is already using the same port.
- Proxy rules still point to the correct internal HTTP port used by Tomcat.
In shared hosting and managed hosting platforms, Tomcat usually runs on an internal port, not directly on 443. Apache handles the secure public connection and forwards the request. If you manually changed Tomcat connector settings during the move, the application may no longer be reachable through the expected HTTPS endpoint.
For most Java hosting and servlet hosting setups, it is better to keep SSL at the web server layer unless your hosting plan explicitly supports a different arrangement.
Check file paths and deployment location after the move
During migration, the application source, WAR file, or exploded deployment directory may end up in a new path. If the site loads over HTTP but HTTPS fails, the problem may still be a missing document root mapping or an incorrect virtual host target.
Review whether the following still match the new account structure:
- Document root for the domain.
- Deployment directory for the Java application.
- Context path in Tomcat.
- Alias or subdomain mapping in Plesk.
- Static files or assets loaded from absolute HTTPS URLs.
A frequent case is a JSP or servlet application that loads its main page correctly but fails to load CSS, JavaScript, or API calls because those assets still point to the old location. The browser may report mixed content or blocked requests, which looks like an HTTPS issue even though the certificate itself is valid.
Review mixed content problems
If the page opens on HTTPS but parts of it do not work correctly, mixed content may be the cause. Mixed content means the page is loaded securely, but some resources are still requested over plain HTTP.
Examples of mixed content
- Images loaded from http:// URLs.
- JavaScript files included with old absolute links.
- API endpoints hardcoded to HTTP.
- External resources not updated after the domain move.
Browsers may block these requests or show warnings, which can break login screens, JavaScript validation, or application features. Search your application for old HTTP links and replace them with relative URLs or HTTPS URLs where appropriate.
If the app generates URLs dynamically, ensure that it detects the secure connection correctly through the proxy headers and uses the right scheme.
Practical troubleshooting checklist
Use this checklist to isolate the problem quickly after moving a Java application:
- Open the domain in a browser and note the exact error message.
- Check whether the domain resolves to the new server IP.
- Confirm that the SSL certificate is installed and valid for the current hostname.
- Verify that HTTPS is enabled for the domain in Plesk.
- Check that Apache is running and listening on port 443.
- Confirm that the Java service or Tomcat instance is running in My App Server.
- Review proxy rules and backend port mapping.
- Inspect application configuration for old base URLs or redirects.
- Look for mixed content in the browser console.
- Test both the root domain and www subdomain.
If the application moved to a new subscription or domain mapping, compare the old and new Plesk settings side by side. The quickest fixes are often in SSL activation, domain alias configuration, or the reverse proxy target.
How to fix common HTTPS issues after migration
1. Reissue or reinstall the SSL certificate
If the certificate no longer matches the current domain, generate a new one or reinstall the existing certificate for the correct hostname. Make sure both the main domain and any required aliases are included.
2. Enable SSL for the domain in Plesk
Confirm that the domain has SSL/TLS support enabled and that the correct certificate is selected for the site. If HTTPS was disabled during migration, re-enable it before testing the app.
3. Restart or verify Apache and the Java service
After changes to the site configuration, restart the relevant web and Java services if your hosting environment requires it. In My App Server, ensure that the application server is started and attached to the correct site.
4. Correct the proxy or virtual host settings
If Apache forwards requests to Tomcat, verify that the backend host and port are still valid. A broken proxy target can make HTTPS appear unavailable even when the certificate is correct.
5. Update application URLs
Replace hardcoded HTTP URLs with the current HTTPS domain. Check application properties, environment variables, JSP includes, servlet redirects, and framework settings.
6. Remove stale DNS records
If an old A or AAAA record is still active, remove or update it. Make sure visitors are not being sent to an outdated server with an old certificate.
When the problem is not in the Java application
In many cases, HTTPS errors after migration are caused by the hosting layer rather than the Java code. If the app starts correctly and responds on HTTP but fails on HTTPS, the issue is usually in one of these areas:
- Domain-level SSL configuration
- Apache or proxy settings
- DNS propagation
- Certificate validity
- Base URL or redirect rules
This is why Java hosting troubleshooting often starts with the surrounding services. A working Tomcat application still depends on the right DNS, SSL, and Apache setup to serve secure traffic properly.
Frequently asked questions
Why does my Java app open on HTTP but not HTTPS after migration?
Usually because SSL is not configured correctly on the new hosting account, the certificate does not match the domain, or Apache is not forwarding secure requests to the Java backend.
Do I need to change anything inside Tomcat for HTTPS?
Not always. In many hosting setups, HTTPS is terminated by Apache, not Tomcat. If that is your setup, most fixes are on the web server, certificate, or proxy side rather than inside the Java application.
What if the browser shows a certificate warning?
That usually means the certificate is invalid, expired, not installed for the current hostname, or the domain still points to an old server. Check the SSL certificate and DNS first.
Why does the site keep redirecting between HTTP and HTTPS?
This is often caused by an application redirect rule, a wrong base URL, or proxy headers that do not tell the Java app the request was secure.
Can a DNS change break HTTPS even if the certificate is correct?
Yes. If DNS points to the wrong server, the browser may reach a different machine presenting a different certificate or an outdated site configuration.
Does My App Server support Java and Tomcat hosting on a shared hosting account?
Yes. It is designed for practical Java hosting use cases such as Tomcat, JSP, servlet applications, and private JVM setups within a shared hosting account, with service control through the hosting panel.
Conclusion
HTTPS problems after moving a Java application are usually caused by the hosting configuration around the app, not by the application code itself. The most common causes are DNS errors, SSL certificate mismatch, Apache proxy configuration, or a stale redirect to an old hostname.
In a Plesk-based Java hosting environment with My App Server, the safest approach is to verify the domain, certificate, web server, and Java service one by one. Once the hostname, SSL settings, and backend mapping are aligned, HTTPS should start working again without changes to the Java code.