Missing TLS Client Authentication breaks galera distributed database

Issuance Policy
1

The fact that "Client Authentication" is no longer included in certificates breaks their usage for the Galera distributed database.

Apparently, Galera database nodes authenticate each other using client authentication.

Now that this is no longer included, the database cluster breaks with errors like

2026-02-26 17:08:05 0 [Warning] WSREP: Handshake failed: certificate verify failed: unsupported certificate purpose
2026-02-26 17:08:05 0 [Warning] WSREP: read_completion_condition(): sslv3 alert unsupported certificate (167773203: 'error:0A000413:SSL routines::sslv3 alert unsupported certificate')
2026-02-26 17:08:05 0 [Warning] WSREP: read_handler(): sslv3 alert unsupported certificate (167773203: 'error:0A000413:SSL routines::sslv3 alert unsupported certificate')

Did anyone ever consider this breakage before recklessly removing client auth from certificates?

2

Connectivity between database cluster nodes sounds like a bad use case for publicly trusted certificates. A private CA is going to be a much better solution there.

6 Likes
3

You can use a self signed certificate as described here Certificate Creation with OpenSSL | Server | MariaDB Documentation.

This can also allow you to set the subject to a suitable value.

3 Likes
4

Recklessly? That's harsh. Let's Encrypt announced this change last May ...

Here: Ending TLS Client Authentication Certificate Support in 2026 - Let's Encrypt
And: Ending TLS Client Authentication Certificate Support in 2026

The reason for the change (from those notices) is:

This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline.

5 Likes
5

So you just let google dictate to you that there are no valid uses of client certificates at all, none, literally zero?

The same google that already enshittified email (by demanding ridiculously complicated "anti-spam" measures, that in reality don't work against spam at all, but only serve to make independent email servers difficult, and hence help their own monopoly), you let them enshittify PKI as well?

Well thank you very much.

(I am trying hard to remain polite. It is very difficult, because I am very angry).

And no, changing to self-signed certificates is not a quick solution. Whatever you do, certificate wise, has to be rolled out to the whole database cluster. The quickest way is to disable TLS. Now that increases security. Not.

6

a) nobody says that. It's just that certs with client auth need their own hierarchie, which is not something Let's Encrypt can offer, nor fits within the goals of LE.
b) Google can do whatever they want with the rules for their root program. If you don't abide, your root certs can (and probably will) be removed from their root store.

Nobody says that. We only say this has been announced quite a while back and there is no good reason why this suddenly would be a surprise.

3 Likes
7

And if you need a workaround until you have time to migrate to a private PKI (or a public PKI from some CA that's making a separate client root), you can use the "tlsclient" profile in a modern ACME client to get one more renewal in the meantime.

5 Likes
8

It is a surprise, because galera doesn't really document that it requires certificates that are for client and server authentication...

9

Then it's not something you can blame Let's Encrypt for.

1 Like
10

As an independent mail operator, I disagree. The email sender guidelines require SPF, DKIM, DMARC and TLS.

SPF and DMARC can be fulfilled by two TXT records, for example

@ TXT "v=spf1 a mx ~all"
_dmarc TXT "v=DMARC1;p=reject"

DKIM (email signing) does require software support however opendkim can be used as a filter to sign messages.

Overall, these provide an effective framework for rejecting unauthorized mail and provides accountability for sending mail.

Edit: Google are actually less restrictive than Microsoft and other mail operators as Google doesn't actually require rDNS if SPF passes or check against the policy block list (a list of IP addresses covering residential ISPs).

3 Likes
11

Google has extended it's deadline until May of 2027. Let's Encrypt can and should honor that extension.

I have seen that there is a tlsclient profile for certificates, but I can't find an ACME client that supports profiles. Is there such a client (free)?

12

You must not have looked very hard. certbot supports them, as does acme.sh. So does Caddy, for that matter.

2 Likes