How to add SSL to a hosted Java website

If your Java application is already running on a hosted Tomcat or private JVM setup, adding SSL is usually the next step before you make it public. In a managed hosting environment with Plesk and a Java extension such as My App Server, the goal is to terminate HTTPS cleanly, keep your application reachable on a secure URL, and avoid breaking redirects, host mappings, or Tomcat context paths.

In most cases, you do not install SSL inside the Java application itself. Instead, you attach an SSL certificate to the domain in your hosting control panel, make sure the web server accepts HTTPS traffic, and then route secure requests to your Java service. This is the standard and safest way to secure a hosted Java website.

What SSL does for a hosted Java website

SSL, more accurately TLS, encrypts traffic between the browser and your site. For a hosted Java website, that usually means:

  • the public domain opens with https:// instead of http://;
  • login forms, contact forms, and API requests are protected in transit;
  • modern browsers stop showing “Not secure” warnings;
  • your site can use secure cookies and HTTPS-only settings;
  • search engines can index the secure URL as the preferred version.

If your Java app uses Tomcat, JSP, or servlets, the certificate is often handled at the web server level, while Tomcat continues to serve the application behind the scenes. In a hosting platform with Plesk and My App Server, this is typically the most practical setup.

Before you add SSL

Check these points first, because they affect how SSL is issued and activated:

  • The domain is pointing to the hosting account and resolves correctly in DNS.
  • The website is published on the correct domain or subdomain, not only on a temporary URL.
  • Port 80 and port 443 are available for the site at the web server level.
  • Your Java service is running in My App Server or your Tomcat setup.
  • You know the main hostname you want to secure, for example example.com or app.example.com.

If your Java app is only intended for a subdomain, it is usually best to issue the certificate for that exact subdomain. If both the root domain and www should work, include both names in the certificate or redirect one to the other consistently.

Common SSL setup options for Java hosting

1. SSL on the hosting control panel and proxy to Tomcat

This is the most common configuration for hosted Java websites. The certificate is installed on the domain in Plesk, Apache or the hosting web layer serves HTTPS, and requests are forwarded to Tomcat or the private JVM application.

Pros:

  • simple to manage from the control panel;
  • no need to maintain certificate files inside the Java app;
  • works well with WAR deployment and standard hosted applications;
  • keeps SSL maintenance separate from the application code.

2. SSL directly in Tomcat

Tomcat can also listen on HTTPS directly if you configure a keystore and connector. This may be useful in some custom setups, especially when you run a private JVM or a custom app server profile.

Pros:

  • direct control inside the Java stack;
  • possible for advanced custom deployments;
  • useful if the application needs a dedicated SSL connector.

However, on hosted shared environments this is often less convenient than panel-based SSL. It can also be harder to maintain, especially when the certificate renews or when the web server already handles TLS termination.

3. SSL via reverse proxy or application front end

Some hosting setups place Apache or another front-end web server in front of Tomcat. In that case HTTPS is terminated at the front end and plain HTTP is passed internally to the Java service. This is a normal and secure pattern when the internal network is isolated inside the hosting platform.

How to add SSL in Plesk for a hosted Java site

The exact labels can differ depending on the hosting template, but the workflow is usually similar.

Step 1: Open the domain in Plesk

Go to the hosting control panel and open the subscription or domain for your Java website. Make sure you are working with the correct domain name, especially if the application is deployed on a subdomain.

Step 2: Issue or install the certificate

Choose one of the following:

  • Let’s Encrypt, if available for the domain and DNS is correct;
  • Upload an existing certificate from a certificate authority;
  • Use a wildcard certificate if you need multiple subdomains secured;
  • Use a certificate with SAN names if several hostnames should be covered.

For a hosted Java application, Let’s Encrypt is often the fastest option if the domain is already active. If you use a custom certificate, make sure you have the correct private key and intermediate chain.

Step 3: Enable HTTPS for the domain

After the certificate is installed, make sure SSL is enabled for the website. In many control panels this means turning on secure hosting for the domain and confirming that HTTPS is available on port 443.

