After SSL is installed, a Java website can still show “Not Secure” when the browser detects that not every page element is being loaded over HTTPS, or when the application itself is still generating HTTP links. In a Java hosting setup, this is often related to Tomcat, a reverse proxy, or a control panel configuration rather than the certificate itself. The SSL certificate may be valid, but the site can still be marked as insecure if the browser finds mixed content, redirects are incomplete, or the application does not know that it is being accessed through HTTPS.
In a managed Java hosting environment, especially when you run a private JVM or Apache Tomcat through a control panel such as Plesk, the issue is usually fixable without changing the certificate. The key is to check how the application builds URLs, how Tomcat detects the request scheme, and whether all resources load securely.
Why a Java site can still show “Not Secure” after SSL setup
Browsers do not judge security only by the presence of a certificate. They also check whether the entire page is delivered securely. If the HTML page is loaded over HTTPS but some images, scripts, CSS files, fonts, or API calls still come from HTTP, the browser may mark the page as “Not Secure” or show a warning icon.
In Java applications, this often happens because the application was originally written for HTTP and later moved to HTTPS without updating:
- hardcoded links in JSP pages or templates
- base URLs stored in configuration files
- redirect logic in servlets or filters
- Tomcat connector settings behind a proxy
- absolute URLs generated by the application framework
So even if your SSL certificate is installed correctly, the browser may still detect insecure content or an insecure redirect path.
Most common reasons for the warning
Mixed content is still being loaded
This is the most common cause. Mixed content means the main page uses HTTPS, but some assets are loaded with HTTP. Typical examples include:
- JavaScript files
- CSS files
- images
- web fonts
- embedded iframe content
- AJAX or API requests
Even one insecure resource can trigger a browser warning. In some cases, the page may still load, but the browser will label it as not fully secure.
The application still redirects to HTTP
Sometimes the first page is loaded securely, but a redirect or internal link sends the browser to an HTTP URL. This can happen if:
- the application uses the old domain format with http://
- Tomcat or the framework does not know the request is HTTPS
- a proxy or load balancer is not forwarding the correct scheme headers
- rewrite rules are incomplete
If the browser ever lands on HTTP, the connection loses the secure state and the page may be flagged.
Tomcat is unaware that SSL is handled upstream
In many hosting setups, SSL is terminated at Apache or another front-end layer, while Tomcat runs behind it on a private port. In that case, Tomcat must be configured to understand that the original request was HTTPS. If it is not, it may generate absolute links with http:// or build redirects incorrectly.
This is particularly relevant in Java hosting setups where you manage a private JVM or Apache Tomcat through Plesk and a custom service layer.
Hardcoded URLs in JSP, servlets, or application settings
Java applications often contain absolute URLs in:
- JSP files
- Servlet redirects
- Spring or framework configuration
- database-stored site settings
- email templates
- frontend code generated from the backend
If these URLs still use HTTP, the browser may request insecure resources even though the domain itself has a valid certificate.
The certificate is installed on the wrong hostname
A valid certificate for www.example.com will not automatically cover example.com unless the certificate includes both names. If a Java application opens redirects between different hostnames, one of them may not be fully protected.
Check whether the certificate matches the exact host that users visit, including:
- apex domain
- www subdomain
- staging subdomain
- application subdomain
How to diagnose the problem step by step
1. Check whether the certificate is valid
Open the site in a browser and inspect the certificate details. Confirm that:
- the certificate is not expired
- the hostname matches the domain you use
- the intermediate chain is complete
- the browser trusts the issuer
If the certificate itself is broken, the issue is SSL installation. If the certificate is valid but the warning remains, the cause is usually mixed content or redirect configuration.
2. Open the browser developer tools
Use the console and network tabs to look for:
- requests to
http:// - blocked insecure scripts
- CSS files loaded over HTTP
- images or fonts from insecure URLs
- redirect chains that switch between HTTPS and HTTP
In many cases, the browser console will clearly show which resource is causing the warning.
3. Search the application code for HTTP links
Review JSP files, templates, and backend code for hardcoded http:// references. In Java applications, a single hardcoded base URL can affect the whole site.
Look in:
- JSP includes
- layouts and header files
- Servlet response redirects
- framework properties files
- theme or asset configuration
When possible, use relative URLs or generate links based on the current request scheme.
4. Verify Tomcat and proxy settings
If your Java app runs on Tomcat behind Apache or another front-end server, verify that HTTPS information is passed correctly. Tomcat must know that the original request came through SSL.
Common indicators of incorrect setup include:
- redirect loops between HTTP and HTTPS
- wrong absolute URLs in generated pages
- session cookies not marked as secure when expected
- links in the application pointing back to HTTP
In a Plesk-based Java hosting environment with My App Server, this usually means checking both the web server configuration and the Tomcat service settings.
5. Confirm that every domain version is covered
Make sure users are redirected consistently to the preferred HTTPS hostname. For example, decide whether the site should use:
https://example.comhttps://www.example.com
Then redirect the other version permanently to the preferred one. If both versions are used without a clear redirect plan, browsers and users can encounter inconsistent security behavior.
How to fix mixed content on a Java website
Replace hardcoded HTTP links
Update all static resource references so they use HTTPS or relative paths. For example, instead of linking to http://example.com/images/logo.png, use a secure URL or a relative path like /images/logo.png.
Relative paths are often safer in Java web applications because they adapt to the current scheme and host.
Update JSP and template files
In JSP-based applications, inspect common shared templates, especially:
- header.jsp
- footer.jsp
- navigation templates
- layout fragments
- script includes
These files often contain the site-wide asset references that cause the warning across multiple pages.
Fix backend-generated links
If the application builds URLs in servlets or helper classes, make sure it uses the secure scheme when needed. Some frameworks can detect HTTPS automatically if the request object and proxy headers are set correctly.
Where possible, avoid concatenating full URLs manually. Use framework helpers or request-aware URL building methods.
Check external resources
Even if your own site is clean, external content can create mixed content. Review any third-party:
- scripts
- tracking snippets
- maps
- fonts
- widgets
- payment or chat embeds
If an external provider still serves content over HTTP, replace it with the HTTPS version or remove it if no secure option exists.
Tomcat-specific checks in a Java hosting environment
When you use a managed Java hosting platform with your own Apache Tomcat or private JVM, SSL is often handled by the web layer in front of the application. That means the application server may not be the place where the certificate is installed, but it still must be configured correctly to respect HTTPS.
Check the connector and proxy awareness
Tomcat should receive the correct scheme, host, and port information. If it does not, it may generate links as if the site is still on HTTP.
Useful checks include:
- whether the front-end server forwards the original protocol
- whether proxy headers are enabled and trusted
- whether redirects are handled at the web server level or inside the app
- whether the application uses absolute URLs in responses
Restart the service after changes
In a control panel environment, configuration changes may require restarting the Java service or the Tomcat instance. If you use a My App Server style setup, make sure the updated settings are applied to the correct service before retesting.
After a restart, clear the browser cache and test the site in a private window. Cached HTTP assets can make it look like the problem still exists even after the fix.
Review deployment paths and context settings
If the application is deployed under a context path, confirm that all internal links respect that path and use HTTPS. A mismatch between the deployed context and the generated base URL can produce redirects to the wrong protocol or host.
How to force HTTPS correctly
Use a single canonical HTTPS version
Choose one canonical domain and redirect all other versions to it. This should include:
- HTTP to HTTPS
- non-www to www, or the reverse
- old hostnames to the active hostname
The redirect should be permanent and consistent. If users can access both HTTP and HTTPS versions, search engines and browsers may treat the site as inconsistent.
Enable HSTS only after testing
HTTP Strict Transport Security can help enforce HTTPS, but it should be enabled only after the site is confirmed to work properly on HTTPS everywhere. If mixed content or broken redirects remain, HSTS can make troubleshooting harder.
Use HSTS only when:
- all pages load correctly over HTTPS
- no insecure resources remain
- redirects are stable
- the certificate setup is complete for the chosen hostname
Practical checklist for Java hosting customers
- Confirm the SSL certificate is valid for the exact domain in use.
- Check browser console messages for mixed content.
- Search JSP, servlet, and template files for
http://. - Update hardcoded links to HTTPS or relative paths.
- Verify Tomcat or the proxy knows the request is secure.
- Make sure all redirects go to one canonical HTTPS URL.
- Remove or replace insecure third-party scripts and embeds.
- Restart the Java service if configuration changes were made.
- Test in a private browser window after clearing cache.
Example scenario in Tomcat
A customer deploys a JSP application on a Java hosting account with a private Tomcat instance. The SSL certificate is installed successfully in the control panel, and https://example.com opens without a certificate error. However, the page still shows “Not Secure”.
After checking the browser console, the customer finds that the page loads a stylesheet from http://example.com/css/main.css. The application also redirects the login page to an HTTP URL because the backend assumes the site is still accessed without SSL.
The fix is to:
- change the stylesheet reference to HTTPS or a relative path
- update the application’s base URL setting
- verify Tomcat is behind the correct HTTPS-aware proxy setup
- test again after restarting the service
After these changes, the browser recognizes the site as fully secure.
When the issue is not in the application
Sometimes the problem is outside the Java code. It can be caused by:
- an incomplete SSL chain
- a certificate installed for the wrong host
- a missing redirect from HTTP to HTTPS
- cached mixed content in the browser
- a proxy or load balancer sending incorrect headers
If you have already checked the application and still see the warning, review the web server and hosting-layer settings in the control panel. In managed hosting, the secure delivery path often spans both Apache and Tomcat, so both layers need to be aligned.
FAQ
Why does Chrome still say “Not Secure” if the certificate is installed?
Because the certificate alone does not guarantee full page security. Chrome also checks for mixed content and insecure redirects. If any resource still loads over HTTP, the browser may show the warning.
Can a Java application cause mixed content by itself?
Yes. Java code often generates absolute URLs, especially in JSP pages, servlets, and framework templates. If those URLs still use HTTP, the browser may flag the page even though SSL is correctly installed.
Do I need to change Tomcat settings for HTTPS?
Often yes, especially if SSL is terminated before Tomcat. Tomcat must understand that the request arrived securely, otherwise it may generate incorrect links or redirects.
Will changing links from HTTP to HTTPS solve the issue?
In many cases, yes. If the warning is caused by mixed content, fixing insecure links is the main solution. However, you should also confirm that redirects and proxy settings are correct.
Why does the site work on one page but not another?
Different pages may load different resources. One page may be clean, while another still includes an HTTP image, script, or external widget. The browser warning depends on the specific page content.
Does this affect SEO?
Yes, indirectly. Search engines and browsers prefer secure, consistent HTTPS sites. If important pages still load insecure resources or redirect unpredictably, that can hurt trust and technical quality.
Conclusion
If a Java website still shows “Not Secure” after SSL setup, the certificate is usually not the real problem. The most common causes are mixed content, incorrect redirects, hardcoded HTTP links, or Tomcat not recognizing that the site is served through HTTPS. In a Java hosting environment with Plesk and a private Tomcat or JVM, the fix often involves both the application code and the hosting configuration.
Start by checking the browser console, then review JSP files, backend redirects, proxy headers, and the canonical HTTPS version of the domain. Once all content, links, and redirects use HTTPS consistently, the browser should treat the site as secure.