If your Java website still shows 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 by a Java application that has not been fully redirected to HTTPS. In a typical hosting environment with Plesk, Apache, and a Java stack such as Tomcat or a private JVM, the issue is usually caused by a configuration detail rather than a faulty certificate.
This can happen on shared hosting, managed hosting, or Java hosting platforms where the web server terminates SSL, then forwards requests to the Java application. Even when the SSL certificate is valid, browsers may still show warnings if the page contains mixed content, the app generates insecure links, or the domain and alias setup is incomplete.
Why a Java website can still show Not Secure after SSL setup
The browser only shows the secure padlock when everything on the page is delivered securely. For Java web applications, the most common causes are:
- Mixed content — the page loads images, CSS, JavaScript, fonts, or API calls over HTTP.
- Wrong redirect rules — the site still responds on HTTP or redirects in the wrong order.
- Application-generated HTTP links — Tomcat or the app itself builds absolute URLs with
http://. - Missing proxy awareness — the Java app does not know the original request was HTTPS.
- Certificate mismatch — the certificate does not cover the exact hostname used by visitors.
- Browser cache or HSTS state — old redirects or cached resources keep the warning visible.
- Third-party content — analytics, scripts, widgets, or embedded assets still use insecure URLs.
In a hosting control panel environment, the SSL certificate can be installed at the domain level, but the Java application still needs to be configured so that all traffic and generated links follow HTTPS consistently.
First checks to perform in Plesk or hosting control panel
Before changing the application, verify the basic hosting and domain settings. These checks are often enough to identify the root cause.
1. Confirm the certificate is assigned to the correct domain
Make sure the SSL certificate is installed for the exact hostname visitors use, such as example.co.uk or www.example.co.uk. If the site is accessed through both versions, the certificate should cover both names.
Check whether:
- the certificate is valid and not expired
- the hostname matches the browser address bar exactly
- both
wwwand non-wwwvariants are handled - the domain points to the correct hosting subscription
2. Make sure HTTPS is enabled for the site
In Plesk, the domain should have SSL/TLS enabled for web traffic. If the hosting platform supports it, ensure the site is configured to serve content over HTTPS and that port 443 is active for the domain.
3. Check the redirect from HTTP to HTTPS
If the site still loads on HTTP first, browsers may show an insecure connection or mixed-state warning. A proper redirect should send visitors from http:// to https:// automatically.
For Java applications, redirects are often handled by the web server layer, not only by the app itself. In managed hosting, this is usually configured in Apache, Nginx, or the hosting control panel.
Common Java and Tomcat reasons for the warning
Java applications add a few extra points to check because the app, the servlet container, and the web server may each influence how URLs are generated.
Absolute URLs still use HTTP
If your JSP pages, templates, or application settings contain full links like http://example.co.uk/images/logo.png, the browser will treat that content as insecure even if the main page is loaded via HTTPS.
This is especially common in:
- older JSP applications
- hard-coded links in templates
- configuration files with base URLs
- email templates or CMS-style Java apps
Tomcat does not detect HTTPS behind a proxy
Many hosting platforms terminate SSL in Apache or another front-end web server and then pass traffic to Tomcat internally. If Tomcat is not configured to trust the proxy headers, it may think the request is still HTTP.
When that happens, the application may:
- generate insecure absolute links
- create redirects back to HTTP
- mark cookies incorrectly
- build forms or callback URLs with the wrong scheme
In this case, the Java app needs to understand the forwarded headers such as X-Forwarded-Proto or the equivalent proxy configuration used by the hosting platform.
Servlets or JSP pages build links dynamically
Some Java applications use request-based URL construction. If the app is not aware that the original request was HTTPS, it may output http:// links even though the visitor is already on a secure page.
Typical examples include:
- login and logout redirects
- absolute links in navigation menus
- download links
- API endpoints called by JavaScript
Mixed content is the most common cause
Even one insecure file can cause the browser to mark the page as not fully secure. Mixed content is the most frequent reason a Java website still shows Not Secure after SSL setup.
Look for insecure references in:
- CSS files
- JavaScript files
- HTML templates and JSPs
- images and icons
- fonts and style libraries
- AJAX or fetch calls
- embedded video, maps, or widgets
Modern browsers may block active mixed content such as scripts, while passive content such as images can still trigger warnings or a broken padlock state.
How to find mixed content quickly
Open the browser developer tools and check the Console and Network tabs. Typical warnings look for blocked insecure resources or requests to http://.
You can also:
- search the application codebase for
http:// - check JSP includes and shared templates
- review CSS background image URLs
- inspect loaded third-party scripts and widgets
How to fix the issue in a hosting platform with Java and Tomcat
The exact steps depend on whether the SSL is handled directly by Apache, by Plesk, or by a reverse proxy in front of Tomcat. In most hosting environments, the following approach works well.
Step 1: Force HTTPS at the web server layer
Set a permanent redirect from HTTP to HTTPS for the domain. This ensures that visitors and search engines use the secure version of the site.
For a Java site, this is usually better than trying to handle the redirect only inside the application, because the web server can catch insecure requests before they reach the app.
Step 2: Update the application to use relative or secure links
Where possible, replace hard-coded absolute URLs with:
- relative paths
- protocol-relative links where appropriate, though full HTTPS links are often better today
- application settings that store the secure base URL
For example, if your app uses a configurable site URL, set it to the HTTPS version of the domain.
Step 3: Configure Tomcat or the Java runtime to trust the proxy
If Apache or another front-end server is terminating SSL, configure the Java application so it knows the original request was secure. This depends on the hosting setup, but the goal is the same: preserve the correct scheme, host, and port information.
In a managed Java hosting environment with a private JVM or Tomcat instance, this often means adjusting connector and proxy settings so redirects and generated URLs remain HTTPS-aware.
Step 4: Replace insecure third-party resources
Check analytics scripts, font providers, payment widgets, chat tools, and embedded media. If any of these still load over HTTP, switch them to HTTPS or remove them if no secure version is available.
Step 5: Re-test in a clean browser session
After changes, test the site in:
- an incognito or private window
- multiple browsers
- mobile and desktop views
This helps rule out cache, HSTS, and saved redirect state.
How this relates to My App Server hosting
If you use a Java hosting service with a Plesk extension such as My App Server, the SSL issue is often a combination of domain-level HTTPS setup and application-level URL handling. My App Server is useful because it lets you run a private Tomcat or JVM instance inside a shared hosting account, but the application still needs to be configured correctly for secure delivery.
In practical terms, that means:
- installing the certificate for the correct domain in the control panel
- ensuring the site redirects to HTTPS
- making sure the Java app uses the secure base URL
- checking Tomcat and proxy settings if the app sits behind Apache
- re-deploying WAR, JSP, or servlet code if hard-coded HTTP links are present
This is especially relevant for JSP hosting, servlet hosting, and small to medium Java applications that run comfortably on a private JVM but still rely on standard web server and proxy configuration.
Practical troubleshooting checklist
Use this checklist to narrow down the problem quickly:
- Open the site with
https://directly. - Confirm the certificate is valid for the exact hostname.
- Check whether the browser address bar shows a warning because of mixed content.
- Inspect page source for
http://links. - Review CSS, JavaScript, and image URLs.
- Verify the HTTP to HTTPS redirect works for both
wwwand non-www. - Check whether Tomcat or the Java app is generating insecure absolute URLs.
- Make sure proxy headers are preserved if SSL is terminated before Tomcat.
- Clear browser cache or test in private mode.
- Retest after redeploying the application.
Example scenarios
Scenario 1: SSL is valid, but images load over HTTP
A JSP site uses HTTPS for the page itself, but the logo, stylesheet, and a custom font are referenced with http://. The browser marks the page as not secure. Fixing the resource URLs removes the warning.
Scenario 2: Tomcat generates HTTP redirects
The application is behind Apache with SSL, but Tomcat still sees requests as plain HTTP. Login and logout redirects go to insecure URLs. The solution is to configure Tomcat and the proxy headers so the app understands the original connection was HTTPS.
Scenario 3: The certificate covers only one hostname
Visitors reach the site through www.example.co.uk, but the certificate was installed only for example.co.uk. Some browsers show warnings or fail to trust the connection properly. The fix is to include the correct hostname in the certificate setup.
When the browser still warns after all checks
If everything appears correct but the warning remains, look for less obvious causes:
- an old HTTP redirect cached by the browser
- an intermediate page linking to an insecure resource
- a subdomain that still uses HTTP
- a backend API endpoint called from JavaScript over HTTP
- a content management module or plugin generating old links
If the Java application uses multiple modules, each module should be checked separately. A secure main page does not guarantee that every included component is secure.
FAQ
Why does the browser still say Not Secure if the certificate is installed?
Because the certificate only secures the connection to the server. The page can still contain HTTP resources, incorrect redirects, or insecure links generated by the Java application.
Can Tomcat itself cause the warning?
Yes, indirectly. Tomcat may generate HTTP URLs if it does not know the original request was HTTPS, especially when it sits behind Apache or another proxy.
Is mixed content the same as an invalid certificate?
No. Mixed content means the main page is secure, but some embedded files are loaded insecurely. An invalid certificate is a separate problem affecting trust in the connection itself.
Do I need to change my Java code?
Sometimes yes. If the app contains hard-coded http:// links or builds URLs incorrectly, the code or configuration must be updated. In other cases, only server-side redirect and proxy settings need adjustment.
Will clearing cache help?
It can help if the browser cached an old redirect or insecure asset, but it will not fix an actual mixed content or proxy configuration issue.
Does this affect SEO?
Yes. Search engines prefer consistent HTTPS. If a site still serves insecure resources or inconsistent redirects, it can affect indexing, user trust, and performance of secure pages.
Conclusion
A Java website that still shows Not Secure after SSL setup usually has a configuration issue in the domain, proxy, Tomcat, or application layer. The certificate may be correct, but the page is still loading some content over HTTP, generating insecure links, or missing HTTPS-aware proxy settings.
In a hosting platform with Plesk, Apache, and a Java setup such as My App Server, the most reliable fix is to combine a proper HTTPS redirect, secure resource URLs, and correct proxy-aware configuration for Tomcat or the private JVM. Once all content and redirects consistently use HTTPS, the browser should show the secure connection normally.