If the site is served through Apache in front of Tomcat, the control panel may automatically connect the certificate to the web vhost. In that case, Tomcat does not usually need a separate certificate unless you explicitly want Tomcat to listen on HTTPS too.

Step 4: Check the Java app service

Open My App Server or the Java service management area and confirm that the application is running normally. SSL should not stop the app from working, but after enabling HTTPS you should verify:

  • the app starts correctly;
  • the correct Tomcat version or JVM profile is selected;
  • the application responds on its normal context path;
  • any internal redirects still point to the right hostname.

If you run a private JVM or custom Tomcat instance, make sure the service is healthy before testing HTTPS. SSL often exposes issues in redirect rules, proxy settings, or absolute URL generation that may not be obvious on plain HTTP.

Step 5: Test the secure URL

Open the site in a browser using https://. Confirm that:

  • the padlock is shown in the browser;
  • the certificate is issued for the correct hostname;
  • the page loads without mixed-content warnings;
  • forms, login pages, and AJAX requests work as expected.

Also check whether http:// still works. In most cases you should redirect all HTTP traffic to HTTPS to avoid duplicate URLs and confusion for visitors and search engines.

How to redirect HTTP to HTTPS

Once SSL is active, the next step is usually a permanent redirect from HTTP to HTTPS. This keeps one canonical URL for the site.

In a hosting environment with Apache or Plesk, this is often handled by a redirect rule or a vhost-level setting. If your Java app is behind a proxy, the redirect should usually happen before the request reaches Tomcat.

Typical redirect goals

  • http://example.com → https://example.com
  • http://www.example.com → https://www.example.com or your preferred canonical host
  • http://app.example.com → https://app.example.com

Use one consistent version of the hostname. If your Java application builds links dynamically, set the canonical base URL in the app configuration so it matches the secure address.

Special notes for Tomcat and Java applications

Absolute URLs in the app

Many Java web applications generate links, redirects, and callback URLs. After enabling SSL, check whether the app still uses http anywhere in:

  • login redirects;
  • password reset links;
  • API callbacks;
  • application-generated email links;
  • embedded assets and scripts.

If you see insecure URLs, update the application’s base URL settings or proxy configuration. This is a common issue when a site moves from testing to public HTTPS delivery.

Proxy headers and secure request detection

If HTTPS is terminated by Apache or the hosting layer before the request reaches Tomcat, your application may need to know that the original request was secure. In such setups, Tomcat usually relies on forwarded headers or proxy settings so that the application can detect:

  • the original protocol is HTTPS;
  • the correct host name;
  • the correct client port.

This matters for redirects, secure cookies, session handling, and URL generation. If your Java app behaves as if it is still on HTTP, review proxy-related settings in the server or application configuration.

Secure cookies and session settings

After SSL is enabled, set cookies to Secure where appropriate. This ensures they are sent only over HTTPS. For authentication-heavy applications, also verify:

  • HttpOnly is enabled where suitable;
  • session timeouts are reasonable;
  • authentication flows do not redirect back to HTTP.

WAR deployment and context paths

If your application is deployed as a WAR file in My App Server or Tomcat, SSL does not change the deployment method. The context path remains the same, but the public URL becomes secure. For example:

  • http://example.com/myapp
  • https://example.com/myapp

Always test the full path after activation, especially if the app uses absolute redirects or loads files from a fixed host name.

How to add SSL directly to Tomcat, when needed

In some custom Java hosting scenarios, you may want Tomcat to handle HTTPS itself. This is more common when you manage a dedicated private JVM or a custom app server profile, and less common for standard hosted sites.

At a high level, you will need:

  • a certificate and private key, usually combined into a keystore;
  • Tomcat connector configuration for port 443 or another secure port;
  • host mapping that points the domain to the service;
  • firewall or service access that allows the HTTPS port.

Because hosted environments often already provide SSL termination through the control panel or front-end web server, this approach should only be used if your hosting setup explicitly supports it and you need it for a specific technical reason. For most standard Java hosting use cases, panel-managed SSL is easier to maintain.

Common problems after adding SSL

The browser shows a certificate warning

