XMPP Service Operators - 2026-03-04

freespoken.nz: So there is interest an a xmpp ca

> Wouldn't it be better to encourage adoption of DANE for authentication instead? DANE just shifts the problem onto domain registrars and assumes everybody has dnssec setup properly.

I'm not arguing against DANE demployment, just saying it's not the end all be all or a perfect replacement for CAs

The original vision for certificate authorities was it would have been a service offered by your local notary, bank, post office, IT company

a new much worse CA than LE isn't a fix either though

That's why there's all the finds for state and organizational units

> > Wouldn't it be better to encourage adoption of DANE for authentication instead? > DANE just shifts the problem onto domain registrars and assumes everybody has dnssec setup properly. thats not how DNSSEC works ↺

> I'm not arguing against DANE demployment, just saying it's not the end all be all or a perfect replacement for CAs No it is the perfect replacement for a CA, as you dont need a chain of trust, which you cant trust, you are trusting the site directly, generally you want your own DNSSEC keys so you can sign your own zones, and not trust a registrar. ↺

the only downside is DNSSEC isn't supported on all tld's but also DNSSEC crypto is not the strongest

> yep, and until then LE works fine Except it isn't. The new Let's Encrypt CA policy on client/server certificates the EFF is being forced to do at the behest of the google chrome browser monopoly literally requires XMPP server implementations such as prosody and ejabberd to implement workarounds to not implement the authentication spec properly

All because google only cares about x509's usage in google chrome in a web based application.

> > yep, and until then LE works fine > Except it isn't. The new Let's Encrypt CA policy on client/server certificates the EFF is being forced to do at the behest of the google chrome browser monopoly literally requires XMPP server implementations such as prosody and ejabberd to implement workarounds to not implement the authentication spec properly Wouldn't be an issue if DANE Is the standard :) ↺

It could be made eventually that CA is entirely ignored, and DANE is used exclusively, allowing for self-signed certs to be trusted via TLSA

no it doesn't, the bug only existed in ejabberd, all other servers had done it the right way for decades

ejabberd used to do it the right way too but accidentally broke their impl and didn't notice

icebound.dev: potentially there isn't a need for self-signed certs either. There's been updates to x509 since the last time I visited the CA issue. You can now limit certificate authority certificates to specific namespaces instead of having godmode certificates that can authenticate anything and everything like letsencrypt

I have a certificate authority certificate limited to only being able to sign *.nuegia.net certificates

> icebound.dev: potentially there isn't a need for self-signed certs either. There's been updates to x509 since the last time I visited the CA issue. You can now limit certificate authority certificates to specific namespaces instead of having godmode certificates that can authenticate anything and everything like letsencrypt Pretty sure thats been around for as long as I have been alive, but sure ↺

> I have a certificate authority certificate limited to only being able to sign *.nuegia.net certificates but nobody trusts you, so nobody will connect ↺

> but nobody trusts you, so nobody will connect Nobody trust me to what? Authenticate my own domain/

?

And only that

it wont be in any trust store by devault

default*

so s2s will fail and so will c2s

tom: so to be clear, ejabberd temporarily introduced a regression to their code and now no one should use LE ? wild

only really useful for internal deployment

moparisthebest: You have such an attitude & complaining problem with almost everybody here.

It's not appreciated

opinions are like assholes, everyone has one and they all stink 🤷

Oh please all stay on topic and not start discussing the ways in which you think the other human sucks...

> moparisthebest: You have such an attitude & complaining problem with almost everybody here. Er, no. Mopar has a point, the move of LE isn't really a concern. ↺

I am not experienced in cryptography so I can't speak much about it, but it really is a small fish in a very big ocean

the bigger concern should be the length of certificate will drop right down, so you are renewing on a weekly basis, which is bound to break a lot of providers :p

> the bigger concern should be the length of certificate will drop right down, so you are renewing on a weekly basis, which is bound to break a lot of providers :p you mean make it easier for everyone to permanently fix their automation ↺

icebound.dev: can you join servers@joinjabber.org ?

> you mean make it easier for everyone to permanently fix their automation well yeah this will be a requirement. ↺

> icebound.dev: can you join servers@joinjabber.org ? Why? I will likely be banned upon joining. ↺

Any idea why?

because they don't like me? It doesn't matter, why are you asking me to join?

I would rather continue the discussion there.

Well its pointless me joining I will be banned on sight.

MattJ: do you know where I could find more information on xmpp.net's history?

> well yeah this will be a requirement. this is something I need to work on as well, I used to have working automation a while ago, but acme.sh broke a lot of DNS providers, so its hit or miss if you aren't doing http challenge. I want to experiment with some other options so I dont need to worry every 3 months about my certs not properly renewing. ↺

icebound.dev: ache.sh has a staging option you can use to test on alternate servers without being rate limited

> icebound.dev: ache.sh has a staging option you can use to test on alternate servers without being rate limited meh, over the years I have used it, it went from being reliable, to now where it barely works, and I am fed up of it. I am hopping ship. ↺

What changed?

dunno, just error after error

they also have zerossl default, and zerossl goes down a lot

so you got to remember to switch over to LE which is a lot more reliable

I have heard people have success with dehydrated, and there is always certbot which is a industry standard at this point.

I personally use caddy's automatic cert management and use a systemd filewatch to trigger the prosody import command on the cert store lol

I still use acme.sh with LE and the DNS challenge, haven't touched it for many years, just keeps working...

I couldn't get it work recently with mythic beasts

>> Wouldn't it be better to encourage adoption of DANE for authentication instead? > DANE just shifts the problem onto domain registrars and assumes everybody has dnssec setup properly. Can you expand on that please? It makes no sense to me. ↺

It seems odd to argue againat domain name holders, the people deploying services exercising more control and autonomy on their domain names.

DANE removes power from the CA Cartel and redistributes it across registrar and name owner, in fact, it empower name owners more then the CA Cartel method.

Ideally for now software should verify both TLSA and CA trust

https://www.moparisthebest.com/images/dane-vs-cab.jpg

nice website

> freespoken.nz: So there is interest an a xmpp ca I'm more interested in DANE making CAs obsolete. It would replace a system where we have dozens of independent single points of failure with one where only the DNSSEC root key is a single point of failure, which is an improvement, but still less than ideal, I admit. ↺

> I would rather continue the discussion there. Why was that Tom?

> https://www.moparisthebest.com/images/dane-vs-cab.jpg corporate needs you to spot the differences between these two images ↺