ERR_SSL_PROTOCOL_ERROR after renewal

ERR_SSL_PROTOCOL_ERROR right after certificate renewal means the browser could not complete a valid TLS handshake—often mismatched private key, corrupt PEM paste, TLS version disabled on the listener, or a CDN still pointing at an old broken origin—not merely an expired notAfter you already replaced on disk.

Teams celebrate certbot “Congratulations” while Chrome shows a blank protocol error. Renewal changed files the process is not reading, or only half the load-balanced pool received the new bundle.

Protocol errors differ from ERR_CERT_DATE_INVALID. You may still see protocol failures when expiry was the trigger if the broken deploy removed the only valid cert entirely.

First response

Note exact URL, browser, and whether incognito fails the same way. Capture whether HTTP redirects to HTTPS on a port with TLS broken. Save certbot or ACME logs and the timestamp of last nginx/apache reload.

Run OpenSSL s_client immediately—protocol errors often show no protocols available, alert handshake failure, or abrupt connection reset instead of a parseable certificate.

Check whether WAF, CDN, or Kubernetes ingress was updated in the same change window. Split tests: origin IP direct versus public hostname through the edge.

Grab HSTS preload status: browsers that force HTTPS amplify protocol errors when port 443 is broken—users cannot fall back to HTTP to grab a status page. Have comms templates ready while TLS is repaired.

If renewal introduced ECDSA keys, confirm cipher suites enabled on Windows Server and older Android WebView builds used by embedded browsers because negotiation failures resemble protocol errors even when calendar dates are valid.

Executive bridges should distinguish protocol errors from certificate date warnings so communications teams send accurate customer messaging. Capture one failing URL per affected brand and avoid claiming global internet outage when only one hostname broke during renewal. After recovery, document which reload command actually applied new material so the next rotation repeats the working sequence instead of rediscovering it under pressure.

What this error means

Chromium reports protocol error when the connection never reaches a trusted certificate dialog—typically malformed ServerHello, absent cipher overlap, HTTP response on 443, or TLS terminator crash.

After renewal, common breaks include concatenating certificate order wrong (key in wrong file), ECDSA cert with RSA-only config, enabling only TLS 1.3 while legacy middleboxes interfere, or serving empty PEM because automation wrote to a path the daemon does not load.

Expiry-related renewals sometimes coincidentally fix dates but introduce incompatible key types. Separately, an actually expired cert can produce date invalid, not protocol error—when both appear across environments, suspect mixed pool members.

See Let's Encrypt renewal succeeded, site still expired when files updated but strangers see old material, and nginx reload after certbot for a common missed step.

Browsers bucket several failures under ERR_SSL_PROTOCOL_ERROR including malformed records and TLS received on HTTP ports. Packet captures showing cleartext HTTP responses after ClientHello indicate mis-pointed backends, not merely calendar expiry—still often triggered by editing the wrong server block during renewal night.

SNI misconfiguration can yield handshake abort without certificate details—use openssl s_client -servername for every hostname on a shared IP before assuming global outage.

Common causes

Renewal week chaos often mixes certificate expiry with configuration edits in the same maintenance window, which makes protocol errors feel mysterious even when calendars triggered the work. Change managers should insist on binary before and after handshake captures for at least one affected hostname so postmortems distinguish forgotten reloads from accidental HTTP exposure on port four forty three. Teams that treat protocol errors as purely client issues postpone fixes that are entirely server side, which extends customer impact across every browser and API integration at once.

fullchain.pem updated but privkey.pem still maps to previous key pair. Certbot --dry-run succeeded on a stand-in directory while production live symlink target differs.

Multiple server blocks: one vhost got new certs, default SSL server still serves outdated or empty config. Apache SSLCertificateFile without matching SSLCertificateKeyFile after manual edit.

Cloudflare or Akamai “strict” mode to an origin whose new cert is missing intermediate—some edges surface protocol errors instead of padlock details.

Kubernetes TLS secret updated with valid cert but ingress references wrong secret name in an alternate Ingress resource still attached to the load balancer.

HTTP/2-only listeners misconfigured after cert swap (ALPN list empty). HAProxy crt bundle unreadable permissions after chmod too aggressive.

Renaming certificate files without updating symlinks certbot maintains leaves nginx pointing at empty paths. Windows IIS occasionally binds a renewed cert in the management console while FTPS or secondary sites still reference the previous hash until an explicit SSL reboot.

Confirm from the outside

OpenSSL verbose handshake

HOST=www.example.com
openssl s_client -connect "$HOST:443" -servername "$HOST" -tls1_2 </dev/null

Watch for verify error versus immediate hang or wrong version number (plain HTTP on 443).

Test TLS versions

for v in -tls1_2 -tls1_3; do
  echo "=== $v ==="
  echo | openssl s_client -connect "$HOST:443" -servername "$HOST" $v 2>&1 | head -n 15
done

curl trace

curl -vI --connect-timeout 10 "https://$HOST/" 2>&1 | head -n 35

Origin bypass (when safe)

curl -vI --resolve "$HOST:443:ORIGIN_IP" "https://$HOST/" 2>&1 | head -n 30

Compare edge versus origin handshake to locate the broken hop.

Fix checklist

1. Validate PEM integrity: cert and key modulus match (openssl x509 -noout -modulus vs openssl rsa -noout -modulus).
2. Ensure ssl_certificate (or equivalent) includes full chain, not leaf-only after intermediate change.
3. Fix file paths in config to match certbot live symlinks actually renewed.
4. Reload all web servers, ingress controllers, and CDN uploads; roll pods mounting TLS secrets.
5. Confirm all pool members present the same serial number via external checks per IP if needed.
6. Re-enable sane TLS protocol lists; avoid experimental cipher-only configs unless required.
7. Retest browsers and curl SSL errors paths without bypass.
8. Document working serial and monitor hostname for future drift.

During change windows, capture openssl s_client output before and after reload and attach both to the ticket. When protocol errors linger, test from IPv6-only paths; some dual-stack listeners bind certificates on IPv4 vhosts but serve plain HTTP on IPv6 after a partial config merge.

If you terminate at multiple hops, renew in order from origin outward and retest after each hop. A healthy origin plus broken CDN upload produces protocol errors that disappear when you grey-cloud or bypass the edge—use that pattern to localize which team owns the broken PEM.

Communication during protocol errors should avoid promising a quick cache clear fix when handshake never reached HTTP. Give executives the minimal customer impact story: browsers cannot negotiate TLS at all on affected names until the broken PEM or cipher config is repaired. After recovery, attach a short root cause summary distinguishing expiry driven renewal mistakes from key mismatch or empty file paths so the next change window includes automated modulus checks and staged canary reloads.

When to use automation

Renewal automation that stops at certificate issuance without handshake verification exports risk to every downstream channel that depends on TLS. Product security teams should treat failed external handshakes as blocking findings in the same severity class as expired dates on customer hostnames. Dashboards that only track synthetic HTTP two hundred responses miss broken negotiations entirely, which is why live TLS oriented monitoring belongs in the same toolchain as certificate renewal success webhooks.

Protocol errors after renewal are deploy verification gaps. Automated live TLS probes on the customer hostname detect handshake failures even when file timestamps on one server look fresh. Use external check after every renewal window before closing change tickets.

Pair with expiry monitoring so renewal urgency does not encourage rushed PEM edits without post-deploy handshake tests. RDAP visibility on the domain helps when manual OV renewals stack with infra changes.

Add a post-renewal smoke suite that records openssl exit codes and browserless curl handshakes within five minutes of every certbot success hook. Protocol regressions are faster to roll back when you detect them before traffic shift completes.