Hi!
When using ACME/LetsEncrypt SSL certs on Expressway and using the Expressway for XMPP Federation we experienced issues with SSL cert.
Using JIDs in the form of account@domain.com we added entries for CollabEdge DNS, the correct A records to additional alternate names and IM&P chat node aliases to the CSR, no XMPP federation domains (as service partner instructed us).
We then get a working SSL cert from LetsEncrypt, but that is missing domain.com entry. Although it might look currently as if everything is working, I'm unsure, because the IM Observatory server report on XMPP.net does report an issue with the SSL cert from LetsEncrypt missing domain.com:
A working exmaple not using LetsEncrypt is this one:
In my understanding of reading https://xmpp.org/rfcs/rfc6120.html#security-certificates it is mandatory to have domain.com when JID is user@domain.com - unless the domain.com zone would be signed by DNSSEC and _xmpp-server._tcp.domain.com record would have a TLSA RR as well, correct?
If so ACME/LetsEncrypt in the current implementation in Expressway is rather useless when Expressway is used in Enterprises for XMPP Federation, because it is rather unlikely (if not impossible) to have domain.com point to Expressway for ACME challenge/response. Similar unlikely like having major domain.com webserver farm redirecting /.well-known/acme-challenge to Expressway, also this would be possible.
Is this correct? Are there any other solutions for this kind of problem beside:
- buying a SSL cert instead of using LetsEncrypt/ACME
- signing the zone with DNSSEC and generate TLSA records
- redirect ACME challenge to Expressway on webserver farm?