This usually means one of the following:

  • the certificate does not match the hostname;
  • the intermediate chain is incomplete;
  • the domain points to the wrong site;
  • an old certificate is still attached to the vhost;
  • the site is opened on www but the certificate only covers the root domain, or vice versa.

The page loads, but some assets are not secure

This is mixed content. A secure HTML page loads one or more insecure resources such as images, scripts, fonts, or CSS files. Update the application so all asset URLs use HTTPS or relative paths.

Redirect loops appear after HTTPS is enabled

This often happens when the app, the proxy, and the web server disagree about whether the request is secure. Check forwarded headers, canonical URL settings, and any redirect rules in Apache, Plesk, or the Java app itself.

The app stops after certificate changes

Normally SSL changes should not stop your Java service. If the service is affected, check whether:

  • the Java app was configured to use its own HTTPS connector;
  • the keystore file was changed or moved;
  • the Tomcat service needs a restart after configuration updates;
  • the custom app server profile has a syntax issue.

HTTPS works on one hostname but not another

Make sure each hostname is covered by the certificate and mapped to the correct domain in the hosting panel. If you use aliases, subdomains, or alternate hostnames, confirm they are all included in the SSL setup.

Best practices for hosted Java SSL setups

  • Use one canonical domain and redirect all others to it.
  • Keep SSL termination in the control panel unless you have a clear reason to configure Tomcat directly.
  • Renew certificates before expiry and confirm auto-renewal works.
  • Test the site after every certificate change, Java version change, or Tomcat service restart.
  • Review application URLs so your Java app consistently uses HTTPS.
  • Check logs if the secure site does not behave as expected.

For smaller and medium Java applications, this approach is usually enough to provide a secure public-facing deployment without adding unnecessary complexity.

When to use My App Server for SSL-enabled Java hosting

If you are using the My App Server extension in Plesk, SSL fits naturally into the hosted Java workflow. The practical advantages are:

  • you can manage Java hosting and the domain certificate in one place;
  • you can run your own Tomcat or private JVM without handling a full enterprise stack;
  • you can choose a suitable Java version for the application;
  • you can deploy WAR, JSP, and servlet applications with a secure public URL;
  • you can keep the service separate from the rest of the shared hosting account while still using standard hosting tools.

This is a good fit for Java websites, internal business tools exposed publicly, small APIs, and lightweight Tomcat-based applications that need HTTPS but do not require complex cluster management.

FAQ

Do I need to install SSL inside my Java application?

Usually no. In hosted environments, SSL is normally installed on the domain in Plesk or the web server layer, then traffic is passed to Tomcat or the private JVM.

Can I use Let’s Encrypt for a hosted Java website?

Yes, if the domain is correctly pointed to the hosting account and the control panel supports automatic certificate issuance for that hostname.

Will SSL change my Tomcat deployment?

No. Your WAR, JSP, or servlet app usually stays deployed the same way. SSL changes how the public URL is served, not the application code structure.

Why does my Java app still show HTTP links after SSL is enabled?

The app may have a hardcoded base URL, missing proxy headers, or old redirect settings. Update the application configuration so it recognises the secure domain.

Can I secure both the root domain and a subdomain?

Yes, if the certificate covers both names. Use a multi-domain certificate, a wildcard certificate, or issue separate certificates depending on the hosting setup.

What is the safest setup for a shared Java hosting account?

For most hosted Java websites, the safest and simplest setup is SSL on the domain in the control panel, with Apache or the front-end web layer terminating HTTPS and forwarding requests to Tomcat.

Conclusion

Adding SSL to a hosted Java website is mostly a domain and web server task, not an application rewrite. In a Plesk-based Java hosting environment with My App Server, the usual process is to install the certificate on the domain, enable HTTPS, verify that Tomcat or your private JVM continues to run normally, and redirect all HTTP traffic to the secure URL.

Once that is done, check for mixed content, update any hardcoded links, and make sure your Java app recognises the secure connection correctly. That gives you a clean HTTPS setup suitable for public-facing Java, Tomcat, JSP, and servlet applications.

  • 0 Users Found This Useful
Was this answer helpful?