# ERR_SSL_PROTOCOL_ERROR

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

Source: https://cwp.sg/errors/err-ssl-protocol-error/  
Author: 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 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.

## 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](/tools/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](/guides/how-to-host-a-website/point-a-domain-to-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](/errors/err-too-many-redirects/)), and *Off* disables HTTPS entirely.

## On CWP hosting specifically

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.

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.