ERR_SSL_PROTOCOL_ERROR on all Let's Encrypt ECDSA certs since 1.89.141 update (macOS)

Brave Browser Desktop Support
1

Description of the issue:
Since updating to 1.89.141, all self-hosted sites secured with Let’s Encrypt ECDSA certificates return ERR_SSL_PROTOCOL_ERROR. The same sites load without issue in Safari. No changes have been made to the certificates or server configuration.

How can this issue be reproduced?

  1. On macOS, update to Brave 1.89.141 (Chromium 147.0.7727.102)
  2. Visit any site with a Let’s Encrypt ECDSA certificate (E8 intermediate / ISRG Root X2)
  3. ERR_SSL_PROTOCOL_ERROR is returned

Expected result:
Sites load normally as they did on the previous Brave version.

Brave Version:
1.89.141 Chromium: 147.0.7727.102 (Official Build) (arm64)

Additional Information:
Certificates are issued by Let’s Encrypt’s E8 intermediate, chaining to ISRG Root X2 (ECDSA root). All certs are valid and not near expiry. The Chromium 147.0.7727.102 update includes a PKI root store change (net/data/ssl/chrome_root_store) dated April 14 2026. Brave on macOS uses its own built-in root store rather than the macOS system keychain — Safari trusts the same certs without issue, suggesting the Chrome root store update has changed how ISRG Root X2 is trusted or constrained in Brave specifically.

2

@burgundyoffice

Are you using a Wi-Fi captive portal?

3

No captive portal - this is a reproducible issue on a standard home network (for reference, I’m connected via LAN in case that’s helpful). The sites load fine in Safari on the same machine and same network connection.

4

@burgundyoffice

What ChatGPT had to say:

Short version:

The update to Brave (Chromium 147) probably changed how its built-in Chrome Root Store handles ECDSA chains - specifically those from Let’s Encrypt using ISRG Root X2 via the E8 intermediate.

Since Brave uses its own root store (not macOS Keychain like Safari), it can break independently even when Safari still works fine.

Why this is happening

A few important moving pieces:

  • Let’s Encrypt introduced ECDSA chains: E8 intermediate → ISRG Root X2 (ECDSA root)
  • Chromium maintains its own Chrome Root Store
  • Brave uses that root store instead of macOS trust

In Chromium 147, there was a root store update (April 2026). That could have introduced:

  • New trust constraints on ISRG Root X2
  • Changes to allowed signature algorithms
  • Path-building differences (ECDSA vs RSA preference)
  • Or a regression/bug affecting ECDSA chain validation

Safari works because it relies on:

  • macOS Keychain (which still trusts ISRG Root X2 correctly)

Most likely cause

The strongest hypothesis is:

:backhand_index_pointing_right: A regression in Chromium’s certificate path validation for ECDSA chains

Specifically:

  • Failure to properly build or validate the chain: Leaf → E8 → ISRG Root X2
  • Resulting in: ERR_SSL_PROTOCOL_ERROR (Chromium’s catch-all for handshake/cert validation failure)

This aligns with:

  • No server changes
  • Only Brave affected
  • Only ECDSA certs affected
  • Timing matches root store update

How to verify (useful for debugging)

If someone wants to confirm this is the issue:

1. Test with RSA chain

Reissue the cert using Let’s Encrypt’s RSA chain (R3 → ISRG Root X1)
→ If it works, that strongly confirms an ECDSA-specific issue.

2. Inspect the cert chain

Use:

openssl s_client -connect yoursite:443 -showcerts

Check that:

  • E8 intermediate is correctly served
  • No missing intermediates

3. Try Chrome vs Brave

  • Same Chromium version Chrome (if available)
  • If Chrome works but Brave doesn’t → Brave-specific issue
  • If both fail → Chromium root store bug

4. Toggle Brave flags (temporary test)

Try disabling Chrome Root Store (if flag exists):

chrome://flags/#use-chrome-root-store

→ If disabling fixes it, that confirms root store regression

Workarounds (until fixed)

  • Switch to RSA certs temporarily (most reliable workaround)
  • Or serve dual certs (RSA + ECDSA) if your server supports it
  • Use Safari/Firefox for affected sites
  • Roll back Brave (if feasible)

What should happen next

This is almost certainly something that needs to be fixed upstream:

  • Either in Chromium
  • Or in Brave if their integration differs

A good bug report should include:

  • Example domain
  • Full cert chain
  • Output of openssl s_client
  • Confirmation RSA chain works

Bottom line

This doesn’t look like user error or misconfiguration.

It strongly points to a regression in Chromium’s root store / ECDSA validation path introduced in version 147, which Brave inherits.

@Mattches - possibly a regression in Chromium’s root store / ECDSA validation path introduced in version 147, which Brave inherits.

5

It’s probably a Chromium issue yeah but just to make sure @burgundyoffice can you test against another Chromium-based browser and see if you get the same results as in Brave?

Additionally, in Brave, what do you have your HTTPS upgrades Shields setting set to?

6

Hmm, well there goes my idea that it might be RTC related (your computers internal clock, as SSL relies on it being correct). If it were RTC related, all browsers would be acting up, not just one.

I second this test more than the second part of the question, as I don’t think shields can in any way actually cause an SSL error like this (anything’s possible, but I think the former question is more important since those certs were inherited via Chromium itself).

7

Shields are max, however, when I turn them off for these sites, it still doesn’t work.

When I open the same pages in Wavebox (Chromium) they don’t open either…

8

@Mattches , based on their response, is it possible Let’s Encrypt is using SHA-1 which Chromium no longer supports? From what I gather though SHA-1 was deprecated by Chromium in 2023 and the user said it was working on previous versions of Brave, and I assume they aren’t referring to a 3 year old version. (Though assuming is bad.)

9

@burgundyoffice can you please share any example sites where you’re getting this error?

10

An example would be good, because community.brave.app uses Let’s Encrypt as well, and we all seem to be here just fine.