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

If a JSP website still shows Not Secure after you have installed SSL, the problem is usually not the certificate itself. In most cases, the browser is warning about something on the page that is still being loaded over HTTP, or the site is not fully redirecting to HTTPS. For JSP hosting, especially when the application runs behind Apache, Tomcat, or a managed control panel such as Plesk, the cause is often a mix of application URLs, server configuration, and cached browser data.

For UK-based websites, the expectation is simple: once SSL is installed, visitors should see the padlock and the site should load securely by default. If that does not happen, the fix usually involves checking the certificate status, forcing HTTPS, correcting absolute URLs inside the JSP application, and making sure Tomcat and Apache are both aware of the secure request.

Why a JSP site can still show Not Secure after SSL setup

A valid SSL certificate only proves that the connection can be encrypted. It does not automatically make every part of your JSP site secure. Browsers will still warn if the page contains insecure elements or if the site is not fully using HTTPS.

The most common reasons are:

The site still loads some images, CSS, JavaScript, or fonts over http://.
The homepage redirects to HTTPS, but internal links still point to HTTP.
The JSP application generates absolute URLs using the wrong protocol.
Apache or Tomcat is not correctly passing the secure request to the application.
The certificate is installed, but the browser is seeing a mixed-content warning.
The server is using an outdated redirect rule or a cached redirect.
The certificate chain is incomplete or the hostname does not match the site URL.

In a managed hosting environment with Plesk and a My App Server setup, these issues are usually manageable without moving to a different platform. The key is to review both the web server layer and the JSP/Tomcat application layer.

Check whether the certificate is actually valid for the website

Before changing application code, confirm that SSL is correctly installed for the exact hostname your visitors use. A certificate can be valid for one domain and still leave another version of the site insecure.

What to verify

The certificate covers the correct hostname, for example www and/or the non-www version.
The certificate is not expired.
The full certificate chain is installed.
The browser is visiting the HTTPS version of the same hostname that the certificate covers.

If your JSP application opens on https://example.co.uk but redirects internally to http://example.co.uk or to a different alias, the browser may still warn. For a UK website, this often happens when the application canonical URL and the SSL hostname are not aligned.

Look for mixed content in the JSP application

Mixed content is one of the most common reasons for the Not Secure label after SSL setup. This happens when the main page is loaded over HTTPS, but one or more resources are still requested over HTTP.

Common mixed content examples

<img src="http://...">
<script src="http://...">
<link rel="stylesheet" href="http://...">
AJAX calls to HTTP endpoints
Embedded fonts, analytics, or third-party widgets using HTTP

Even one insecure resource can cause the browser to mark the page as not fully secure. In JSP applications, this often comes from:

hardcoded URLs inside JSP files
template fragments shared across pages
older JavaScript files
build-time configuration values

How to fix mixed content

Open the site in the browser and use Developer Tools.
Check the Console for mixed content warnings.
Search your JSPs, HTML templates, and JavaScript for http://.
Replace insecure links with https:// or with protocol-relative or relative URLs where appropriate.
Update external integrations so they also support HTTPS.

If your site uses a shared header or footer JSP, fixing the URL there can solve the issue across the whole application.

Force HTTPS for all requests

Installing SSL is only one part of the process. You should also ensure that every request to the HTTP version is redirected to HTTPS. If the HTTP version remains available, browsers may still land on the insecure URL through bookmarks, old links, or search results.

What a proper redirect should do

Send http:// traffic to https://
Preserve the full path and query string
Use a permanent redirect when appropriate
Avoid redirect loops

In Apache-based hosting, this is usually handled in the site configuration or .htaccess. In a Plesk environment, the redirect can often be set at the domain level. If your JSP application runs through a private Tomcat service managed by My App Server, the redirect may need to be applied at the Apache layer in front of Tomcat, not only inside the application.

Things to check in redirects

The redirect is applied to the correct domain and alias.
There are no competing rules in .htaccess and the control panel.
The site does not redirect HTTPS back to HTTP by mistake.
The application does not issue its own redirect after Apache already redirected the request.

Check how Tomcat sees the request

For JSP hosting, the browser does not talk directly to your JSP files. The request usually passes through Apache and then to Tomcat, or to a Tomcat service configured through a control panel extension such as My App Server. If Tomcat does not know that the original request arrived via HTTPS, the application may generate insecure links.

Typical symptoms

Login pages or form submissions jump back to HTTP.
Generated absolute links in JSP show the wrong protocol.
Session cookies are not marked as secure where expected.
Framework-generated URLs do not reflect HTTPS correctly.

What to inspect

Whether Apache forwards the original scheme correctly.
Whether Tomcat is configured to trust the proxy headers.
Whether the application uses request data to build links.
Whether the site is behind a reverse proxy or SSL termination layer.

In a managed JSP hosting setup, the most practical approach is usually to make sure Apache handles the HTTPS connection and forwards the correct headers to Tomcat. This allows the application to generate secure links consistently.

Review absolute URLs inside JSP pages

Many JSP sites show Not Secure because the application itself builds links in a way that still assumes HTTP. This is especially common in older applications or custom code.

Examples of risky patterns

Hardcoded domain names in JSP pages
Links built without checking the current request scheme
Configuration values that still point to http://
Redirects generated from outdated environment settings

