We are developing an ACME server to help our customers purchase and manage commercial certificates from us. Such automation is becoming more important now that the maximum validity period has dropped to 200 days and will eventually drop to 47.
While we support free Let’s Encrypt certs in various ways, we currently sell commercial certs only through our website. We resell them from https://www.thesslstore.com/, which sources them from the DigiCert and Sectigo CAs. Our ACME server is intended to be a wrapper around the existing reseller API provided by The SSL Store for certificate provisioning, allowing customers to use standard clients like certbot and simple-acme to purchase and reissue certs from us via External Account Binding.
The issue I’m encountering is that when DNS validation is chosen, we get “challenges” that must be published via TXT records on the root domain name rather than the _acme-challenge sub-host. E.g. for a cert on example.com, the CA will require us to publish a TXT token on example.com, not _acme-challenge.example.com. Unfortunately, the ACME dns-01 challenge type seems to have no way for the server to tell the client not to prepend the conventional _acme-challenge label when publishing the TXT record. There is also no way for us to tell the client to publish a CNAME rather than TXT record, as required by Sectigo. This issue prevents us from completing the domain validation (DV) process via our reseller API, because the CA will not find the DNS record they’re expecting.
It’s true that in most cases, we will control the domain’s DNS, as we are the registrar of record and offer comprehensive DNS hosting; in that case, we could first validate the client’s conventional _acme-challenge record and then turn around and publish the CA’s requested record in the zone to complete validation on that side. But there will be cases where the customer uses a third-party DNS host, preventing us from publishing the needed record.
Do you know of any way around this issue, or any future RFC ACME extension proposal that might help? I’m aware of the http-01 challenge type, but The SSL Store reseller API doesn’t provide consistent support for HTTP validation across all cert products.
Thanks,
Jordan Rieger | Software Development Manager | Webnames.ca
You're, like building a proxy ACME server? I have to admit I'm not that familiar with the CA reseller ecosystem, but I would expect that you could use ACME with the CAs that you're reselling to have them use the ACME-related domain validation methods rather than trying to have you implement the manually-implemented validation methods.
Yes, but the problem is that the ACME implementations provided by the CAs aren't fully wired into our existing reseller, The SSL Store, so if we go direct to the CA, we would be bypassing the billing and management system that we currently use for thousands of active certs.
I think what you need to do is talk with that reseller store about what their plans are for increasing automation as lifetimes continue to decrease, and how they expect organizations like yours to have their customers automatically do validation.
I'm not aware of any way of using ACME to fulfill a non-ACME domain validation, or any planned extensions to do so. But I'm certainly not personally aware of everything. For an interesting historical note, one reseller once tried to use a remote code exploit in a specific ACME client to try to get this sort of thing to work, but I doubt that's the best approach…
I think the dns-persist-01 challenge type would work for you. At least for issuing CA that support it. So that's the critical path. Let's Encrypt plan to add it to their Staging system yet this month with production rollout next quarter. Perhaps you could help influence those other CA to support that?
The user, or possibly its ACME Client, creates a static TXT record that has an optional expiration date. The values needed in the TXT do not change across cert requests.
Your "middle" ACME Server wouldn't have anything to do. You could, optionally, validate that the target DNS system has some TXT record but you wouldn't know the exact record data to validate. And, this would just allow you to intercept faulty requests or provide better feedback.
There is a dns-account-01 challenge type that allows custom names for the TXT but LE has not announced whether they will support that. I am not fully versed in the details of that one.
I think the dns-persist-01 challenge type would work for you. At least for issuing CA that support it. So that's the critical path.
Interesting. I did come across this one, but unfortunately support is not widespread yet.
My impression is that the paid SSL/CA industry is not showing sufficient urgency in jumping on the automation bandwagon forced on it by the shorter validity periods.
I don't know if I'd completely agree with "forced on it", since reducing validity passed unanimously (though perhaps they figured if they opposed it then root stores wouldn't like them as much). I would have naively expected that paid CAs are precisely who could benefit the most by offering automation tools to their customers, helping walk their customers through configuring it and adding monitoring and such. Good support and tooling is like, the main thing one might find worth paying for. But it may be that the reseller-setup organizations like you're working with aren't yet as set up for that as one might hope. My intuitions about how business works are not always correct.
I don't know if I'd completely agree with "forced on it", since reducing validity passed unanimously (though perhaps they figured if they opposed it then root stores wouldn't like them as much).
I agree with the statement in this blog post: "The vote didn’t really matter. If it didn’t pass, Apple or Google or Mozilla was going to do it anyway."
IIRC current acme challenges specifically use different path from their non-acme counterpart:
/.well-known/acme-challenge for http-01 : /.well-known/pki-validation for ca/b 3.2.2.4.18