If your JSP website still shows Not Secure after you have installed SSL, the certificate itself is often not the problem. In most cases, the browser is warning about something else: mixed content, redirects that still go through HTTP, an incomplete certificate chain, or application links that were never updated after the HTTPS change. For JSP hosting environments, this can also happen when Apache, Tomcat, or a private JVM is serving pages through different paths, ports, or connector settings.
In a managed hosting environment with Plesk and a Java hosting setup such as My App Server, the fix usually involves checking both the web server layer and the Java application layer. A JSP app may load its main page over HTTPS, but still call images, scripts, CSS files, APIs, or redirects over HTTP. Modern browsers treat that as insecure even when the SSL certificate is valid.
Why a JSP site can still show Not Secure after SSL installation
SSL setup only protects the connection between the browser and the server. It does not automatically convert your application to HTTPS. Your JSP application must also be configured to use secure URLs everywhere. If even one important resource is loaded over HTTP, the browser may mark the page as Not Secure or show a partial warning.
Common reasons include:
- Mixed content: the page uses HTTP for scripts, images, fonts, stylesheets, AJAX calls, or embedded media.
- Old application links: hardcoded http:// URLs remain in JSP files, tag libraries, templates, or configuration files.
- Wrong redirects: the site redirects from HTTPS back to HTTP somewhere in the chain.
- Incomplete SSL chain: the certificate is installed, but intermediate certificates are missing.
- Proxy or connector mismatch: Tomcat or Apache does not know the original request was HTTPS.
- Cookie and session issues: secure cookies, session tracking, or login flows still use insecure settings.
- Content loaded from external sources: third-party resources are not available over HTTPS.
What browsers check when they display Not Secure
Browsers do more than verify whether an SSL certificate exists. They inspect the full page and its dependencies. If the top-level page is HTTPS but one or more subresources are HTTP, the browser may show a warning, disable the lock icon, or block some content.
In practice, browsers look at:
- the validity of the SSL certificate
- the certificate name and domain match
- the certificate chain and intermediate certificates
- redirect behavior from HTTP to HTTPS
- all resources loaded by the page
- JavaScript requests, form submissions, and API endpoints
- cookie security flags such as
SecureandHttpOnly
Most common SSL-related issues in JSP, Tomcat, and Apache setups
1. Mixed content in JSP pages
This is the most frequent cause. Your JSP page may be served securely, but a stylesheet, JavaScript file, logo, or external API call may still use an http:// address. Even one insecure resource can trigger the browser warning.
Typical examples:
<script src="http://example.com/js/app.js"><img src="http://example.com/images/logo.png"><link rel="stylesheet" href="http://example.com/css/site.css">- AJAX requests sent to an HTTP endpoint
- embedded iframe content that does not support HTTPS
2. Hardcoded HTTP links in templates or JSP fragments
JSP applications often reuse header, footer, navigation, and include files. If those files contain hardcoded absolute URLs, the site may still call HTTP even after SSL is active.
Check:
- JSP include files
- layout templates
- tag files
- properties files
- Spring or framework configuration, if used alongside JSP
3. Application-generated redirects still point to HTTP
Some applications generate redirect URLs based on server variables. If Tomcat or Apache does not correctly detect HTTPS, the app may build an HTTP redirect URL. This is common behind reverse proxies or when SSL is terminated before the Java application layer.
For example, login pages, checkout pages, or post-submit redirects may go back to http:// unless the application is configured to trust the proxy or the forwarded protocol header.
4. SSL certificate installed, but not fully trusted
If the certificate chain is incomplete, browsers may still connect but display warnings. This is especially likely when the certificate was installed manually in Apache or Tomcat and the intermediate CA bundle was not added.
5. Tomcat or Apache is serving the site on both HTTP and HTTPS
In a JSP hosting environment, you may have Apache handling public traffic while Tomcat runs the application privately. If HTTP remains open and your app or old bookmarks still use it, the browser may reach the insecure version first or be redirected through an insecure path.
6. Session cookies are not marked secure
Login-heavy JSP applications may need secure session handling. If cookies are not protected correctly, browsers can consider parts of the session flow less secure, especially if authentication or form submission occurs over an insecure route.
How to find the exact cause
Before changing configuration, identify whether the warning is caused by the certificate, the application content, or the redirect chain. This saves time and helps you fix the real issue instead of reinstalling SSL unnecessarily.
Step 1: Open the site in a browser and inspect the warning
Click the browser security indicator and review the details. If the browser mentions mixed content, the certificate is usually valid and the issue is inside the page. If it says the certificate is invalid, expired, or not trusted, focus on the SSL installation itself.
Step 2: Check the page source for HTTP links
View the page source and search for http://. Also inspect loaded resources in the browser developer tools. Pay special attention to:
- JavaScript files
- CSS files
- images and icons
- fonts
- API endpoints
- embedded widgets
Step 3: Test the redirect chain
Open the HTTP version of your site and verify that it redirects directly to HTTPS. The redirect should be clean and consistent. Avoid redirect loops, double redirects, or paths that send users back to HTTP.
Good behavior:
http://example.com→https://example.comhttp://www.example.com→https://www.example.com
Problematic behavior:
http://example.com→http://example.com/login→https://example.com/loginhttps://example.comloads content fromhttp://cdn.example.com
Step 4: Verify the SSL chain
Use your hosting control panel or SSL diagnostic tools to confirm that the full certificate chain is installed. If the browser does not trust the chain, the padlock may not appear correctly even when the domain matches.
Step 5: Review Apache and Tomcat settings
If you run a JSP app on Apache with a Tomcat backend or a private JVM, confirm that both layers understand HTTPS. Apache may terminate SSL, while Tomcat still believes requests are arriving over HTTP unless forwarded headers are configured correctly.
How to fix mixed content in JSP websites
Mixed content is the most common reason a JSP website still looks insecure after SSL setup. Fixing it usually requires editing your application code, templates, and configuration.
Use relative URLs where possible
Instead of hardcoding full URLs, use relative paths for internal resources:
- use
/assets/css/site.cssinstead ofhttp://example.com/assets/css/site.css - use
/images/logo.pnginstead of an absolute HTTP path
This reduces the risk of protocol mismatch after SSL changes or domain migrations.
Replace HTTP links with HTTPS
If a resource must be loaded from your own domain, update every hardcoded URL to https://. This includes:
- header and footer includes
- canonical links
- form actions
- AJAX endpoints
- download links
- redirect destinations
Use protocol-relative or dynamic base URLs carefully
Some older JSP applications use protocol-relative URLs such as //example.com/resource.js. These can work, but they are not always ideal for modern applications. A better approach is to generate URLs based on the current request protocol or, even better, store HTTPS URLs explicitly when the site is public-facing.
Update third-party integrations
External tools can also create mixed content. Check payment providers, analytics scripts, chat widgets, font services, and embedded maps. If a service does not support HTTPS, browsers may block it or lower the security status of the page.
How to make Apache and Tomcat handle HTTPS correctly
In a hosting environment where JSP runs on Tomcat or a private JVM, the web server and application server must agree on the request scheme. If SSL is terminated in Apache or a proxy, Tomcat may need forwarded header configuration so it can generate secure URLs correctly.
Confirm that HTTPS is enabled on the public URL
Your public website should always resolve to the secure address. If both HTTP and HTTPS are accessible, the HTTP version should redirect immediately to HTTPS.
Check forwarded protocol handling
If Apache or a reverse proxy terminates SSL before the request reaches Tomcat, the application may need to read headers such as:
X-Forwarded-ProtoX-Forwarded-HostX-Forwarded-Port
Without these, your JSP application might generate insecure absolute links or wrong redirects.
Review Tomcat connector and proxy settings
In Tomcat-based hosting, connector settings and proxy configuration must align with the actual deployment. If the application is behind Apache, Tomcat should not assume that the direct client connection is plain HTTP if the public site is served over HTTPS.
In a managed setup such as My App Server, this is usually simpler because the service is controlled through the hosting panel and the Java runtime can be managed alongside the web application. Still, when you deploy custom JSP code, you should confirm that the application uses the correct scheme and host values.
Use the hosting control panel to verify the active service
If your hosting platform provides service controls for the Java application server, check that the correct Tomcat instance or JVM is running and that the web application is attached to the intended domain. A common issue is deploying SSL on one hostname while the application continues to reference another hostname or an old port.
SSL setup checklist for JSP hosting
Use the following checklist to resolve a persistent Not Secure warning:
- Confirm that the SSL certificate is valid and not expired.
- Make sure the certificate is installed for the correct domain and subdomain.
- Verify that the full certificate chain is present.
- Redirect all HTTP traffic to HTTPS.
- Search the JSP app for hardcoded
http://links. - Replace insecure resource URLs with HTTPS or relative paths.
- Check external scripts, fonts, widgets, and APIs.
- Review Tomcat or Apache proxy settings if SSL is terminated before the app server.
- Confirm that generated links, form actions, and redirects use HTTPS.
- Clear browser cache after changes and retest in a private window.
How My App Server fits into JSP SSL troubleshooting
For JSP hosting, a managed Java service such as My App Server can help simplify the SSL and HTTPS workflow because you can run your own Apache Tomcat or private JVM inside the hosting account and manage the service through Plesk. That makes it easier to align the application server, deploy WAR files, and control the Java version used by the site.
However, SSL issues still need the same basic checks. My App Server does not automatically rewrite your JSP code or fix hardcoded HTTP references. It gives you control over the runtime and deployment, but the application itself still needs to be HTTPS-ready.
In practical terms, this means:
- deploying the JSP app to the correct domain
- ensuring the Tomcat service is running properly
- checking that the application uses secure URLs
- validating redirects and proxy headers
- testing after each deployment or configuration change
Example: fixing a JSP page that loads insecure assets
Suppose your homepage is served from https://example.com, but the page source contains the following resources:
http://example.com/css/app.csshttp://example.com/js/app.jshttp://cdn.thirdparty.com/widget.js
Even though the site has SSL, the browser sees HTTP resources and flags the page. The fix is to:
- change internal assets to
https://example.com/css/app.cssandhttps://example.com/js/app.js, or use relative URLs - replace the third-party script with an HTTPS version, if available
- remove or replace any service that does not support HTTPS
- clear cache and retest
Why clearing cache and testing in a private window helps
After making SSL changes, cached redirects or old resource references may continue to affect what you see. A private window helps you test the current state of the site without relying on stale cache, cookies, or saved redirects.
When you retest, verify:
- the lock icon appears correctly
- no browser console warnings remain
- all pages and subpages load over HTTPS
- login and form submission flows remain secure
FAQ
Why does my browser say Not Secure even though the certificate is installed?
The certificate may be correct, but the page can still load insecure resources over HTTP. This is usually caused by mixed content, old redirects, or application links that were not updated after SSL setup.
Can a JSP page show Not Secure because of one image or script?
Yes. Even a single insecure image, script, stylesheet, or external widget can trigger a warning. Browsers inspect the full page, not just the main HTML document.
Does installing SSL in Plesk automatically fix JSP URLs?
No. Plesk can install and manage the certificate, but your JSP application still needs correct links, redirects, and proxy handling. The application code may need updates.
Why does Tomcat generate HTTP links after SSL is enabled?
Tomcat may not know that the public request arrived through HTTPS if SSL is terminated in Apache or another proxy layer. In that case, forwarded headers and connector settings must be configured correctly.
Do I need to change every URL in my JSP files to HTTPS?
All public-facing absolute URLs should use HTTPS. Internal links are often better as relative paths, which helps avoid protocol issues in future changes.
What if the warning only appears on the login page?
Login pages are especially sensitive to redirect and cookie issues. Check the form action URL, session cookie settings, and any post-login redirects that may still use HTTP.
Is this a problem with SSL or with the application?
It can be either, but in JSP hosting it is often an application-level issue. The certificate may be valid while the JSP pages, Tomcat configuration, or external assets still use insecure references.
Conclusion
If a JSP website still shows Not Secure after SSL setup, the root cause is usually not the certificate installation itself. More often, the problem is mixed content, outdated HTTP links, redirect behavior, or Tomcat and Apache settings that do not fully reflect the HTTPS request.
For JSP hosting environments that use a managed control panel and a Java service such as My App Server, the best approach is to check the certificate, review all application URLs, verify proxy handling, and confirm that the site redirects cleanly to HTTPS. Once the JSP application, web server, and Java runtime all agree on the secure scheme, the browser warning should disappear.