Let's Encrypt's Certificate Changes: What XMPP Server Operators Need to Know

Let's Encrypt is rolling out a significant change to how they issue certificates starting February 11th, 2026. While this change won't directly affect Prosody operators, it has the potential to cause connectivity issues between XMPP servers across the network. Here's what you need to understand about these changes and how they might impact your server's ability to communicate with others.

The Certificate Landscape is Shifting

Certificates are the backbone of secure communication on the internet. Certificate Authorities like Let's Encrypt verify that you control a domain, then issue certificates that prove this verification to others. These certificates contain not just your domain name, but also metadata about their intended use.

One crucial piece of metadata is the "Extended Key Usage" field, which specifies whether a certificate can be used for server authentication, client authentication, or both. Historically, Let's Encrypt issued certificates that could be used for both purposes. However, starting February 11th, they will issue certificates with only "server authentication" by default.

Why This Matters for XMPP

The XMPP protocol relies heavily on server-to-server communication, often called "federation." When one XMPP server connects to another, the initiating server acts as a TLS client, even though it's a server in the XMPP sense. This creates an interesting conflict with how certificate usage is traditionally interpreted.

Traditional TLS specifications would forbid using a server-only certificate for client authentication. Common TLS libraries like OpenSSL automatically check these certificate fields and will reject connections that don't match the expected usage patterns.

Prosody's Approach: Forward-Thinking Design

Fortunately for Prosody users, this isn't new territory. Years ago, the Prosody team anticipated potential issues like this and implemented alternative certificate validation logic. Prosody will accept server-only certificates for server-to-server connections, regardless of which server initiated the connection.

This approach aligns with what makes sense for XMPP's federation model, where servers frequently act as both clients and servers depending on the direction of communication. The Prosody team believes this is the correct approach for XMPP, even though it hasn't been standardized across the broader TLS ecosystem.

The Wider XMPP Ecosystem: A Mixed Bag

While Prosody handles server-only certificates gracefully, not all XMPP server implementations have caught up. The compatibility landscape looks like this:

Compatible servers: ejabberd (requires version 25.08 or later) Openfire

Potentially incompatible servers: Any server not explicitly listed above, particularly older versions of ejabberd and Openfire, may reject connections from servers using Let's Encrypt's new server-only certificates.

This fragmentation in the XMPP ecosystem could lead to federation issues where some servers can communicate while others cannot, depending on their software versions and configuration.

What Happens When Servers Don't Agree

If a server doesn't implement the alternative validation logic (either because the software doesn't support it or hasn't been updated), it will treat all server-only certificates as invalid for initiating server-to-server connections. This can lead to several scenarios:

1. Dialback fallback: Many servers still have dialback protocol enabled, which uses DNS to authenticate connections as a fallback. In this case, connections might still succeed, albeit less securely.

2. Strict certificate requirements: If either server has dialback disabled or requires valid certificates, the server-to-server connection will fail entirely.

3. Silent failures: You might see errors in your Prosody log files like "Server-to-server connection failed: Could not authenticate to remote server"

Testing Your Server's Compatibility

Want to know if your Prosody server can handle server-only certificates? There's a simple test you can perform:

Send an XMPP ping (using XEP-0199) to le-tlsserver.badxmpp.eu. If you receive a successful IQ response, your server accepts server-only certificates. If you don't get a response, check your server's log files for any incoming server-to-server failures.

This test server is specifically configured to use Let's Encrypt's new server-only certificates, making it an ideal way to verify your setup before the February 11th change takes full effect.

The Broader Context: Browser Vendors vs. Non-Browser Applications

The controversy around server-only certificates extends beyond just XMPP. The current certificate authority ecosystem is heavily influenced by web browser vendors (Google, Apple, Microsoft, and Mozilla), who are increasingly pushing back against non-browser applications using certificates from CAs they consider to be primarily serving web browsers.

An attempt to update the relevant specifications to clarify server and client roles failed to gain consensus at the IETF, leaving the XMPP community to navigate these changes independently.

What Server Operators Should Do

While Prosody users don't need to take immediate action, there are still steps you should consider:

1. Test your setup using the le-tlsserver.badxmpp.eu test server
2. Monitor your logs for any server-to-server connection failures
3. Communicate with other server operators in your federation about potential issues
4. Consider upgrading any non-Prosody servers you operate to compatible versions

For operators of incompatible server software, upgrading to a compatible version should be a priority to prevent federation problems.

Looking Ahead

This change from Let's Encrypt highlights the ongoing tension between web-centric certificate policies and the needs of other protocols like XMPP. As the internet continues to evolve, server operators in federated systems may need to become more proactive about testing compatibility and advocating for their specific use cases.

The good news is that Prosody's forward-thinking design means its users are well-positioned to handle these changes smoothly. However, the broader XMPP ecosystem may experience some growing pains as servers upgrade and adapt to the new certificate landscape.

The February 11th deadline is approaching quickly, so now is the time to test your setup and ensure smooth sailing for your XMPP federation connections.