With 47day certs on the horizon, please add support for ACME challenge type DNS-PERSIST-01. This will greatly enhance automation in lot of environments.
Let’s Encrypt is scheduled to add support for it in Q2 of 2026. More on Let’s Encrypt support. DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt
The CA/Browser Forum ballot [SC-088v3] passed support for it in October 2025 (Ballot SC-088v3: DNS TXT Record with Persistent Value DCV Method | CA/Browser Forum)
Hi, thanks for your interest. This draft feature is already implemented and working in our development branch and will be available when the first ACME CAs start to support the feature.
Is there a way I can test the development branch with say pebble internally before it becomes live?
We don’t currently have test release to try, you could clone https://github.com/webprofusion/certify and try the windows service + desktop app, but it’s probably easiest just to wait a week or two for the next update.
In the app you can add any ACME CA under Settings > Certificate Authorities, then add an ACME account against that CA, then select that specific CA under Certificate > Advanced > Certificate Authority
Okay forgive me if this sounds dumb. But with DNS-PERSIST-01, to quote LetsEncrypt “The tradeoff is that, because the authorization record persists over time, protecting the ACME account key becomes the central concern.”. So I assume I’m supposed to protect my ACME account, which is really a nice way (I think) of my CertifyTheWeb account, but if I would even say they have accounts it is just email with no password or anything else (including verification) which means anybody can use my email and bam I’m done… So how is this going to work in reality?
Reading more, it sounds like I just need to be very protective of the keypair on the (in my case) VM that long term would host the certify management hub. I also suspect it would need to be the only machine recieving a certificate (directly obviously). Which makes the ability for it to hand the certificate off to other machines even more critical.
BTW since it uses API I presume it doesn’t matter much if I have multiple active directory forests/domains (2 forests, 3 domains). The forests have no trust etc… Though of course I do fear how well running PS scripts would work.
@nsumner How is very different from protecting the private key of your certificate on your server. Ideally one would use a different key pair per server which needs the cert, so a separate cert per server. The advantage I see is all these servers do not need access to write to the DNS for domain control validation.
@nsumner the account key in question is the ACME accounts you configure under Settings > Certificate Authorities. So not your certifytheweb.com account but the ACME CA account configured in the app(s).
So yes, centralizing your renewals means you have less ACME accounts, although it is possible for multiple instances to use the same account.
Our hub Certificate Subscriptions feature will solve the problem of account proliferation because instances won’t need an ACME account, or any DNS credentials etc. They will just get the latest cert from the hub and deploy it as they currently would when renewing a cert themselves.
The one difference is that in theory if the key is stored in Windows Certificate provider than it can be blocked from export. Yes there are normally ways around that (though more and more servers now have a TPM which would make that harder). IE there are built in Controls to in theory make that impossible. Sure it can still be done but it gets more and more difficult. A random file is much harder to protect in practice. Very few servers have bitlocker (for various good reasons), VMWare has yet to do a very good job of TPM as well. So while in general the SAN has encryption so you can check the box that data is encrypted at rest it isn’t nearly as good as every server having bitlocker. If I can get to the HD I can get to that key…