Where possible, use relative paths for internal resources. This reduces the chance of protocol mismatch and makes the site easier to maintain. For external links, verify that the target site supports HTTPS and update the URL accordingly.

Practical checklist for JSP code

Search templates for http://yourdomain.
Check JavaScript files loaded by the JSP application.
Review configuration properties used for public URLs.
Make sure canonical URLs match the SSL-enabled hostname.

Check Apache and .htaccess rules

In hosting environments that use Apache in front of Tomcat, SSL problems are often caused by web server rules rather than the JSP application itself. A faulty redirect or rewrite rule can keep sending visitors to the insecure URL or create a loop between HTTP and HTTPS.

What to look for

Redirect rules that force the wrong hostname
Multiple conflicting HTTPS rules
Old rules copied from a previous migration
Rewrite conditions that do not recognise proxied HTTPS traffic

If you manage the domain through Plesk, check the domain-level SSL and hosting settings first. Then review any custom Apache directives or .htaccess rules added by the application. A simple redirect is often enough, but it should be implemented in one place only.

Clear browser cache and test in a private window

Sometimes the certificate and redirects are already correct, but the browser is showing an older version of the site. This is common after SSL changes, especially when the site was previously accessible only over HTTP.

Do this first

Open the site in a private or incognito window.
Test in another browser.
Clear cached images and scripts if needed.
Confirm that the URL bar shows https://.

If the site looks secure in a clean browser session, the remaining issue may only be local cache. If the warning still appears, continue checking mixed content and redirects.

Use the browser developer tools to find the exact issue

The browser usually tells you why the site is not fully secure. This is faster than guessing. Open Developer Tools and inspect the Console and Network tabs.

What you may see

“Mixed Content” warnings
Blocked insecure resources
Redirects from HTTPS to HTTP
Requests to old subdomains or asset URLs

If the browser reports blocked resources, the page may still load, but it will not be considered fully secure. Fixing the listed URLs normally resolves the warning immediately.

Special notes for JSP hosting with My App Server

When a JSP or Tomcat application is hosted through My App Server, the setup is designed for practical Java hosting rather than large enterprise architectures. That means the most effective SSL troubleshooting usually focuses on:

the domain SSL settings in the control panel
Apache-to-Tomcat request handling
the Java/Tomcat version selected for the app
the application’s own URL generation

My App Server is useful when you need a private JVM, separate Tomcat instance, and easy deployment for WAR, JSP, and servlet applications. For SSL issues, the same practical rule applies: secure the front end, ensure clean redirects, and avoid hardcoded insecure links in the application.

If you are running a custom app server or manually uploaded Tomcat version, double-check that the service is started correctly and that the web root and connector settings match your domain. Misaligned service settings can cause the app to behave as if it is still on HTTP even after the certificate is installed.

Step-by-step fix checklist

Confirm the SSL certificate is installed for the correct hostname.
Open the site on https:// and check for browser warnings.
Test the page in a private window.
Search the JSP application for http:// references.
Fix mixed content in images, scripts, stylesheets, and AJAX calls.
Ensure HTTP requests redirect to HTTPS.
Review Apache, Plesk, and .htaccess rules for conflicts.
Check Tomcat and proxy settings so the app recognises secure requests.
Clear caches and retest.

Common mistakes to avoid

Installing SSL but not updating the website links.
Redirecting only the homepage, not the whole site.
Forcing HTTPS in the browser while the app still loads HTTP assets.
Changing rules in both Plesk and .htaccess at the same time.
Assuming Tomcat will automatically rewrite all URLs to HTTPS.

FAQ

Why does my browser still say Not Secure after I installed a certificate?

Because the page is probably loading at least one resource over HTTP, or the site is not fully redirecting to HTTPS. The certificate is only one part of the setup.

Can a JSP website show Not Secure even if the padlock appears sometimes?

Yes. The browser may display mixed security states depending on the page, the subresources, or the exact URL entered. Always test the full site, not only the homepage.

Does Tomcat automatically make a JSP site secure after SSL is installed?

No. Tomcat can serve the application, but it does not automatically fix hardcoded HTTP links or mixed content. Those usually need application or web server changes.

Should I change my JSP code or only Apache settings?

Often both need review. Apache handles redirects and SSL termination, while JSP code may still generate insecure absolute URLs. Fixing only one side may not solve the warning.

How do I know if the issue is mixed content?

Open the browser console. If you see mixed content warnings or blocked HTTP resources, that is the cause. Replace those insecure URLs with HTTPS or relative paths.

Is this different for UK websites?

The technical issue is the same, but for UK sites it is important that the secure version of the exact public hostname is used consistently, including any www or non-www preference.

Conclusion

If a JSP website still shows Not Secure after SSL setup, the certificate is usually not the real problem. The warning typically comes from mixed content, missing HTTPS redirects, incorrect Tomcat proxy handling, or hardcoded HTTP links inside the application.

In a managed hosting environment with Apache, Plesk, and a private Tomcat service such as My App Server, the fastest fix is to check the certificate, enforce HTTPS for the full site, and review the JSP application for insecure resource URLs. Once all page elements load over HTTPS and the app recognises the secure request, the browser warning should disappear.

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