Why does a Tomcat website still show Not Secure after SSL setup in the UK

If your Tomcat website still appears as Not Secure after SSL setup, the certificate may be installed correctly but the page is still loading some content over HTTP, using the wrong hostname, or being served through a Tomcat configuration that has not been fully switched to HTTPS. In a managed hosting environment, especially when using Plesk and a private Tomcat / JVM service such as My App Server, the fix is usually straightforward once you identify where the non-secure reference is coming from.

This article explains the most common causes for Tomcat sites showing “Not Secure” in the UK, how to check them, and what to change in Apache, Tomcat, Plesk, DNS, and application settings so your public-facing site loads fully over HTTPS.

Why a Tomcat site can still show “Not Secure” after SSL is installed

Browsers display a site as secure only when the entire page and its critical resources are delivered correctly over HTTPS. Even if the SSL certificate itself is valid, the page may still be flagged as not secure for one of these reasons:

The website is still opening on http:// instead of https://.
The page loads images, CSS, JavaScript, fonts, or API calls over HTTP.
The Tomcat application generates absolute links with the old protocol or hostname.
Apache is terminating SSL, but Tomcat is not receiving the correct secure request information.
The certificate is issued for a different hostname, such as www vs non-www.
There is a redirect loop, mixed content, or a browser cache issue.

For Tomcat hosting, the most common cause is mixed content: the SSL certificate is active, but the application still references non-secure URLs in JSPs, templates, JavaScript, or backend-generated links.

First check: is the SSL certificate actually installed on the correct hostname?

Before changing Tomcat settings, verify that the certificate is assigned to the exact domain the site uses. This matters because browsers check the hostname in the address bar against the certificate name.

Check these points in Plesk or your control panel

The certificate is assigned to the correct domain or subdomain.
The site opens on the same hostname covered by the certificate.
Both www and non-www versions are handled consistently.
The certificate chain is complete and not expired.
The browser is not loading a cached old certificate from a previous setup.

If you use a Tomcat application behind Apache in a hosting control panel, SSL is often configured on the web server side rather than directly inside Tomcat. That means the certificate can be valid, while Tomcat still needs to know that requests are secure.

Most common reason: mixed content on the page

Mixed content means the main page loads over HTTPS, but one or more resources still load over HTTP. Modern browsers may show a warning, a broken padlock, or “Not Secure” depending on the resource type and browser policy.

Typical mixed content examples

http:// links in CSS files
Image URLs hard-coded with HTTP in JSP templates
JavaScript fetching APIs over HTTP
Embedded fonts or icons from insecure URLs
External widgets or analytics scripts loaded through HTTP

How to check for mixed content

Open the site in a browser.
Press F12 to open developer tools.
Go to the Console or Security tab.
Look for messages about insecure resources.
Refresh the page and note which URLs are being blocked or warned about.

How to fix it

Replace all http:// links with https://.
Use protocol-relative or root-relative URLs where appropriate.
Update template files, JSPs, JavaScript, CSS, and configuration files.
Check backend code that builds absolute URLs.
Rebuild and redeploy the application after changing references.

If your Tomcat site is generated from JSP or servlet code, pay special attention to any code that constructs links from request values. A small hard-coded HTTP reference can keep the browser from showing the site as fully secure.

Check whether the site is redirecting from HTTP to HTTPS correctly

Some websites are secure only after the user manually types https://. If the main URL still opens on http://, the browser may continue to show a warning, especially if redirects are incomplete or inconsistent.

What the redirect should do

Redirect all HTTP traffic to HTTPS.
Use one preferred hostname, either www or non-www.
Avoid redirect chains with multiple hops.
Preserve the full path and query string.

Where redirects are usually configured

Apache virtual host or site configuration
.htaccess file if allowed
Plesk hosting settings
Application-level redirect code

For Tomcat hosting, it is usually best to handle the public redirect at the web server layer when possible. That keeps the app simpler and avoids duplicate redirect logic inside the Java application.

Apache and Tomcat can be split between HTTPS termination and application delivery

In many managed hosting setups, Apache handles the public HTTPS connection and proxies traffic to Tomcat or a private JVM service. This is common in Plesk-based Java hosting setups, including managed Tomcat services like My App Server.

In that architecture, the certificate may be installed on Apache, while Tomcat runs behind it. If Tomcat does not know the original request was secure, it may generate insecure links or incorrect redirects.

What to check in a proxy setup

Apache is configured to serve HTTPS on the public hostname.
Tomcat receives headers such as X-Forwarded-Proto when needed.
The application respects the forwarded scheme and hostname.
Redirect rules do not send the browser back to HTTP.

Common symptoms of a proxy misconfiguration

The login page works, but links point back to HTTP.
The app creates absolute URLs with the wrong protocol.
Secure cookies do not behave as expected.
Forms submit to an insecure address.

If your site is using a private JVM or Tomcat service through the control panel, make sure the service is operating behind the intended web front end and that the app’s own URL settings match the public HTTPS address.

Tomcat-specific settings that can cause “Not Secure”

