Option to disable requesting client certificates?

[Dunedan]

By default ejabberd requests client certificates from every client establishing a TLS-connection. Is there an option to disable that?

We stumbled over this because some users reported problems connecting to ejabberd. What they have in common is that their client uses SChannel and their Windows certificate store contains client certificates. While we don't know what's causing SChannel to abort the connection, the most straight-forward way to get rid of this problem would be to not request client certificates in the first place, as we don't use them anyway.

One workaround we found to prevent clients from sending certificates is setting cafile to a CA which doesn't issue certificates, but we'd prefer not requesting client certificates at all. This would also save a few bytes during the TLS handshake.

In general I wonder if the defaults for cafile and tls_verify are useful. Don't they just cause ejabberd to request client certificates without doing anything with them afterwards?

[licaon-kter]

@Dunedan you've read https://blog.prosody.im/2026-letsencrypt-changes/ and you run newer than 25.08 ejabberd?

[Dunedan]

Yes, I'm aware of that, but I don't see how that relates to my question, which is about c2s connections.

[prefiks]

Did you explicitly enabled tls_verify: true in c2s listener (i think we don't set that by default)? The only purpose of this option is to enable accepting client certificates for authentications purposed, do removing this option still make client attempt to send certificate?

[Dunedan]

We did not set tls_verify in the configuration, so it defaults to false. However ejabberd requesting client certificates seems to be independent of this option right now. If my understanding is correct fast_tls doesn't even seem to support not requesting client certificates right now: https://github.com/processone/fast_tls/blob/29b669365464247228137c5479aa662593d7e269/c_src/fast_tls.c#L632-L640

[prefiks]

I added 5b03ca5, which should sending flag requesting client certificate if tls_verify is not set.

[nosnilmot]

It's been a while since I worked with this, but IIRC the correct way to disable requesting client certificates is to NOT set cafile. The only reason to set it on a c2s listener is to specify which CAs client certificates are accepted from.

That change to tls_verify looks worryingly like it might disable verification of client certs when they are optional, which could be a massive security issue.

[prefiks]

Afaik you need to have tls_verify: true (which this change also looks for), to enable EXTERNAL authentication method, and only if EXTERNAL auth is triggered we are checking validity of client cert, but i will investigate this.

[Dunedan]

It's been a while since I worked with this, but IIRC the correct way to disable requesting client certificates is to NOT set cafile. The only reason to set it on a c2s listener is to specify which CAs client certificates are accepted from.

Unfortunately not setting cafile doesn't disable requesting client certificates, but just doesn't add a constraint for specific CAs, so clients return certificates signed by whatever CA they have certificates available from.

That change to tls_verify looks worryingly like it might disable verification of client certs when they are optional, which could be a massive security issue.

I completely agree. How cafile and tls_verify work is not obvious and the documentation of these options isn't clear about it either.

[prefiks]

I did some testing, client certificates are only verified by ejabberd is EXTERNAL authentication method is triggered, if different method is choosen, ejabberd doesn't even look at what client cert was sent, even if client send wrong certificate but authenticates using password method, connection will be accepted (and i think this is correct thing per spec). Ejabberd accepts EXTERNAL auth only when tls_verify: true is set, so not requesting certificate if it's not set will not change how client certs are handled.