If your Tomcat website still shows Not Secure after you have installed SSL, the certificate itself is not always the problem. In many cases, the browser is warning about how the site is being loaded, whether every page resource uses HTTPS, or whether Tomcat and the front-end web server are both configured correctly. In a managed hosting environment with Plesk, Apache, and a Tomcat-based Java application, this usually comes down to one of a few common causes that can be checked and fixed quickly.
For Java hosting setups that use My App Server and a private Apache Tomcat instance, SSL is only one part of the secure delivery chain. The domain must resolve correctly, the certificate must be active for the right hostname, Tomcat must be served through HTTPS, and all links, scripts, images, and redirects must consistently use secure URLs. If any part of that chain still uses plain HTTP, browsers may continue to display a warning or mark the page as partially secure.
Why a Tomcat site can still appear as Not Secure
When a browser says Not Secure, it usually means one of these situations:
- The page is opening over HTTP instead of HTTPS.
- The SSL certificate is installed, but the site still redirects to a non-secure URL.
- The certificate does not match the domain name being used.
- The page loads mixed content, such as images, JavaScript, CSS, fonts, or API calls over HTTP.
- Tomcat is behind Apache or a proxy, but the proxy headers are not configured properly.
- The browser is showing an old cached version or an old redirect.
In other words, SSL can be correctly installed and the site can still look insecure if the application, web server, or URL structure is not aligned.
Check whether the browser is loading the HTTPS version
The first thing to verify is the exact URL in the address bar. The site should open as https://your-domain.com, not http://your-domain.com. If the browser starts on HTTP and only later tries to switch, the initial request may still be flagged as insecure or redirected in a way that confuses users.
What to look for
- The address starts with https://.
- The padlock icon is present.
- There is no browser warning about redirects or certificate mismatch.
- Both www and non-www versions resolve as intended.
If one version loads securely and another does not, you may need a redirect rule so that all requests go to the same canonical HTTPS hostname.
Make sure the certificate is installed for the correct hostname
A very common issue is installing SSL for one hostname while users browse another. For example, the certificate may be valid for example.com but not for www.example.com, or the reverse. A modern browser will treat that as a certificate mismatch, which can still show as not secure even though SSL exists.
Confirm the certificate covers all required names
- Primary domain: example.com
- WWW alias: www.example.com
- Any additional alias or subdomain used by the application
If your Tomcat app is accessed through a specific hostname in Plesk or a control panel, that exact hostname must be included in the certificate. If you recently changed the domain or added an alias, renew or reissue the certificate with the correct names.
Check for mixed content in the Tomcat application
Even when the page itself loads through HTTPS, browsers will warn if some page resources still load over HTTP. This is known as mixed content. A single insecure image, font, script, stylesheet, iframe, or external API call can trigger a Not Secure state or a broken padlock.
Typical mixed content sources in Tomcat apps
- Hardcoded image links using http://
- JavaScript files loaded from an insecure CDN
- Stylesheets referenced with old absolute URLs
- Form actions pointing to HTTP
- AJAX requests to non-HTTPS endpoints
- Absolute links in JSP files, templates, or configuration files
How to fix it
- Replace all hardcoded http:// URLs with https:// or relative paths.
- Update JSPs, templates, and Java application configuration files.
- Check third-party libraries or widgets that may still call insecure resources.
- Use browser developer tools to identify blocked or insecure items.
For Tomcat hosting, mixed content is one of the most frequent reasons a site still looks insecure after SSL setup, especially when an older application was built before HTTPS became standard.
Verify SSL termination in Apache and the Tomcat connection
In many managed hosting setups, Apache handles the HTTPS connection and forwards requests to Tomcat internally. If that layer is not configured properly, the browser may see the HTTPS front end while the application still generates HTTP links or redirect URLs.
With a Tomcat app behind Apache, you should confirm:
- Apache is listening on port 443 with the SSL certificate active.
- Requests are forwarded to Tomcat using the correct connector or proxy settings.
- Tomcat knows the original request was HTTPS.
- The application generates secure URLs based on the incoming scheme.
Why this matters
If Tomcat thinks the request is plain HTTP, it may generate links, redirects, or session URLs that start with HTTP. The page can then appear partly insecure or trigger redirect loops. This is especially relevant when using a private JVM or a custom Tomcat instance managed through a hosting control panel.
Check Tomcat’s proxy and secure request settings
When Tomcat runs behind Apache or another reverse proxy, it often needs to be told that the original request arrived via HTTPS. Otherwise, the application may not recognize the secure scheme correctly.
Common indicators of incorrect proxy handling
- Login pages redirect to HTTP after submission
- Session cookies are missing the secure behavior you expect
- Generated links point to the wrong scheme or port
- Browser warnings appear only after form submission or login
Depending on the setup, the relevant configuration may involve proxy headers such as X-Forwarded-Proto, a secure connector definition, or application-level settings that respect forwarded HTTPS requests. If you use My App Server or a custom Tomcat service, this should be verified alongside the Apache front end and domain binding.
Make sure the site redirects all traffic to HTTPS
If users can still reach the site over HTTP, the browser may show a warning before redirecting to the secure version. A proper HTTP-to-HTTPS redirect ensures that every visitor lands on the encrypted URL from the start.
What a proper redirect should do
- Send all http:// requests to the matching https:// address.
- Preserve the path and query string when possible.
- Apply to both the base domain and the www version if both are used.
- Avoid redirect loops between Apache, Tomcat, and application code.
In Plesk-based hosting, redirects are often handled through hosting settings, Apache rules, or application-level logic. The important part is that there should be one clear canonical HTTPS destination. If the redirect happens partly in Apache and partly in Tomcat, make sure the rules do not conflict.
Confirm the certificate is active and not expired
Sometimes the certificate is installed correctly but is not actually the active certificate for the domain. It may also have expired, or the hosting panel may still be serving an older certificate while the new one is present in the account.
Check these details
- Expiration date is still valid.
- The certificate chain is complete.
- The correct certificate is assigned to the correct domain.
- Any intermediate certificate is included automatically by the panel or web server.
If the hosting platform uses automatic SSL provisioning, verify that the certificate was issued successfully for the exact hostname and that the web server has picked up the latest version.
Check DNS and domain mapping
A domain can only present the right certificate if it points to the correct hosting target. If DNS still points to an old server, a temporary IP, or the wrong virtual host, the browser may see the wrong certificate or an unexpected response.
Things to verify in DNS and hosting mapping
- The domain resolves to the correct server.
- The virtual host in the control panel matches the domain name.
- The SSL certificate belongs to that exact hosted site.
- The application is not being reached through an outdated IP or alias.
This is especially important after a go-live change, migration, or DNS update. During propagation, some visitors may still see the old site or a certificate issued for a different hostname.
Review the application URLs inside JSP and configuration files
Older Java web applications often contain absolute URLs in JSP pages, servlet responses, XML configuration files, or Java properties. If those URLs were written before SSL was enabled, they may still use HTTP.
Common places to inspect
- JSP include files
- Servlet-generated links
- Login and logout redirects
- Base URL settings in properties or XML files
- Environment-specific configuration for public URLs
For best results, the application should build URLs dynamically from the current secure request or from a configurable base URL that is set to HTTPS. This avoids future issues when the domain, port, or proxy setup changes.
Check cookies, sessions, and login redirects
Some browser warnings appear after a login or session change rather than on the homepage itself. In a Tomcat application, this can happen when session cookies or redirect logic are still tied to HTTP.
What to look for
- Session cookies should behave correctly over HTTPS.
- Logout and return URLs should use HTTPS.
- Authentication flows should not jump back to HTTP.
- Remember-me or SSO-related links should also use secure URLs.
If the site only appears insecure after login, the problem may be in the application flow rather than the certificate installation.
Browser cache and old redirects can hide the fix
Even after you correct the issue, your browser may continue to show the old state because of cached redirects, cached resources, or remembered certificate errors. Test the site in a private window or a different browser to confirm the current behavior.
Good testing steps
- Open the site in incognito/private mode.
- Test from another browser.
- Clear cached site data if needed.
- Check the site from an external device or network.
This is a practical step, especially after you have already corrected DNS, SSL, or redirect settings in the hosting control panel.
Recommended checklist for Tomcat hosting with SSL
If your Tomcat site still shows Not Secure, go through this checklist in order:
- Confirm the site opens with https://.
- Verify the certificate is valid for the exact hostname.
- Check whether www and non-www versions are consistent.
- Inspect the page for mixed content.
- Confirm Apache is serving HTTPS correctly.
- Verify Tomcat receives the secure request through the proxy.
- Review application URLs in JSPs, servlets, and config files.
- Test redirects from HTTP to HTTPS.
- Check DNS and virtual host mapping.
- Retest in a private browser window.
Example scenario in a managed Tomcat setup
Imagine a Java application deployed as a WAR file on a private Tomcat instance through My App Server. You install SSL in Plesk, and the domain now opens with HTTPS. However, the browser still shows Not Secure on the login page.
In this case, the issue may be one of the following:
- The login page loads a stylesheet from http://.
- The application redirects to an HTTP callback URL after authentication.
- Apache is terminating SSL, but Tomcat is not seeing the original scheme as HTTPS.
- The certificate is valid for example.com but the app uses www.example.com.
The fix would usually involve updating the application URLs, checking the proxy headers, and ensuring the HTTPS redirect is applied consistently. Once all resources load securely and the correct hostname is used, the browser should stop showing the warning.
When to contact hosting support
If you have already checked the certificate, redirects, and mixed content, and the site still shows Not Secure, the issue may be at the web server or virtual host level. At that point, support can help confirm whether:
- The correct certificate is attached to the domain.
- Apache is serving the expected vhost on port 443.
- Tomcat is connected through the proper service configuration.
- A custom Tomcat or JVM setup needs proxy or connector adjustment.
In a managed hosting environment, this is often faster to resolve when the exact domain, URL, and symptoms are provided, especially if the issue appears only on certain pages or after login.
FAQ
Why does my site show Not Secure even after installing a valid SSL certificate?
Because the browser warning is often caused by mixed content, wrong redirects, or a hostname mismatch, not only by the certificate itself. The certificate may be valid, but the page may still load insecure resources or open through HTTP.
Can Tomcat cause the site to show Not Secure?
Yes. If Tomcat generates HTTP links, does not recognize the secure proxy connection, or uses outdated application URLs, the browser may still mark the site as insecure.
What is mixed content?
Mixed content is when an HTTPS page loads some elements over HTTP. Even one insecure image, script, stylesheet, or API call can trigger a browser warning.
Do I need to change anything in Apache if Tomcat is behind it?
Often yes. If Apache handles HTTPS and forwards traffic to Tomcat, the proxy and redirect settings must be correct so the application knows it is being accessed securely.
Why does only the login page show Not Secure?
That usually means the issue is in the application flow, such as a redirect to HTTP, a form action using an insecure URL, or a resource loaded only on that page.
How do I know if the certificate covers both www and non-www?
Check the domain names included in the certificate. If users can access the site with both versions, both names should be covered or one should redirect cleanly to the canonical HTTPS version.
Conclusion
A Tomcat website can still show Not Secure after SSL setup even when the certificate is installed correctly. The most common causes are mixed content, incorrect redirects, hostname mismatches, proxy configuration issues, or application URLs that still point to HTTP. In a hosting environment with Plesk, Apache, and My App Server, the best approach is to check the full chain: DNS, certificate, web server, Tomcat proxy handling, and application links.
Once all public URLs use HTTPS consistently and Tomcat is configured to respect the secure front end, the browser warning should disappear and the site will present as secure to visitors.