Content Website Platform cwp.sg

Error SSL · ssl

ERR_SSL_PROTOCOL_ERROR

In one line

The browser and server could not agree on how to encrypt the connection — usually because there is no certificate on that hostname yet.

Ben Johnson · last verified 2026-08-04

Also seen as: This site can't provide a secure connection · SSL handshake failed · SSL_ERROR_NO_CYPHER_OVERLAP

What it actually means

Before any page loads over HTTPS, the browser and server negotiate: which TLS version, which cipher, and which certificate. ERR_SSL_PROTOCOL_ERROR means that negotiation failed outright.

The browser never got as far as requesting a page, so nothing about your files or your PHP is involved.

On shared hosting the overwhelming cause is timing: the certificate has not been issued yet. Certificate issuance requires DNS to be pointing at the host first, so for a few minutes after a domain change there is a window where the domain resolves but the certificate does not exist.

If you just changed DNS, wait ten minutes before debugging anything.

Diagram illustrating ssl errors on shared web hosting.

Why it happens

No certificate has been issued for this hostname

The most common cause by far. Certificates are issued per hostname, and issuance needs DNS pointing at the host so the certificate authority can validate ownership.

A certificate for example.com does not cover www.example.com unless both were included. Both need to exist.

The certificate expired

Let’s Encrypt certificates last 90 days and are meant to renew automatically. Renewal fails silently when DNS changed, the domain was removed from the account, or a redirect blocked the validation request.

Sites that worked for months and suddenly break on a Tuesday are usually this.

TLS version mismatch

Modern browsers refuse TLS 1.0 and 1.1. A server offering only those gets rejected before anything else happens. This affects old servers, not current shared hosting.

Something is intercepting the connection

Corporate proxies, some antivirus products, and public wifi captive portals inspect TLS by substituting their own certificate. When they do it badly you get this error on one machine or network while everyone else is fine.

How to fix it

1. Confirm DNS resolves to your host first

Certificate issuance cannot happen until it does. Check with the DNS propagation checker, or:

dig +short example.com @1.1.1.1

If that returns nothing or the wrong address, fix DNS and wait. The certificate follows automatically. See pointing a domain at your host.

2. Look at what the server is actually serving

curl -vI https://example.com 2>&1 | grep -E 'subject:|issuer:|expire'

That shows the certificate’s names and expiry. Three things to check:

  • expire date in the past — renewal failed. Reissue from your control panel.
  • subject does not list the hostname you typed — the certificate does not cover it. www and the bare domain are separate names.
  • No output at all — no certificate is being served.

3. Issue certificates for both www and non-www

Whichever one you redirect from still needs a valid certificate, because the browser completes the TLS handshake before it ever sees your redirect.

This catches people constantly: they redirect www to the bare domain, assume www needs no certificate, and every visitor typing www hits this error.

4. Test from another network

Load the site on mobile data with wifi off. If it works there but not on your usual network, the problem is local — an antivirus TLS scanner, a corporate proxy, or a captive portal — and nothing on the server needs changing.

5. Check the Cloudflare SSL mode

If Cloudflare is in front, set SSL/TLS → Overview → Full (strict). Flexible mode causes a redirect loop instead (too many redirects), and Off disables HTTPS entirely.

On CWP specifically

Our platform

CWP issues a free certificate automatically for every subdomain and every custom domain, but only once DNS points at us — the certificate authority has to verify ownership first.

So the normal sequence for a custom domain is: point DNS, wait for it to resolve, then the certificate appears within a few minutes. Seeing this error immediately after a DNS change is expected. The Domains page in your control panel shows the live status of each certificate.

Still stuck?

Post the exact error and your account name on the community forum — staff and other users answer there, and the thread helps the next person who hits this.