Why is HTTPS not working after moving a JSP application?

If your JSP application was working over HTTPS before the move and now the secure version does not load correctly, the problem is usually not the JSP code itself. In most hosting setups, HTTPS issues after migration are caused by one of the surrounding services: the SSL certificate, domain DNS, Apache virtual host routing, proxy rules, or Tomcat being bound to the wrong host name or port. In a managed hosting environment with Plesk and a Java hosting layer such as My App Server, the fix is often in the web server and SSL configuration rather than in the application files.

This article explains how to check the most common causes of HTTPS failures after moving a JSP application, how SSL is typically wired in a Tomcat hosting setup, and what to verify in Plesk or a control panel when your secure site shows certificate warnings, redirects to HTTP, or fails to open altogether.

What usually breaks HTTPS after moving a JSP application

When a JSP application is moved to a new hosting account or a different server, HTTPS can stop working for several reasons:

  • The SSL certificate was not installed on the new hosting account.
  • The domain points to the new server by DNS, but the certificate still matches the old host name or a different alias.
  • The application was moved, but the Apache or reverse proxy configuration was not updated for the secure vhost.
  • Tomcat is serving the app, but the application or framework still generates absolute http:// links.
  • A redirect rule sends users from HTTPS back to HTTP.
  • The app relies on a context path, proxy header, or port mapping that changed during migration.
  • The certificate chain is incomplete or the browser does not trust the installed certificate.

In JSP and Tomcat hosting, HTTPS is usually handled at the web server layer, while the application runs behind it in a private JVM or Tomcat service. That means the application may be healthy, but the secure connection can still fail because the front-end SSL termination is misconfigured.

Check whether the domain points to the correct hosting account

Before changing anything in the application, confirm that the domain resolves to the new hosting environment. After migration, DNS propagation or a wrong A record is a common reason why HTTPS appears broken.

What to verify

  • The domain A record points to the correct IP address.
  • Any www record points to the same host or is redirected consistently.
  • The domain is attached to the correct subscription, site, or domain in Plesk.
  • The secure URL uses the same host name that the certificate was issued for.

If the browser opens the old server, a parking page, or a different site, the SSL certificate problem may only be a symptom. Fix the DNS or hosting binding first, then test HTTPS again.

Confirm that the SSL certificate is installed for the new site

After a move, certificates are often forgotten because the files and the application were transferred, but the certificate was not. In managed hosting, SSL must be reissued or reattached to the new domain configuration if the host name, account, or server identity changed.

What to check in the control panel

  • The certificate is assigned to the correct domain.
  • The certificate covers both the apex domain and any www alias if needed.
  • The private key matches the certificate.
  • The intermediate chain is installed correctly.
  • The certificate has not expired.

In Plesk, open the domain’s SSL/TLS settings and verify the active certificate. If you use a Let’s Encrypt certificate, issue it again for the new environment if the previous one was tied to a different setup. If the certificate is self-signed, browsers will show warnings unless it is trusted manually, so this is usually not appropriate for public production sites.

Make sure Apache is serving the secure host correctly

For JSP hosting, Apache often acts as the public entry point while Tomcat or a private JVM handles the application logic. HTTPS can fail if Apache is not listening on port 443 for the domain, if the secure virtual host is missing, or if the proxy configuration points to the wrong backend.

Typical Apache-side checks

  • Port 443 is enabled.
  • The SSL vhost exists for the domain.
  • The certificate path in the vhost is correct.
  • Proxy rules still point to the running Tomcat instance.
  • Rewrite rules do not force a broken redirect loop.

If the application was moved between environments, the host name in Apache configuration may no longer match the new domain. This can lead to the default SSL site being shown instead of your application, or to a certificate mismatch warning.

Check Tomcat and My App Server binding settings

In a Java hosting platform using My App Server, your JSP application may be deployed in a private Tomcat instance or a dedicated JVM within the hosting account. After migration, the service may still be running, but not on the expected port, context path, or virtual host.

