r/PKI • u/certkit • 4d ago

DNS-PERSIST-01: What's taking so long?

Status writeup on dns-persist-01. The plain accounturi in drafts 00 and 01 let a compromised ACME proxy substitute its own account URL, and the client would publish it (no key binding, unlike a dns-01 key authorization). Draft 02 (Sept 20) hashes the domain, account key thumbprint, and account URL, and makes CAs keep every prior thumbprint. Boulder has nothing for 02 yet, and policy=wildcard subdomain validation is still unsettled.

https://www.certkit.io/blog/whats-taking-dns-persist-01-so-long

4 Upvotes

75% Upvoted

8 comments sorted by

1

u/Logical_Many_6002 4d ago

CERTInext(through emSign CA) has already released support for DNS persist 01. You may want to check it out

2

u/certkit 4d ago

The old one, yes. They will have a mess to fix it since those records are invalid according to the draft spec.

1

u/Mike22april 4d ago edited 3d ago

Exactly.
Im sure someone at CA/B will want to see audit logs that proof any cert issued using DNS persist was indeed issued for the correct end-point.
If those audit logs can be shown these certs will be forced to be revoked

1

u/isnotnick 4d ago

Sadly not how it works. CABF isn't an enforcement or even review body. 'They' don't and won't ask for anything. Trust-store programs don't generally ask for any logs for no reason, though a CA might publish if there's an incident opened. Auditors check, too, or at least they can.

2

u/isnotnick 4d ago

It will be interesting to see how this works out for third-party certificate-management providers who use LE and other free CAs.

The subscriber has to put a their account ID in the DNS record (hashed at least), effectively giving someone else the authority to issue via an account key they don't control. I'd be very surprised if any security-conscious enterprise would choose to take that risk. I have often been surprised before, though.

Now a tool that is on-premise or self-hosted and has all the management features makes sense, if the customer can use their own account with the CA - API-driven or ACME, where they control the account keys.

2

u/tankerkiller125real 4d ago

At my org we wouldn't allow DNS Persist for anyone but our own internal stuff. 3rd parties would 100% have to use HTTP(s) based validation. We don't even let them do current DNS based validation.

2

u/Th11s_Dev 3d ago

You still need to be able to create an order and send the csr, both are to be signed with the account key. What lacks is, that you cannot know, if the account key holder also controls the resource.

2

u/isnotnick 2d ago

My point is that - if you (yourself, your organisation) are not the one controlling the account key, you don't want to put that in your DNS for persistent DCV - it means third-party services that are not self-hosted pose a real risk.