XMPP Service Operators - 2024-09-16

moparisthebest, I just checked. For XMPP stuff I use the dehydrated script to create new certs. There is a setting PRIVATE_KEY_RENEW="no" and I see that the private keys are only renewed from time to time. I guess because there is an expiration date.

For openim.de there is only one private key, which was created last year when I took over the domain. So 1.5 years ago.

So I am a bit lost why there is/was a problem with TLSA. When I checked everything was okay...

According to https://www.huque.com/bin/danecheck it's OK now.

Thanks for checking. It was okay yesterday at 8:25pm, too. Checked with sys4.de

No idea if there really were problems before.

>> 15.09.24 18:36:18 - mdosch.de: Establishing a secure connection from mdosch.de to openim.de failed. Certificate hash: e848346b9b635ab1f58cafe6249547aaf3a83e07b35bb6330d742a2ea38a0a45. Error with certificate 0: no matching DANE TLSA records. But seems now the hash is different:

https://files.mdosch.de/upload/2ZHq7FQBIISVtStLQ6junnM2/bIZTQhVpRoWOSHydERGT2A.jpg

Hacked!! 😉 (maybe serious?) 😂

Didn't propagate all the way to the xmpp cert checker yet https://certwatch.xmpp.net/ ✏

Ah, i checked openim.de for TLSA with huque… …when checking jabber.hot-chili.net it fails indeed.

https://files.mdosch.de/upload/W-NrKRw46CmGdnQZlHevIvG3/2024-09-16-201432_grim.png

Roi: so with keeping the key (good) and the record type of 3 1 1 (good: roughly, pinning the key) you don't need to change DNS records at all when renewing the cert The problem is you are using a different key for the openim.de cert and the hot-chilli.net cert but only have 1 tlsa record and therefore 1 key allowed, that's what Martin's screenshot shows The solution is to add a tlsa record for each key port 5269 on jabber.hot-chilli.net is configured to serve, once, and you never have to touch it again unless you change keys

And don't forget the 2 c2s ports 5222 and 80

Yeah it's important to note that the srv target will be validated. I'm using the same key for all my certs on the same server, only one tlsa record😬

Nothing wrong with that

There is 0 reason to ever rotate a key unless you have reason to believe it's been compromised

> The problem is you are using a different key for the openim.de cert and the hot-chilli.net cert but only have 1 tlsa record and therefore 1 key allowed, that's what Martin's screenshot shows There should be TLSA keys for every host/service in the zone files.

I'm a little confused. What is not correct in the check Martin ran? Is there a TLSA record or is it the wrong one? Or do I need all TLSA records for every domain for port 5269? Which I would also need to check if this is set or not.

It's some time ago I set everything up here...

Roi: jabber.hot-chilli.net offers a cert with a fingerprint different from the one pinned in jabber.hot-chilli.nets TLSA records.

AFAIU. I'm also not the expert in all this TLSA DANE stuff.

Roi: run `dig tlsa _5269._tcp.jabber.hot-chilli.net` I get 1 record, this is used for all connections to here, including openim.de connections

Martin, you used https://www.huque.com/bin/danecheck for the check?

And whatever other domains you are hosting if they are DNSSEC enabled too

Entering jabber.hot-chilli.net, port 5269 and xmpp s2s shows green...

Roi: Yes

Funny, now it's green here as well. Earlier it failed…

moparisthebest, I do not understand. It should matter if you connect to the different domains.

Only for SSL one cert is served for all domains.

Nope, go to your tool https://www.huque.com/bin/danecheck Enter jabber.hot-chili.net + 5269 up top Check XMPP s2s In service, enter jabber.hot-chili.net, this passes Now go back and leave everything the same but change service to openim.de, this fails because it serves a different cert

Martin, I just checked. The cert was last updated on August 4th. And as I reuse the key, the TLSA record should not have changed. 🤷‍♂️ As I said, I am bit of lost here. I do not understand many of the details or these do not match...

moparisthebest, But why should I change the service name and not the host name?

In Prosody there is no main vhost. So it matters to which domain you are connecting. Client and server.

Except SSL and HTTPS, there you can only provide one cert for all connection, no matter which hostname you are using.

Because srv records for both openim.de and jabber.hot-chili.net point to the same right?

They both point to port 5269 on jabber.hot-chilli.net

I use hostnames in the SRV records, right. Everybody does. Especially if you are running other services like web for the same hostname (domain) you have to do it that way.

But from that port you are serving 2 different certs depending on domain you ask for

But tlsa has only 1 key pinned

Yeah because the domain name should matter. Not where the SRV record is "forwarding" this.

Nope that's not how DNSSEC/TLSA work

https://upload.jabber.hot-chilli.net:5281/file_share/600709ad-332d-4dcc-ba07-ea8bfdbf4372/2024-09-16%2020_52_38-Check%20a%20DANE%20TLS%20Service%20%e2%80%93%20Opera.png

In my eyes this is okay.

That's secure delegation so connecting to openim.de with Dane uses the tlsa record at _5269._tcp.jabber.hot-chilli.net

Btw, I cannot set more than one TLSA record the way I am updating the certs and records. So that would be a big problem.

You shouldn't set them when updating certs, only once then never again