Review these Tomcat-related items

  • The Tomcat service is running.
  • The application is deployed in the correct context.
  • The backend connector port matches the Apache proxy setup.
  • The server name or virtual host configuration matches the public domain.
  • The Java version selected for the app is compatible with the application.

If your hosting plan supports multiple Java/Tomcat versions, confirm that the app is started with the same or a compatible version as before. A version mismatch can cause startup errors that look like HTTPS or site availability problems, even though the real issue is application initialization.

Look for redirect loops between HTTP and HTTPS

One of the most common post-migration problems is a redirect loop. The site may open and then bounce between secure and insecure URLs, or the browser may report that the page redirected too many times.

This often happens when the application or Apache rules enforce HTTPS, but the proxy or application server does not correctly detect that the original request was already secure.

Common causes of redirect loops

  • Both Apache and the application force HTTPS.
  • The app checks a header such as X-Forwarded-Proto, but the proxy no longer sends it.
  • The application reads the wrong scheme because SSL terminates before Tomcat.
  • A hardcoded redirect sends users back to http://.

Check any rewrite rules, web.xml security constraints, Spring Security settings, or framework-level redirect logic. If the hosting platform terminates SSL at Apache and forwards traffic to Tomcat internally, the application must be aware that the original request was HTTPS.

Verify application-generated URLs and absolute links

Even when the certificate is correct, the page may still appear broken if the JSP app generates links that point to the wrong protocol or host. This happens after a move when the application still contains the old domain name, port, or scheme in templates, configuration files, or database content.

Search for hardcoded values

  • http:// links inside JSP files
  • Old domain names in configuration properties
  • Absolute URLs in JavaScript, CSS, or image references
  • Legacy callback URLs, login URLs, or API endpoints

Where possible, use relative URLs or application settings that build links from the current request. If the app must generate full URLs, make sure it uses the correct secure base URL after the move.

Check for mixed content problems

Sometimes HTTPS technically works, but the browser shows warnings or blocks parts of the page. This is usually mixed content: the main page loads over HTTPS, but images, scripts, CSS files, or AJAX requests are still loaded over HTTP.

This is especially common after migration if static resources are referenced by absolute URLs or if the application was configured for a different domain.

How to spot mixed content

  • The page loads, but styles or images are missing.
  • The browser console shows blocked insecure requests.
  • Some buttons or login forms do not work securely.

Update the resource paths so that they use HTTPS or relative URLs. In hosted JSP applications, this is often the fastest way to restore a clean secure page after the move.

Confirm that the application is aware of the proxy and SSL termination

In many hosting environments, SSL is terminated at Apache or a front proxy, while Tomcat receives internal HTTP traffic. This is normal, but the application must understand the original request scheme if it builds redirects, absolute links, or secure cookies.

Helpful headers and settings

  • X-Forwarded-Proto for the original scheme
  • X-Forwarded-Host for the public host name
  • X-Forwarded-Port if port mapping matters
  • Tomcat proxy configuration or connector settings

If these headers are missing or ignored, the app may believe it is running on HTTP even though visitors are using HTTPS. That can cause redirect loops, insecure cookie flags, or incorrect generated URLs. In a private JVM or My App Server setup, verify the Apache-to-Tomcat handoff after migration.

Test the certificate and host name from the browser and command line

A practical diagnosis is to check both the browser and the actual certificate presented by the server. If possible, test the host with a secure URL and inspect the certificate details.

What to inspect

  • The certificate common name and SAN entries match the domain.
  • The browser is not showing a mismatch between host and certificate.
  • The certificate chain is complete.
  • The secure site responds on port 443.

If the certificate looks correct but the site still fails, the issue is likely in the virtual host, proxy, or application routing rather than in the certificate itself.

Use this step-by-step troubleshooting order

