XMPP Service Operators - 2026-01-12

dnsviz validates DNSSEC is set up correctly or not (that link says it was updated an hour ago and DOES NOT have secure delegation from EU to erebion.eu) since DNSSEC is a pre-requisite for DANE, nothing else matters, it's invalid

> dnsviz validates DNSSEC is set up correctly or not (that link says it was updated an hour ago and DOES NOT have secure delegation from EU to erebion.eu) > > since DNSSEC is a pre-requisite for DANE, nothing else matters, it's invalid Oh, I wanted to set up DNSSEC, but after DANE. Guess I'll need to re-order my to do list. Thanks. :)

ah yea that'll do it, np (note the hash the first one gives you is the one you'll need for DANE)

> ah yea that'll do it, np (note the hash the first one gives you is the one you'll need for DANE) I want to use the hash of the CA and not my cert, so that's not the one I want to use

0 1 2, not 2 1 2, I believe

Oh, it'd be 1 1 2 in that case

"CA Constraints" vs "Certificate Constraints" should be the terms

Got DNSSEC now, monocles still says DANE failed and I don't know why

> Got DNSSEC now, monocles still says DANE failed and I don't know why Maybe it takes some time to propagate ↺

erebion, DANE is... well tl;dr that won't work, you want to re-use the same key across cert renewals, and pin that key with DANE

erebion: monocles expects DANE for your cert key. So theoretically you can setup I for your CA but then monocles will say it failed.

No need to pin a private key for DANE and compromise security if you can automate everything when the cert is updated. That's what I do... add new TLSA when the cert is renewed, wait for the record TTL to expire, update the cert where it's needed, remove the old TLSA. Multiple records of that type are fine, as long as at least one matches the current cert.

what part is "compromising security" though, that sounds overcomplicated and less secure

Cert Pinning?

cert pinning bad key pinning good

ah tru

> No need to pin a private key for DANE and compromise security if you can automate everything when the cert is updated. That's what I do... add new TLSA when the cert is renewed, wait for the record TTL to expire, update the cert where it's needed, remove the old TLSA. Multiple records of that type are fine, as long as at least one matches the current cert. Private key?! No, of course you would use the public key...

I've now added my public key to the record instead of the cert itself and monocles still says it is invalid....

I'm starting to think monocles is just broken

Any other clients I could try for DANE?

gnutls-cli shows a different Hash for the public key.

openssl rsa -in pubkey.pem -pubout | sha512sum <- this was my method for obtaining it, maybe that's wrong

This says failed: https://www.huque.com/bin/danecheck This says valid: https://www.uriports.com/tools/dane-validator?domain=erebion.eu&port=5223&protocol=tcp

Now, wich one is right?

> > No need to pin a private key for DANE and compromise security if you can automate everything when the cert is updated. That's what I do... add new TLSA when the cert is renewed, wait for the record TTL to expire, update the cert where it's needed, remove the old TLSA. Multiple records of that type are fine, as long as at least one matches the current cert. > > Private key?! No, of course you would use the public key... What I meant was keeping the same private key, so that the public key remains the same. Of course you wouldn't put your private key in a TLSA record. ↺

It is debatable if using a private key for a longer time compromises any security. It shouldn't matter. But in any case. Currently one won't find a client that checks DANE for anything then for the cert key

> Any other clients I could try for DANE? Cheogram ↺