“Domain not verifiable”

cocker-cc commented

2023-05-08 11:35:15 +00:00

After several Years I migrated my Prosody-Server from an “All-in-one-Server” (Webserver + XMPP-Server) to an XMPP-only-Server.
My Cert comes from Letsencrypt, and obviously it does only contain xmpp.example.com and not example.com.
I have these SRV-Entries set:

_xmpp-client._tcp.example.com. 3600 IN SRV 0 5 5222 xmpp.example.com.
_xmpps-client._tcp.example.com. 3600 IN SRV 0 5 5223 xmpp.example.com.
_xmpp-server._tcp.example.com. 2048 IN SRV 0 5 5269 xmpp.example.com.
_xmpps-server._tcp.example.com. 2048 IN SRV 0 5 5270 xmpp.example.com.

Conversations will not let me authenticate with my JID test123@example.com. Instead it complains “Domain not verifiable”. As soon as I specify the explicite Host xmpp.example.com in the Accountsettings everything works fine.

Why is this the Case? Why does Conversations not respect the SRV-Entries?

Server2Server-Communication behaves exactly as it should. A Message from test456@jabber.de directed to test123@example.com knows which Server to contact, according to the SRV-Entries.

Sidenote: I also opened a similar Issue for Gajim, which does not let me authenticate at all.

After several Years I migrated my Prosody-Server from an “All-in-one-Server” (Webserver + XMPP-Server) to an XMPP-only-Server. My Cert comes from Letsencrypt, and obviously it does only contain `xmpp.example.com` and not `example.com`. I have these `SRV`-Entries set: ``` _xmpp-client._tcp.example.com. 3600 IN SRV 0 5 5222 xmpp.example.com. _xmpps-client._tcp.example.com. 3600 IN SRV 0 5 5223 xmpp.example.com. _xmpp-server._tcp.example.com. 2048 IN SRV 0 5 5269 xmpp.example.com. _xmpps-server._tcp.example.com. 2048 IN SRV 0 5 5270 xmpp.example.com. ``` Conversations will not let me authenticate with my JID `test123@example.com`. Instead it complains “Domain not verifiable”. As soon as I specify the explicite Host `xmpp.example.com` in the Accountsettings everything works fine. Why is this the Case? Why does Conversations not respect the `SRV`-Entries? Server2Server-Communication behaves exactly as it should. A Message from `test456@jabber.de` directed to `test123@example.com` knows which Server to contact, according to the SRV-Entries. Sidenote: I also opened [a similar Issue](https://dev.gajim.org/gajim/gajim/-/issues/11515) for Gajim, which does not let me authenticate at all.

iNPUTmice commented

2023-05-08 11:45:20 +00:00

Owner

The certificate must match the domain name (the part behind the @ in your XMPP address); not the hostname.

Or more specifically it must match something the user (you) has entered. That’s why it works if you enter the hostname.

DNS (without DNSSEC) is not a trusted chain.

Edit: s2s only works because it falls back to dial back. On server that don’t have dialback s2s requires the domain name in the cert too.

The certificate must match the domain name (the part behind the @ in your XMPP address); not the hostname. Or more specifically it must match something the user (you) has entered. That’s why it works if you enter the hostname. DNS (without DNSSEC) is not a trusted chain. Edit: s2s only works because it falls back to dial back. On server that don’t have dialback s2s requires the domain name in the cert too.

iNPUTmice closed this issue

2023-05-08 11:45:20 +00:00

cocker-cc commented

2023-05-08 12:08:08 +00:00

Poster

DNS (without DNSSEC) is not a trusted chain.

But my DNSSEC is valid…

What's then the Point of those SRV-Entries, when they are not respected?

> DNS (without DNSSEC) is not a trusted chain. But my DNSSEC is valid… What's then the Point of those `SRV`-Entries, when they are not respected?

iNPUTmice commented

2023-05-08 12:19:47 +00:00

Owner

What's then the Point of those SRV-Entries, when they are not respected?

To derive the hostname from the domain. Finding the server on the network is independent of verifying the certificate.

You can try to enable 'Validate hostname with DNSSEC' in the expert settings.

Having the domain name in the certificate is the correct(tm) setup unless you have very very good reasons not to do this.

> What's then the Point of those SRV-Entries, when they are not respected? To derive the hostname from the domain. Finding the server on the network is independent of verifying the certificate. You can try to enable 'Validate hostname with DNSSEC' in the expert settings. Having the domain name in the certificate is the correct(tm) setup unless you have very very good reasons not to do this.

cocker-cc commented

2023-05-08 13:34:30 +00:00

Poster

Thanks for the Explanation. Because I recognized this is not something negotiable, I upgraded my Cert with the pure Domain, using Letsencrypt's DNS-Validation.

“Domain not verifiable” #50