Hi, On Sun, Feb 01, 2026 at 12:26:16AM +0200, Mia Kanashi wrote: > Subject: RFC: implement acme dns-persist-01 > Working Draft: > https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist > > This will allow to issue certs without open ports or >
I also so this yesterday on https://letsencrypt.org/2026/02/18/dns-persist-01 This is really interesting as it would not require anymore to give access to the reverse proxy to the DNS zone, one could just put manually the token once for all. > I'm currently working on it in this tree: > https://github.com/kanashimia/haproxy/tree/acme-dns-persist-01 > > It is already basically implemented, > but I still want to wait some time before merging, Great! I'll take a look, but don't worry to much if some things are missing functional, the ACME feature is still experimental in haproxy. I'll take a look in more details. > as there isn't any good CA available yet really, had to roll my own. > Tested against this one too: https://github.com/rafaelgieschke/serles-acme > Letsencrypt stated that they will implement it this year. > >From the previous article it seems like this will be rollout in Q1 for staging and Q2 for production, so this is mostly ready for letsencrypt. Also Pebble seems to support the specification, I used Pebble and step-ca during development for testing, so this should be easy to test with. > Some script needs to be written to print DNS record ahead of time. We are already able to print the DNS record in the log to put in the DNS challenge when doing ACME in "manual" mode, so we could probably do something like that as well. > I used this one to get account uri: https://github.com/pawlakus/acmecli > > Posting this to ask for feedback and opinions before contributing, > it is my first contribution here. > This is definitely interesting, I still need to spend some time checking and testing your branch and I'll give you more feedback. > My branch assumes that DNS records are already created and propagated, > maybe that could be improved. Maybe haproxy should check propagation > for both DNS challenges in its code? I'm not sure how to do that myself. That's in my TODO list, and it's quite difficult because the DNS code was not made for that in HAProxy, but I absolutely agree with you, that's one of the caveat we currently have with the existing dns-01 mode. > Also, while implementing it I found that `domains "foo,*.foo"` > will ask for foo dns record two times, while with dns-persist-01 > wildcard record on foo already authorizes both, and so currently > it incorrectly prints log message two times with two records on my branch, > have any ideas with that? > I'll check that as well thanks, I remember emitting 2 logs for this and only needing to validate 1 challenge on the CLI. > CC me when replying (as per contributing instructions) > > On Tue, Feb 03, 2026 at 12:48:48AM +0200, Mia Kanashi wrote: > Subject: Re: RFC: implement acme dns-persist-01 > Some additions, sorry I'm bad with writing messages: > > > This will allow to issue certs without open ports or > > Sorry, was distracted and forgot that I didn't finish that, > I meant that it allows to have to have benefits of DNS-01 without relying > on having a separate code for each DNS provider in something like dpapi, > and without waiting for DNS propagation each time, which is important > as people shift towards certificate lifetimes as low as 7 days. > Absolutely agree. > > It is already basically implemented, > > Still pretty WIP though. > > > but I still want to wait some time before merging > > Letsencrypt stated that they will implement it this year. > > Waiting on support in Letsencrypt Pebble at least. > > > My branch assumes that DNS records are already propagated, > > Now am thinking that this probably doesn't matter much, my concern > was about CA ratelimiting during retries, if anyone has a problem > with that it could serve as an improvement later. I don't know about dns-persist-01, but that was a problem with dns-01 because the CA wouldn't allow a retry if the propagation was not done yet, and it requires to use a new DNS challenge which is really not efficient... We definitely need to check the propagation in this case, since there won't be any manual commands on the CLI. But DNS would honestly take some time to be ready for that. Or maybe we could differentiate the first generation from the renew, and ask for manual validation only during the first generation. > I found that iterating over arrays with mjson is kinda not efficient? > And also pretty clunky... I mean it doesn't matter here really, at all, > but with the removed mjson_next it is slightly better than using sprintf... > Though the API is still pretty baaaad, > I tried to use mjson_next as an experiment on my branch, > to see what it looks like, it is still clunky but at least makes more sense. > IDK if I would keep that though, what do you think? Well it's just changing iterating on 1 octet and you don't have to handle > 10 items so that's only inelegant more than inefficient. But I agree, the API is not great. I stripped down our mjson code since the latest CVE, but we could reintroduce mjson_next if needed. > BTW I want to mention yyjson: https://github.com/ibireme/yyjson > Just in case you didn't hear about it. I don't really suggest integrating > it, > at this point at least, it is larger and the code is extremely hard to read, > but if you plan to use json in more places in the future it may worth > looking into it, as it is about infinite times faster (tm) I have no idea if that's really faster :-) but we already talked about that in another thread, let's concentrate on ACME for now, the JSON feature could evolve later. > DNS-PERSIST-01 allows to set an expiration date on the record optionally, > so there is a possible point for integration with dpapi > Honestly I don't see a reason to use that, DNS-01 already exists, > but if there is a use case, integration with dpapi could be added later. > I wont implement that at this point because I don't know how and why > and I don't care. I will look into doing that later though if it isn't hard > to do. The dataplaneapi integration is also about saving the certificate on the disk for you, but it would work the same way so I don't think it needs patches. Regarding the dns-persist-01 itself, maybe there's not that much changes needed to make it work like dns-01 in dpapi, don't worry about that, that's not a requirement to make it work in haproxy! -- William Lallemand
