So I'm pondering automatic provisioning certificates in XMPP Server. As XMPP relies on SRV records mostly (you can have A record for example.com pointing to main www server and then SRV records of the same example.com pointing to xmpp service) it's somewhat challenging to add feature to automatically provision SSL certificate within software (with exposing .well-known http challenge). [Think akin to email address where quite often for single domain.com we have www that could handle HTTP challenge and MX records for mail…]
Right now the solution is to use software (certbot) with update hook that would call XMPP server rest-api to update software.
It would be very convenient to be able to use SRV records for "domain ownership" verification.
I'm aware that there is DNS-01 challenge (which also gives wildcard certificate) but that would require user providing access/credentials to their DNS service to add relevant ACME TXT entries and given that would mean access to complete zone I'd say only a few (or even none) would decide to do that.
There were a couple of topics touching on this years ago but at the time it was said "not possible"
Hi @_wojtek, and welcome to the LE community forum
They could delegate (via CNAME) their specific TXT record(s) to any other system and the changes could be made there instead.
That said, there is no "set-it-once-and-forget-it" validation type; All types require being able to be updated [once per validation request].
So, how would it be "convenient" with this specific DNS record type?
As I understand it, in this case the ACME client would have to update the SRV record instead of the TXT record.
That still requires DNS zone modification priviledges.
Hmm... I wasn't aware about extensions. Is there even slight probability that such extension could be devised (and included in, let's say, certbot?)
Hmm... I was pondering the "flow". Currently with HTTP-01 challenge protocol simply stipulates that request is made to the domain under which it exposes .well-known/acme-challenge/ (i.e. request is made to http://domain.com/.well-known/acme-challenge/<token>).
I'd imagine that for SRV records it would be the same: you have domain domain.com with SRV record pointing to my-deployment.com thus to get certificate for domain.com first it would resolve SRV records and then make http request to that domain (i.e. request is made to http://my-deployment.com/.well-known/acme-challenge/<token>)
There are a couple of issues but one of the most problematic would be multiple SRV records for XMPP (see SRV Records - XMPP WIKI):
_xmpp-client.
_xmpps-client.
_xmpp-server
_xmpps-server
In majority of cases (I'd wager 100% of cases) those would point to the same service but then certbot/acme would need to (?!) know that for "xmpp SRV" there are multiple endpoints.
Alternatively in the ACME protocol/extension one would specify all SRV records that would have to be checked (so 4 in above case) and then verification would have to be done on all (distinct) targets.
So for example:
_xmpp-client._tcp.domain.tld. 86400 IN SRV 5 0 5222 server.domain.tld.
_xmpps-client._tcp.domain.tld. 86400 IN SRV 5 0 5223 server.domain.tld.
_xmpp-server._tcp.domain.tld. 86400 IN SRV 5 0 5269 server.domain.tld.
acme would specify: "I want certificate" for 3 listed services, it determines 1 distinct target hostname (server.domain.tld) and makes the challenges to http://server.domain.tld/.well-known/acme-challenge/<token>
Alternatively maybe having single SRV service entry akin to _acme-challenge._tcp.domain.tld? But that wouldn't work for multiple different (type) services. Or in the end only single service type (_xmpp-client) would suffice to get target for obtantion of the certificate?
I explained it above though your idea with specific TXT record delegating certificate validation (with challenge-response still!) is quite interesting and something I try to suggest in more words
So (re-using previous examples):
domain.com creates TXT record <use server.domain.tld> for validation
certbot uses that domain when making http-01 challenge or owner of server.domain.tld (so hosting entity could update their DNS records).
Yes, but it's about handling the case where there are two entities:
xmpp service provider (exposing and having control over server.domain.tld
end-user with domain.com (it can have website, mail, whatnot) that wants to host that domain on service provided by (1). End user modify their DNS (domain.com) and service owner (2) can modify their DNS (server.domain.tld). Of course end user (1) could give credentials to their domain to service owner (2) but that seems like a security nightmare... being able for end user (1) to relegate challenges to service operator (2) would be very convenient.
I think it would NOT break ownership contract as user (1) still would have modified their DNS entries and it would NOT be "set once and forget" as the renewal would require solving challenge every 3 months.
EDIT: (haven't seen your reply)
Still, this requires additional deployment. I'd imagine that if someone host their website on github-pages this wouldn't work directly?
This seems to be a whole lot of "inventing a new wheel"...
Where there is already a simple wheel that can move this along.
I'm talking about simply using HTTP at the IP of the SRV record.
If:
domain.com = IP 1
service.domain.com = IP 2
then
I don't [yet] see any reason why an ACME client can't be spun up in standalone mode and used to obtain a cert for that service FQDN [this only requires having a regular DNS entry (A or AAAA or both) for that service FQDN - in addition to the SRV DNS record].
If an A or AAAA record already exists, then that should come first [before the SRV record].
[if the two record types are using different IPs, what then?] service.domain.com A = IP 3 service.domain.com SRV = IP 4
If only an SRV record is to exist, then ACME should use that as it would when an A/AAAA record exists?
So, the "complication" to me, seems to be when there are two IPs for the same name [one for each service]. But this case is hard to imagine in real (Internet) life. How would anyone find the SRV record? It would have to be an IP [not a name - as names would resolve via A/AAAA type]. This would make the cert require the "name" be that "IP" (or the secure request to the IP would never match the name on the cert - maybe).
Have you ever heard about concept of email? where you have website under https://my-company.com and then email as <user>@my-company.com? For this purpose MX records exists And SRVs are evolution of that - instead of creating new DNS type for each service you have generic one. And yes, XMPP identifiers follows email scheme so you can use <user>@my-company.com as both email and XMPP address.
Of course world moved "forward" and now we are stuck in a world "one to rule them all" (http protocol and it's port [well, we have two of those in this case 80 and 443])... Why? Because corpo-firewall-blocking eveyrhing non-web, because lot's of devs only understood http and so forth.
Due to that instead of having your twitter account as rg305@twitter.com you have https://twitter.com/@rg305 - same solution to previous constraints…
Have you read the linked wiki page? DNS resolution is not black magic.
Same as protocols defining it and the whole discovery.
Are you sure you need the certificate to be valid for domain.tld and not just for server.domain.tld? When using TLS with email you only need the certificate for whatever fqdn is in the MX record, not for the domain name in the email address.
No, you connect to whatever you get from MX record that you got while querying DNS. Now - DNS is plaintext protocol and if you connect to a spoofy wifi for example you get DNS response from that entity - it can then return MX record for gmail.com that points you to this-is-bad.com and said this-is-bad.com would give your client this-is-bad.com domain but if the client verifies only that domain then there is no verification…
When you connect to google gmail IMAP they tell you - configure client to use "imap.gmail.com" for your @gmail.com address... and when connecting you get cert for that domain:
Email is "a can of worms" where providers usually either provide server names or use "mailprofiles" for applications (and try to guess the server) or some try to use "_autodiscover.tcp." SRV record (but it's like yeti)…
Could you elaborate?
Yes, and they are defined in RFCs… but the point of SRV (and cert for such) would be discovery of the target hostname, and only hostname, not the port - as with broader world not everything is http-based so different services use different protocols thus you wouldn't be able to do http-challenge against this XMPP-port (maybe doing XMPP-01 LE challenge would be an option )
That's true, but again - if destination would provide certificate for the actual domain that we wanted to connect instead one matching resolved DNS record that would also be safer - isn't it?
As far as I can tell, you just confirmed exactly what @9peppe said while refuting @9peppe's response? I might be misinterpreting the intent of your writing.
To clarify, the point @9peppe was trying to make is that having a TLS certificate for example.com is utterly pointless for running a mail server for example.comunless one of these two conditions holds:
the example.com domain name itself (not one of its subdomain names) is serving its own mail (which would be incredibly strange)
no MX record is present for example.com per the caveat discussed below, which is really just a degenerate version of the first condition
This is the caveat in how MX records are handled that @9peppe was addressing:
In the absence of an MX record, email senders will attempt delivery to the address record - e.g. example.com.
This is based on RFC 5321 sec. 5.1, which states :
SMTP clients must look up an MX record;
If (and only if) no MX record for the domain is present, treat the domain as if it had an MX record with the given domain as the target hostname and a preference value of 0
Perform A or AAAA lookups as required to determine the IP address of the target hostname
Determining "which hostname am I expecting the server to present in its certificate" is really more nuanced and complicated than one would expect. I think the most recent recommendation is RFC 9525, though I don't really see in there from a quick skim-through how one is supposed to deal with SMTP/MX records. It does have some discussion of SRV records, though.
There is discussion of what hostnames to expect in TLS for user connections to mail servers in RFC 7817, but that document specifically isn't about the MX lookup for MTA-to-MTA.
I'm going to admit that I'm a bit confused by this thread. I'd like to start at the top to make sure I'm understanding correctly.
This statement sounds to me like "I'd like to be able to put the CA-provided random value in a SRV record, instead of in a TXT record, to fulfill domain control validation". But then:
This makes it sound like you want to complete domain control validation without updating any DNS records.
So I think what you're saying is: "I would like to complete HTTP-01 validation (or something like it) but have the CA connect to an IP:Port found in a SRV record instead of an IP found in an A/AAAA record". @_wojtek is that understanding of your question correct?
Assuming this interpretation is correct, the short answer is: no, you cannot do this. The Baseline Requirements specify that, in the course of connecting to the Authorization Domain Name, only two kinds of redirects can be followed: DNS CNAMEs, and HTTP 3XX. We cannot use SRV records to perform lookups.
Beyond that, I'm slightly confused as to why this request would be relevant at all. SRV records are useful for service discovery. You might perform a DNS query for an identifier like _xmpp._tcp.example.com, and the response would be something like IN SRV 5 0 5223 example.com. The original query _xmpp._tcp.example.com is not a "real" domain name, it is a combination of domain + protocol + service which is used as a lookup key, and the response tells you what domain name to actually perform A record lookups on to find the relevant IP address. There is no need to get a certificate for _xmpp._tcp.example.com, and indeed it is impossible to do so, since underscore is not a valid character in the Preferred Name Syntax. So there's no way for our validation process to encounter a SRV record at all: requesting issuance for _xmpp._tcp.example.com will fail immediately as that is not a valid domain name, and requesting issuance for example.com would not prompt us to look up any potential SRV records for any potential service+protocols that we suspect may be running on that hostname.
If you want to get TLS certificates for your XMPP server running on example.com:5223, then the easiest solution is to also run an HTTP server on example.com:80, use that to obtain certificates, and then share those certificates with the XMPP server.
To add to @aarongable's great suggestion, you could use a "standalone" functionality in your ACME client (e.g. certbot) to have your ACME client spin up a temporary webserver on port 80 specially for acquiring your certificate then use a "deployment hook" to your ACME client to install the certificate for your XMPP service. This would save you a lot of headache on maintaining a webserver for this purpose. It's also nice for security since this ephemeral and limited webserver will only exist while acquiring your certificate only for acquiring your certificate then vanish into thin air. Of course this only works if you don't already have something listening on port 80.
I think the concern is, and I also may not be following completely, the case where _xmpp._tcp.example.com has a SRV record for some-other-host.example.net, along with a client that when trying to connect to XMPP for example.com looks up the some-other-host.example.net server and connects to it, but expects it to present a certificate for example.com rather than a certificate for its own hostname.
I'm not clear on whether that's actually the "standard" behavior for the client, or if clients are supposed to be expecting a certificate for the pointed-to hostname instead (like the analogous way MX records work). But if that's the way clients work, that they need the name on the certificate to match the original name instead of the actual hostname, then one may need to get two certificates for example.com, one for any main services running on the A/AAAA record for it, and one for the some-other-host.example.net server. And it can a bit awkward with ACME to set up multiple clients on different systems to fulfill separate DNS-01 challenges (which I think is what the draft-ietf-acme-scoped-dns-challenges proposal is supposed to help with?). And it can be really awkward with HTTP-01, since the servers need to coordinate somehow and probably redirect one server to the other for at least some of the time, or distribute the certificate separately, or the like.
All solvable problems, and I don't think compelling enough to actually get an update to the BRs/RFCs/etc., but I can see how they're annoying. If I do in fact understand it correctly, which again I'm not sure I do.
More and more DNS providers (especially the business-oriented big "cloud" ones) allow for limited-scope credentials that can only be used to update a specific TXT record. And you can do a lot with an acme-dns type solution of a custom DNS server for the problem you're trying to solve. But those kinds of features may not be pervasive enough quite yet, no.
)