top | item 46952980

(no title)

forty | 21 days ago

The refusal to accept server only certificate as client certificate for server

discuss

order

MattJ100|21 days ago

There might be some confusion here, as there is no refusal at all.

As stated in the blog post, we (Prosody) have been accepting (only) serverAuth certificates for a long time. However this is technically in violation of the relevant RFCs, and not the default behaviour of TLS libraries, so it's far from natural for software to be implementing this.

There was only one implementation discovered so far which was not accepting certificates unless they included the clientAuth purpose, and that was already updated 6+ months ago.

This blog post is intended to alert our users, and the broader XMPP community, about the issue that many were unaware of, and particularly to nudge server operators to upgrade their software if necessary, to avoid any federation issues on the network.

forty|21 days ago

Sorry, I probably misunderstood, I thought there were resistance to update the corresponding specs. I understand that non XMPP specs might refuse to be updated, but at least this behavior could be standardized for XMPP specifically.

direwolf20|21 days ago

A common saying in the IETF is "there is no protocol police."

You don't have to do what the RFC says.

kokx|21 days ago

The article literally talks about how one of the server implementations does exactly that:

> Does this affect Prosody?

> Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. [...]