> https://upload.jabber.hot-chilli.net:5281/file_share/600709ad-332d-4dcc-ba07-ea8bfdbf4372/2024-09-16%2020_52_38-Check%20a%20DANE%20TLS%20Service%20%e2%80%93%20Opera.png It's not ok because your srv records don't say to connect here, so nothing does, and so nothing grabs that TLSA record ↺

At some point the private key will expire. Then what? I would need to monitor that and update by hand. Great.

So to fix your setup: 1. Remove updating TLSA records when renewing certs since they always stay the same there is no need 2. Either add multiple tlsa records to the srv target, or change all srv targets to point to their own target with their own tlsa record

Private keys never expire

Thank you. But I still do not understand.

Let me check something.

Okay... I am using a hot-chilli.im account and the SRV records are the same as for any other domain here. So 5222 and 5269 points to jabber.hot-chilli.net

If I check the cert in Gajim, it should be the jabber.hot-chilli.net cert. As you said that because of the SRV record the jabber.hot-chilli.net domain is used and clients are sent there?

But I see the hot-chilli.im cert in Gajim

So if I (the client) would like to check TLSA it does not make sense to check jabber.hot-chilli.net but hot-chilli.im

Same with openim.de and so on.

Or I am really lost here and totally on the wrong train...

no that is not how TLSA works

I am a client or server that supports DANE, I want to connect to openim.de, so I ``` $ dig +short srv _xmpp-server._tcp.openim.de 0 0 5269 jabber.hot-chilli.net. ``` that response is signed with DNSSEC and validates, so I know I can connect to jabber.hot-chilli.net:5269, and now I will accept a cert valid for *either* openim.de *or* jabber.hot-chilli.net so I request the TLSA record for that target: ``` $ dig +short tlsa _5269._tcp.jabber.hot-chilli.net. 3 1 1 C953D7B5EA30F4D579D9F3CD6842A2A3AE3B01E9A63A4AB6E7165B25 4B074B52 ``` that's also DNSSEC signed, so now I will ensure the public key matches, but your server gives me the cert for openim.de and the public key doesn't match

That is very unpleasant.

Does it make sense from a technical point of view?

the 2 ways you can fix this: 1. if ``` $ dig +short tlsa _5269._tcp.jabber.hot-chilli.net. 3 1 1 C953D7B5EA30F4D579D9F3CD6842A2A3AE3B01E9A63A4AB6E7165B25 4B074B52 3 1 1 OTHERKEYVALIDFOROPENIMDECERT 4B074B52 ``` it will just work 2. if ``` $ dig +short srv _xmpp-server._tcp.openim.de 0 0 5269 openim.de. ``` then I will grab the TLSA key for that target: ``` $ dig +short tlsa _5269._tcp.openim.de 3 1 1 C1B74D329E7766D6E8263A6251DDF7813ED558DB6D9746B5F9E64DB3 449C754E ``` and assuming it's right it'll connect

So SNI or whatever it is called here is not used?

SNI is used and you hand back a different cert on the same target which is the cause of the problem, if you squint lol

this makes sense because in a world where everyone uses DANE, you only need 1 cert here for unlimited domains

Okay thank you again. I still do not understand (or want to understand, as it seems that I need to do something and that it was wrong for many years), but I will take care of it. Solution number 1 sounds less worse to me at the moment...

Done. Now 5222 and 5269 for jabber.hot-chilli.net have both a lot of TLSA records.

Test still fails the way you did it - maybe caching is involved...

Don't forget port 80 on server.jabber.hot....

Ah you're right

> Sep 16 21:35:48 s2sout559ce62580c0 debug connection mdosch.de->openim.de is now authenticated for openim.de \o/

> Don't forget port 80 on server.jabber.hot.... Thank you. Done, too.

For the future I would recommend you use https://certwatch.xmpp.net/ Roi, it's specifically made for xmpp and will exactly say what records it expects where if there is an issue

Only the propagation takes quite some time there

Well this checker is still not so happy about openim.de... Caching or still a config problem?

I bet caching, or slow propagation to their end. Just wait for it. Will be happy tomorrow

(because my server is) ✏

Okay I will wait and try again tomorrow. :-)

Once it is happy, It will also tell you how to subscribw to it, so you'll get informed when even it detects a mitm / misconfiguration again

I'm not too young anymore, but I can still wait a day or two... ;-)

Menel, yeah I know. I once subscribed to jabber.hot-chilli.net and did not continue with the other domains.

I was stucked with hot-chilli.im and noticed that .im domains do not support DNSSEC. Btw, MattJ, you do not know any news about this? ;-)

I will wait some hours and then check too thanks for fixing Roi , also sorry if I was poor at explaining

No I do not search the problem on your side. Thank you for your patience. :-D

When you stare into the eye of DNSSEC/Dane too long I think something breaks in your brain

🤣😂

Also it's super cheesy but this legitimately helped me understand this better early on https://wiki.xmpp.org/web/The_Knight

Predates DANE but the DNSSEC part is right

Maybe it's bad somehow, but I didn't have patience with all the ports entries and just did *._tcp.xmpp.example.com for the tlsa record. Is `*.*.*.example.com` possible btw? 😂 ✏

I spent a stupid amount of time with all components and ports all with different certs and i'm honestly not sure if it was worth it

But it's scripted at least /shrug