Tomcat applications often generate links based on request metadata. If the app thinks the request is plain HTTP, it may create insecure absolute URLs even when the browser connected through HTTPS.

Things to review in the application

Base URL or site URL settings in the app configuration
Environment variables used for generating links
Servlet filters that rewrite URLs
Reverse proxy support in the app framework
Authentication redirects and callback URLs

If the application uses Java framework settings

Some Java frameworks need explicit configuration to trust reverse proxy headers. If this is missing, the app may build URLs using the internal Tomcat address rather than the public HTTPS address.

Review whether your framework needs settings for:

forwarded headers
secure request detection
canonical site URL
context path handling

For JSP and servlet applications, the issue is often in a link-building helper, redirect logic, or a shared layout template.

Make sure the certificate covers all hostnames you use

A site can look insecure if users land on a hostname that is not covered by the certificate. This often happens when one version of the site redirects to another version, but the target hostname is not included in the certificate or DNS setup.

Examples

example.co.uk redirects to www.example.co.uk, but the certificate only covers the root domain.
The application uses a subdomain such as app.example.co.uk that is not covered by the SSL certificate.
The site is accessed through an old alias, parked domain, or temporary hostname.

To avoid this, align the following:

DNS records
certificate names
preferred site URL
redirect rules

Browser cache, HSTS, and old redirects can confuse the result

Sometimes the SSL setup is correct, but the browser still shows old warnings because it cached an earlier version of the site. This is common after changing certificates, redirects, or proxy settings.

Try these checks

Open the site in an incognito or private window.
Clear browser cache for the domain.
Test in a second browser.
Check from a different device or network.

If you previously had a broken HTTPS setup, browser history or HSTS state can make the problem appear to continue even after the fix has been applied.

Step-by-step troubleshooting checklist

Use this checklist to identify why your Tomcat website still shows “Not Secure” after SSL setup.

Open the website with https:// directly.
Check whether the certificate matches the exact hostname.
Look for mixed content warnings in the browser console.
Confirm the site redirects from HTTP to HTTPS.
Verify that only one preferred hostname is used.
Review Apache proxy or reverse proxy settings.
Check Tomcat or application URL generation logic.
Replace any hard-coded HTTP links in templates, JSPs, or scripts.
Test again in a private browser window.

How this applies to My App Server and Plesk-based Java hosting

In a managed Java hosting setup with My App Server, the application usually runs as a private Tomcat / JVM service controlled from the hosting panel. This makes it practical to host JSP, servlet, and WAR-based applications without managing a full standalone Java infrastructure.

For SSL troubleshooting, the main advantage is that you can usually separate the problem into three layers:

DNS and hostname — does the domain point to the correct site?
Web server / SSL layer — is HTTPS active and the certificate valid?
Application layer — is Tomcat or the Java app generating secure URLs?

If you can access service controls in the panel, check whether the application service is running normally, whether the correct Tomcat version is selected, and whether your deployment uses the expected virtual host or context path. In many cases, the SSL problem is not in Tomcat itself but in how the application was written or how Apache proxies requests to it.

Best practices to avoid the problem in future

Set the preferred URL early during deployment.
Use HTTPS links everywhere in the application.
Store one canonical base URL in configuration.
Test mixed content after every release.
Ensure redirect rules are consistent across Apache and the app.
Check all subdomains and aliases before going live.
Keep the certificate assignment aligned with DNS changes.

For Tomcat and JSP applications, it is also a good idea to review any shared header, footer, or layout files. A single insecure external resource in a shared template can affect the entire site.

Frequently asked questions

Why does the padlock disappear even though the certificate is valid?

Usually because the page loads one or more resources over HTTP. The certificate may be valid, but the browser marks the page as not fully secure due to mixed content.

Does Tomcat need its own SSL certificate?

Not always. In many hosting setups, SSL is terminated at Apache or the front-end web server. Tomcat may sit behind it and serve the application traffic internally. What matters is that the public site is served consistently over HTTPS and Tomcat knows when a request is secure.

Can a Java app generate insecure links even after SSL is installed?

Yes. If the app builds absolute URLs from incorrect settings or does not trust proxy headers, it may still output http:// links.

Why does the site work in one browser but not another?

Browser cache, old redirects, stored HSTS state, or different mixed content handling can cause different behaviour. Test in a private window and compare results.

What should I fix first?

Start with mixed content and redirect settings. Those are the most common causes for a Tomcat website still showing “Not Secure” after SSL setup.

Conclusion

If your Tomcat website in the UK still shows Not Secure after SSL setup, the certificate is often only part of the solution. The issue is usually caused by mixed content, incomplete redirects, hostname mismatch, or application settings that still generate HTTP links. In a Plesk-based Java hosting environment with a private Tomcat service, the fix normally involves checking both the web server layer and the Java application layer together.

Once the site uses one correct hostname, redirects all traffic to HTTPS, and removes any insecure resource references, the browser should display the site as secure. If the problem persists, focus on the application code and proxy settings, because that is where Tomcat sites most often keep old HTTP references after an SSL change.

Why does a Tomcat website still show Not Secure after SSL setup in the UK?