If your hosted JSP site is running through Tomcat or a private JVM in Plesk, adding SSL means more than just uploading a certificate. You need to make sure the domain resolves correctly, the certificate matches the hostname, Apache or your Java proxy serves HTTPS, and your JSP application is reachable without browser warnings. In a managed hosting setup, this is usually straightforward once the DNS and web hosting side are aligned.
For JSP hosting platforms that use a control panel such as Plesk and a Java service like My App Server, the usual approach is to secure the public domain with SSL at the web server layer, then forward traffic to the internal Tomcat instance. This keeps your application private, while visitors connect securely over HTTPS.
What SSL does for a hosted JSP website
SSL is the technology behind HTTPS. It encrypts traffic between the browser and your hosting platform, verifies the identity of the site, and helps prevent interception or tampering. For a JSP website, SSL is especially important if the site has login forms, admin pages, checkout flows, API calls, or any personal data.
When SSL is correctly configured, visitors access your site through https:// instead of http://. The browser shows a padlock icon, and the connection is encrypted. If the certificate is missing, expired, or issued for the wrong hostname, browsers may show warnings that reduce trust and can block access in some cases.
How SSL works in a JSP hosting setup
On a hosted JSP platform, the public web address is often handled by Apache or by the hosting platform’s web layer, while the Java application runs inside Tomcat or a private JVM. In that model, SSL is usually terminated at the front-end web server, and requests are passed to the app server internally.
This setup has practical benefits:
- The certificate is managed in one place, usually the control panel.
- Your Tomcat service does not need to expose its own public port directly.
- HTTPS can be enforced for the whole domain, including JSP pages and static content.
- Redirects from HTTP to HTTPS can be configured centrally.
In a My App Server environment, this is a common pattern because it lets you keep the Java runtime isolated while still using standard domain-based HTTPS.
Before you start: check these prerequisites
Before adding SSL to your hosted JSP website, confirm the following:
- The domain is active and points to the hosting account.
- The website is reachable over HTTP before switching to HTTPS.
- You know whether the application is using Apache, Tomcat, or a proxy-based setup.
- Your hosting plan includes SSL support or an issued certificate option.
- You have access to Plesk or the hosting control panel used for the account.
If you use a separate hostname such as www.example.com and example.com, make sure you know which names should be covered by the certificate. A mismatch between the hostname and the certificate is one of the most common causes of SSL errors.
Step 1: make sure DNS points to the hosting platform
SSL installation should come after basic domain setup. Your domain must resolve to the hosted site before browsers can validate and load the secure version properly. Check the A record, AAAA record, or nameserver setup according to your hosting configuration.
If you are moving an existing JSP site to HTTPS, allow enough time for DNS changes to propagate. During this time, some visitors may still reach the old destination if records are not fully updated.
What to verify in DNS
- The root domain and any www alias point to the correct hosting account.
- No conflicting records send traffic to another server.
- Any mail records are left intact if mail is hosted separately.
- The domain in the certificate matches the live hostname.
Step 2: choose the right certificate type
For most hosted JSP sites, a standard domain-validated certificate is enough. It secures the connection and is typically the easiest to issue and renew. If your site has multiple subdomains, a wildcard certificate may be useful. If you only need to secure a few exact hostnames, a multi-domain certificate can be another option.
Choose based on how the site is used:
- Single-domain certificate — best for one hostname, such as example.com.
- Wildcard certificate — covers all first-level subdomains, such as *.example.com.
- Multi-domain certificate — covers several named domains or hostnames.
In a managed hosting environment, a hosted certificate or automatic Let's Encrypt certificate is often the simplest option if your domain is already pointed correctly.
Step 3: issue or install the SSL certificate in Plesk
Most hosted sites can be secured directly from the control panel. In Plesk, the certificate is usually attached to the domain, then applied to the web hosting configuration for that site. The exact menu names may differ depending on the hosting platform, but the logic is the same.
Typical SSL setup flow
- Open the domain in the hosting control panel.
- Go to the SSL/TLS or security section.
- Request a new certificate or upload an existing certificate, private key, and CA chain.
- Assign the certificate to the domain.
- Enable HTTPS support for the site.
If your platform supports automatic certificate issuance, use it whenever possible. This reduces manual errors and makes renewal easier. If you are uploading your own certificate, double-check that the private key matches the certificate and that the full chain is complete.
Step 4: connect HTTPS to the JSP application
Once the domain is protected with SSL, the next step is to ensure your JSP application is served correctly through the secure hostname. In many hosting setups, Apache handles HTTPS and forwards requests to Tomcat or the private JVM behind the scenes. That means your JSP app may already work over HTTPS as soon as the domain-level certificate is active.
If your application uses a custom app server or My App Server configuration, confirm that the site is bound to the correct domain and port mapping. The public-facing URL should remain the same, while the internal Java service continues running separately.
Things to check in a Tomcat-based setup
- The app responds correctly when accessed through the HTTPS domain.
- Session cookies are marked secure if your application requires it.
- Absolute links inside JSP pages use https:// or relative paths.
- Any callback URLs, login redirects, or API endpoints use the secure hostname.
If the application contains hardcoded HTTP links, browsers may show mixed content warnings even when SSL is installed correctly. This is very common in JSP apps with old templates or manually written links.
Step 5: force HTTP to HTTPS redirects
Installing SSL is only half of the job. To ensure all visitors use the secure version, redirect HTTP traffic to HTTPS. This also helps search engines consolidate ranking signals on the secure URL version.
In a hosted Apache or Plesk environment, the redirect is often configured at the domain level. Some platforms provide a checkbox or built-in redirect option. Others require a rule in the site configuration.
What the redirect should do
- Send every http:// request to the equivalent https:// URL.
- Preserve the path and query string.
- Redirect permanently where appropriate, so browsers and search engines cache the secure version.
Example outcome:
http://example.com/login should redirect to https://example.com/login.
Be careful not to create redirect loops. This can happen if both Apache and the application try to force HTTPS in different ways, or if the proxy settings are inconsistent.
Step 6: update the JSP application for secure URLs
After SSL is active, review the application itself. JSP websites often generate links, form actions, and redirects dynamically, so they should be checked for anything that still points to HTTP.
Common places to update
- Navigation menus and footer links.
- Form action URLs in JSP pages.
- Login and logout redirects.
- JavaScript files that call API endpoints.
- Embedded images, fonts, or CSS loaded from absolute URLs.
If your app uses request URL generation inside JSP or servlets, make sure it respects the secure scheme when the request comes through HTTPS. In proxy-based hosting, the application may need to trust forwarded headers so it can detect the original protocol correctly.
Step 7: fix mixed content warnings
Mixed content occurs when the main page loads over HTTPS but some resources still load over HTTP. Modern browsers may block these resources or mark the page as unsafe. For JSP applications, this often affects stylesheets, scripts, images, fonts, and embedded widgets.
To resolve mixed content:
- Replace hardcoded HTTP links with relative or HTTPS links.
- Update template files, JSP fragments, and shared includes.
- Check external libraries and CDN references.
- Search the source code for http:// references.
If a third-party resource does not support HTTPS, replace it with a secure alternative. Leaving one insecure asset in place can make the page appear partially broken or reduce browser trust.
Step 8: test the SSL installation
After setup, test the site carefully from a browser and, if possible, from an SSL checker. You want to confirm that the certificate is valid, the hostname matches, the chain is complete, and HTTP redirects to HTTPS correctly.
What to test
- The secure site loads without browser warnings.
- The certificate name matches the domain and www alias if needed.
- HTTP redirects to HTTPS.
- Login forms, session handling, and file uploads still work.
- No mixed content warnings appear in the browser console.
Also test important application flows such as registration, password reset, and admin pages. JSP applications often have multiple entry points, and one overlooked URL can still point to an unsecured location.
How SSL usually fits with My App Server and Tomcat hosting
If your JSP site runs on ITA’s My App Server platform, SSL is generally applied to the public domain while the Java runtime remains managed separately. This is useful because you can keep control over Java version, service start and stop, and deployment of WAR or JSP applications without exposing the internal service directly.
In this model, the hosting platform can provide:
- A controllable Tomcat or private JVM service inside the hosting account.
- A chosen Java version, depending on what your app requires.
- Domain-level SSL management through the control panel.
- A cleaner separation between public web traffic and application runtime.
This approach works well for small and medium JSP or servlet applications that need practical control without the complexity of a large enterprise Java stack.
Common problems and how to solve them
The browser says the certificate is not trusted
This usually means the certificate is missing, expired, installed for the wrong hostname, or not linked with the full certificate chain. Check the domain assignment in the control panel and confirm that the certificate covers the exact public URL your visitors use.
HTTPS loads, but the site looks broken
This often points to mixed content or an application that still generates HTTP links. Search the JSP code, layout templates, and JavaScript files for hardcoded links and replace them with secure URLs.
HTTP and HTTPS both work, but search engines see two versions
Set a permanent redirect from HTTP to HTTPS and make sure your canonical URLs point to the secure version. Update sitemap files and any internal references in the application.
The JSP app redirects in a loop
Redirect loops usually happen when the app and the web server both try to force HTTPS without agreeing on the current request scheme. Review proxy headers, forwarding configuration, and any application-level HTTPS logic.
My app works on HTTP but fails on HTTPS after login
Check cookie settings, session handling, and any absolute callback URLs. Some applications need secure cookie flags or updates to redirect targets after authentication.
Security best practices for hosted JSP websites
Once SSL is active, use the opportunity to tighten the site configuration:
- Keep only HTTPS accessible for the public site.
- Use modern TLS settings provided by the hosting platform.
- Renew certificates before they expire.
- Remove unused aliases and outdated hostnames from the certificate request.
- Audit JSP pages for insecure external resources.
- Use secure session cookies and sane timeout values where appropriate.
For managed hosting, it is usually best to keep SSL management at the domain level and let the platform handle the web server integration. That reduces manual configuration drift and makes renewals easier.
FAQ
Do I need a separate SSL certificate for Tomcat?
Not always. In many hosted JSP environments, SSL is terminated at Apache or the front-end layer, and Tomcat receives traffic internally. If the hosting platform is already serving the domain over HTTPS, a separate Tomcat certificate is often unnecessary.
Can I use Let’s Encrypt for a hosted JSP website?
Yes, if your hosting platform supports it and your domain points correctly to the account. It is a common choice for JSP hosting because it is easy to issue and renew automatically.
Will SSL affect my JSP deployment?
Usually no, but you may need to update absolute URLs, redirects, and cookies inside the application. The WAR or JSP deployment itself normally stays the same.
What if my site uses both www and non-www?
Make sure the certificate covers both names or redirect one to the other consistently. The public site should use one preferred canonical hostname.
Do I need to change my Tomcat port?
Not necessarily. In most managed hosting setups, the public HTTPS connection is handled outside Tomcat. The internal app server port can remain unchanged unless your hosting instructions say otherwise.
Why do I still see “Not secure” after installing SSL?
This usually happens because some page content is still loaded over HTTP, the certificate does not match the visited hostname, or the browser is being served a cached version of the old page. Check for mixed content and verify the redirect.
Conclusion
Adding SSL to a hosted JSP website is mostly about connecting the domain, certificate, and application layer in the right order. Start with DNS, issue or install the certificate in the hosting control panel, ensure the HTTPS site points to the JSP application correctly, and then redirect all HTTP traffic to HTTPS. After that, review your JSP pages for hardcoded links and mixed content so the secure version works cleanly in every browser.
In a Plesk-based Java hosting setup with My App Server and Tomcat, this approach gives you a practical balance: secure public access for visitors, controlled Java runtime management, and a simpler workflow for JSP and servlet applications.