SSL certificate installed but not working: why your site still says not secure

What not working usually means

People say a certificate is not working when they see one of four quite different things. Work out which one you have first, because each has its own cause.

Note that current Chrome no longer shows a padlock at all on secure pages. Since Chrome 117 the padlock was replaced with a neutral settings icon, so a missing padlock in Chrome is normal. What matters is whether the address starts with https and whether Chrome shows Not secure or a warning. Click the icon and choose the connection details to see whether Chrome considers the connection secure.

The common causes

On GoDaddy and similar hosts, the certificate product and the hosting are often separate. Buying a certificate does not install it: it must be validated, issued and then installed on the hosting plan that actually serves the domain. If the domain's DNS points somewhere else, such as another host or a site builder, the certificate on the GoDaddy plan is never used. Check the certificate's status in the account first, then confirm where the domain points.

How to diagnose it in five minutes

Open a private window so no cached redirects or old pages get in the way, then type the bare domain with no scheme. Watch where you land. Then run these commands from any terminal:

curl -sI http://example.com | grep -iE "^HTTP|^location"
curl -sI https://example.com | grep -iE "^HTTP|^location"
curl -sI https://www.example.com | grep -iE "^HTTP|^location"

The first should return 301 with a location: https://... header. If it returns 200, there is no HTTPS redirect. If the second or third fails with a certificate error, curl tells you why: a name mismatch, an expired certificate or unable to get local issuer certificate, which means the chain is incomplete.

To see the certificate the server actually sends, and whether the chain is complete:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | grep -E "subject=|issuer=|Verify return code"

Verify return code: 0 (ok) means the certificate and chain are valid for that name. Anything else names the problem. If the subject is a different domain, you are hitting the wrong server or the wrong virtual host.

Checking mixed content

Load the https page, open DevTools and look at the Console. Mixed content messages name every insecure URL. Chrome upgrades insecure images, audio and video to https automatically and blocks them if the upgrade fails, and it blocks insecure scripts, stylesheets and frames outright, which can break layouts and menus. The security audit lists mixed content across a page, along with the certificate details and redirect status.

Sending every visitor to https

Most sites that still say not secure after an install simply never redirect http to https. Add one 301 that goes straight to the final address, so http://www.example.com goes to https://example.com in a single hop.

Apache or cPanel, in .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

In Plesk, open Hosting and DNS, then Hosting, and tick the permanent SEO-safe 301 redirect from HTTP to HTTPS. In cPanel, the Domains page has a Force HTTPS Redirect switch for each domain. Then update the site's own settings: in WordPress the WordPress Address and Site Address must both start with https, or the site keeps generating http links. The full set of patterns is in fixing HTTPS redirects.

CDN and proxy settings

With Cloudflare or another proxy in front, there are two connections: the visitor to the CDN, and the CDN to your server. Each needs to be secure for the site to work cleanly.

Use Full (strict) with either a public certificate or a Cloudflare Origin CA certificate on your server, and switch on Always Use HTTPS. Remember that an Origin CA certificate is only trusted by Cloudflare: if you later set the record to DNS only, visitors get an untrusted certificate warning. For loops between the CDN and your server, see CDN origin redirects, and for mixed content caused by a proxy, mixed content behind a proxy.

Worked example: a GoDaddy domain on another host

Example Bakery bought a certificate through its domain registrar, and the account shows it as issued. The site still opens as http://example.com with Not secure, and https://example.com shows a privacy warning.

1. curl -sI http://example.com returns 200, so there is no redirect to https.
2. OpenSSL against https://example.com shows a certificate for the web host's own server name, not example.com.
3. dig +short example.com shows the domain points at a separate web host, not the registrar's hosting. The paid certificate was never installed where the site lives.
4. The owner switches on the web host's free Let's Encrypt certificate for example.com and www.example.com in the hosting panel instead.
5. They tick the HTTP to HTTPS redirect, change the WordPress addresses to https, and replace a hard-coded http logo URL that caused a mixed content message.
6. A private window now lands on https://example.com, Chrome shows the connection is secure, and OpenSSL reports Verify return code: 0 (ok).

The fix, step by step

Edge cases worth knowing

• It works for you but not for others. Your browser may have cached a missing intermediate certificate from another site. Test with curl or OpenSSL, which do not do this, and install the full chain as described in untrusted certificate fixes.
• Only www or only one subdomain fails. That is a name mismatch, covered in wrong hostname and subdomain fixes.
• The panel says the certificate cannot be issued. Validation is failing, often because of DNS or a blocked challenge path. See certificates that cannot be issued.
• Port 443 is closed. If https times out, check the server firewall and any security group, and make sure the web server listens on 443.
• Wrong system clock. A visitor whose device date is wrong sees a date error even with a valid certificate. If only one device fails, check its clock.

Keeping HTTPS working

Once it works, add HSTS so browsers go straight to https on later visits, but only after every hostname has a valid certificate; see adding HSTS. Confirm automatic renewal is on, because a certificate that expires breaks the site in the same way as one that was never installed. Re-test with curl after any move to a new host, a DNS change or a CDN change, and run the security audit every few months to catch new mixed content from editors adding http images.