SSL Not Working: Fix It by Stage

Read the error code before you change anything

An SSL error means the browser could not open a trusted encrypted connection. Read the code first: a TLS protocol error is not a certificate problem, while ERR_CERT_DATE_INVALID is an expired or not-yet-valid certificate. Fix the stage that failed, then re-check from outside with openssl or an SSL checker.

The code under the warning names the failure. Reinstalling a certificate that was never the problem is the usual way an hour becomes an afternoon.

The four stages of an HTTPS connection

Every HTTPS request goes through four stages, and the error tells you which one stopped. That is why generic advice helps some people and does nothing for the rest.

1. Connect. The browser opens a TCP connection to port 443. If the other end answers with plain HTTP or closes early, no certificate is involved.
2. Negotiate. Both sides agree a TLS version and cipher suite. A mismatch here is a configuration problem, not a certificate problem.
3. Validate. The server sends its certificate chain. Expiry, hostname coverage, trust and revocation are checked at this stage.
4. Carry data. The encrypted session is working. Failures now come from mixed content, HTTP/2 or QUIC, not from the certificate.

If the browser says the connection is not private and the code starts with ERR_CERT, you are at stage three. If it says protocol or cipher, you are at stage two, and a new certificate changes nothing.

Check the server from outside

Look at what the server actually sends, not at the file on disk. These commands show the chain, the dates and whether the hostname matches.

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts </dev/null
openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null \
  | openssl x509 -noout \
    -dates -subject
openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  </dev/null

Read the certificate list, not only the Verify return code line. If the output says no peer certificate is available, the handshake failed before validation and the certificate is not the fault. Run the same host through SSL Labs for a second opinion from outside your network.

Fix an incomplete certificate chain

Most authority errors are a missing intermediate. The browser trusts the root, the server sends its own certificate, and the link between them is absent, so the chain cannot be built.

1. Download the full chain from the CA: your certificate plus the intermediate, in that order.
2. In cPanel open Security, then SSL/TLS Status, and confirm the domain shows a valid certificate and a complete chain.
3. For a manual install, point the server at the combined file. Do not put the private key in that file.
4. Restart or reload the web server, then re-run the openssl command until the chain lists more than one certificate.
5. Test on a phone as well. Mobile platforms are stricter about incomplete chains than desktop browsers.

The click-path for a fresh install is in install SSL in cPanel. If the chain is complete and the error remains, move to dates and hostname.

Fix dates, hostname and coverage

Three certificate faults produce three different codes, so the fix depends on which one you see.

• Expired: renew and install. If the renewal was recent, a proxy or CDN may still serve the old certificate; query the live one.
• Not yet valid: the server clock or the certificate's start date is wrong. Fix NTP on the server before reissuing.
• Hostname mismatch: browsers check the subjectAltName list, not the common name. A certificate for example.com does not cover shop.example.com unless it is a wildcard or lists it.
• Wrong device clock: a visitor's phone or laptop months out of date reports ERR_CERT_DATE_INVALID on every site. That one is fixed on the device, not the server.
• Revoked: the CA cancelled the certificate. Reissue rather than reinstall.

After any change, confirm the dates from outside with the openssl command above. A browser that already cached the old certificate will keep showing the warning until it refreshes.

Fix mixed content when the padlock breaks

A page can load over HTTPS and still ask for an image, script, font or iframe over HTTP. The certificate is fine; the padlock is downgraded because part of the page is not encrypted.

1. Open the page, then DevTools, Console, and reload. Mixed-content warnings name the exact URL.
2. Search the theme or template for http:// and replace those resources with https:// or a relative path.
3. In WordPress, run a search-replace on the database for the old http URL, then check the customiser and widgets.
4. Add a Content-Security-Policy header with upgrade-insecure-requests as a safety net, not as the only fix.
5. In OpenCart or Magento, set the store URL itself to https; a store setting left on http recreates the problem on every page.

The Not secure warning guide covers the same fault from the visitor's side.

Prevent the next failure

Most repeat failures come from manual renewal, an incomplete chain after a migration, or a configuration change nobody re-checked. Three habits remove them.

• Automate renewal. On WebJi hosting, Let's Encrypt renews through AutoSSL every 90 days; leave it on.
• Monitor expiry from outside, so a broken renewal is an alert weeks early rather than a warning page on a Monday.
• Re-check after every migration, CDN change or panel update, and test on a phone as well as a desktop.

For a commercial certificate or a warranty, the SSL certificate page lists the options; PositiveSSL is ₹1,800 a year before 18% GST. If the chain looks correct and the error persists, email support@webji.services with the domain, the error code and the openssl output. Support answers 24/7 in Hindi and English, average first reply under 60 minutes.