AETERNAE AI RESEARCH LLC INDEPENDENT RESEARCH
ÆAETERNAERESEARCH
Sign inRequest access
← Malware catalog

Attributed metadata history

REPORTPUBLIC METADATA

Onboarding Your Customers with Let's Encrypt and ACME

If you work at a hosting provider or CDN, ACME’s DNS-01 validation method can make it a lot easier to onboard new customers who have an existing HTTPS website at another provider. Before your new customer points their domain name at your servers, you need to have a certificate already installed for them. Otherwise visitors to the customer’s site will see an outage for a few minutes while you issue and install a certificate. To fix this, you and your new customer should use the DNS-01 validation method to issue a certificate before the customer switches over DNS for their site. How the DNS Validation Method Works The DNS-01 validation method works like this: to prove that you control www.example.com, you create a TXT record at _acme-challenge.www.example.com with a “digest value” as specified by ACME (your ACME client should take care of creating this digest value for you). When the TXT record is ready, your ACME client informs the ACME server (for instance, Let’s Encrypt) that the domain is ready for validation. The ACME server looks up the TXT record, compares it to the expected digest value, and if the result is correct, considers your account authorized to issue for www.example.com. Your new customer can set up this TXT record (or a CNAME) without interfering with normal website operations. The Advantages of a CNAME There’s an additional trick that I recommend for hosting providers and CDNs: Instead of giving the digest value to your new customer and telling them to make a TXT record with it, tell your customer to configure a CNAME from _acme-challenge.www.example.com to a domain name that you control and that is unique to the domain being validated. For instance, you might use www.example.com.validationserver.example.net. Then, once your software has verified that this CNAME is set up (accounting for propagation delay and anycast), your ACME client should begin the validation process for www.example.com, provisioning a TXT record at www.example.com.validationserver.example.net. Because the ACME server’s TXT lookup follows CNAMEs (as do all DNS lookups), it will see the value you provisioned, and consider your account authorized. This approach is preferable to handing your customers a raw digest value for a few reasons. First, it gives your customers all the time they need to set up the CNAME. If you create a pending authorization up front and give your customer a digest value to deploy themselves, it has a fixed lifetime before it expires (for Let’s Encrypt this lifetime is 7 days). If your customer doesn’t complete the process in that time, you’ll have to create a new pending authorization and give your customer a new digest value. That’s annoying and time consuming for both you and your customer. The CNAME method means even if it takes your new customer a month to make the needed changes to their DNS, you can get things up and running as soon as they do. Another reason to prefer the CNAME method over having new customers directly provision their TXT records is to support the best practice of periodically rotating your ACME account key. Because the digest value used for DNS-01 validation is computed based on your current ACME account key, it will change whenever you rotate your account key. If you asked customers to provision their TXT record manually, that means notifying potential new customers that the value you asked them to put in DNS isn’t valid anymore, and they need to use a different one. That’s pretty inconvenient! If you use the CNAME method instead, there’s only one ACME-related value you’ll ever need to have your new customers put in DNS, and it won’t change as you change your account key. Cleaning Up Unused CNAMES One last note: This is a good way to onboard customers, but you also need to detect when customers offboard themselves. They may simply change their A records to point at a different CDN, without telling you that their plans have changed. You should monit

Reference details

Source category
research-report
First reported
Oct 09, 2019 00:00 UTC
Last reported
Oct 09, 2019 00:00 UTC
Catalog updated
Oct 14, 2026 00:12 UTC
Record ID
a8cd23320a17bacc6d0592ce384cc3a67691122fd36ca76d799c30784244a357

Published indicators

Network indicators are visibly defanged. This page does not make them clickable or send them to another service.

No validated file hashes or network indicators are stored for this record.

Source observations

intelligence_src_823f7b237762257237

Source-provided label
Publisher RSS metadata
Evidence class
mentioned in report
Confidence
Not reported
Observed
Oct 09, 2019 00:00 UTC
Retrieved
Oct 14, 2026 00:12 UTC

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.

Feed collection status

Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.

1 sources: 0 stale, 0 needing attention, 0 paused, 0 unverified.

Review source update dates and status
  • intelligence_src_823f7b237762257237Recent successful batchLast successful batch: Last attempt:

Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.