If you are not sure where the issue is, use this order to isolate it quickly:

  1. Check DNS and confirm the domain points to the new hosting account.
  2. Open the site directly with https:// and note the exact browser error.
  3. Verify that the SSL certificate is installed for the domain.
  4. Confirm the certificate matches the host name you are using.
  5. Check whether Apache is serving the domain on port 443.
  6. Confirm the Tomcat or My App Server service is running.
  7. Review proxy and rewrite rules for redirect loops.
  8. Inspect the application for hardcoded HTTP links or old domain references.
  9. Test for mixed content in the browser console.

This sequence usually reveals whether the problem is at the DNS layer, SSL layer, web server layer, or application layer.

Examples of common symptoms and their likely cause

Browser says the certificate is for a different site

This usually means the wrong SSL certificate is attached, the domain points to the wrong account, or Apache is serving the default SSL vhost instead of the intended site.

Site opens on HTTP but not HTTPS

Port 443 may not be enabled, the SSL certificate may be missing, or the secure virtual host may not be configured after the move.

HTTPS keeps redirecting back to HTTP

Look for redirect rules in Apache, Tomcat, or the JSP application. Also check whether the app is aware of proxy headers such as X-Forwarded-Proto.

Site loads but images and scripts are broken

This is usually mixed content or hardcoded HTTP resource URLs in the application.

Application starts, but secure login fails

The session cookie may not be marked correctly for HTTPS, or the app may be building login redirects with the wrong scheme or host name.

How My App Server and Plesk help in this situation

In a hosting platform that provides Java hosting through a Plesk extension such as My App Server, the main benefit is that the application server can be managed separately from the public web site. This makes it easier to deploy a private Tomcat instance, choose an appropriate Java version, and control the service without touching the whole server stack.

That said, HTTPS still depends on the surrounding services:

  • Plesk domain configuration must match the public site name.
  • The SSL certificate must be attached to the correct domain.
  • Apache must route the secure request to the right backend.
  • The Tomcat service must listen on the expected internal endpoint.
  • The application must generate URLs that match the secure host.

If you moved a JSP app into a My App Server environment, think of HTTPS as a chain: DNS, certificate, Apache, Tomcat, application code. A break in any one of these layers can make the site appear down.

FAQ

Why did HTTPS work before the migration but not after?

Because the SSL setup is often tied to the domain and hosting configuration, not just the application files. When the app is moved, the certificate, DNS, proxy, or vhost settings may not be recreated exactly.

Do JSP files themselves control HTTPS?

Not directly. JSP pages can generate redirects and links, but the actual HTTPS connection is handled by the web server, SSL certificate, and proxy configuration.

Can Tomcat run HTTPS on its own?

Yes, but in many hosting environments HTTPS is terminated by Apache or a proxy in front of Tomcat. In a managed hosting setup, this is often the standard arrangement.

Why does my browser show a certificate mismatch?

The domain you are visiting does not match the certificate name, or the server is presenting the wrong certificate. Check DNS, vhost selection, and the installed SSL certificate.

What if the site loads on HTTPS but styles are missing?

That is usually mixed content. Update insecure resource links so that all assets load over HTTPS or use relative URLs.

Should I change Tomcat settings or the Apache SSL config first?

Start with DNS and certificate checks, then verify Apache, and only after that review Tomcat and application-level redirects. This avoids changing the wrong layer first.

Conclusion

If HTTPS stops working after moving a JSP application, the cause is usually in the hosting configuration rather than the JSP code itself. The most common fixes are to reattach the SSL certificate, confirm the domain points to the right account, check the Apache secure virtual host, verify Tomcat or My App Server bindings, and remove redirects or hardcoded links that still assume HTTP or the old domain.

In a Java hosting environment with Plesk and a private Tomcat service, the safest approach is to troubleshoot from the outside in: domain, SSL, web server, proxy, then application. Once each layer matches the new hosting setup, HTTPS should work normally again.

  • 0 Users Found This Useful
Was this answer helpful?