# Blocking Some On-Demand Issuance Caused by Internet Scanning **URL:** \ **Category:** API Announcements\ **Created:** [February 25, 2026, 9:55pm UTC](https://community.letsencrypt.org/t/blocking-some-on-demand-issuance-caused-by-internet-scanning/245553 "2026-02-25T21:55:53Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![mcpherrinm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mcpherrinm/32/59604_2.png) [@mcpherrinm](https://community.letsencrypt.org/u/mcpherrinm)\ **Post date:** [February 25, 2026, 9:55pm UTC](https://community.letsencrypt.org/t/blocking-some-on-demand-issuance-caused-by-internet-scanning/245553/1 "2026-02-25T21:55:53Z")
We've noticed a surge in certificate requests for very long domain names (e.g., 10 DNS labels) that we believe are the result of unintended feedback loops between [Caddy](https://caddyserver.com/) or [autocert](https://pkg.go.dev/golang.org/x/crypto/acme/autocert) and Internet scanning tools. We'll be blocking some certificate requests, and may additionally pause accounts that show a large volume of this kind of issuance. Most Let's Encrypt subscribers will be unaffected, but read more if you use golang.org/x/crypto/acme/autocert or Caddy with [On-Demand TLS](https://caddyserver.com/docs/automatic-https#using-on-demand-tls). The affected web servers automatically request certificates when a client initiates a TLS handshake containing a hostname for which the server doesn't have a certificate. This is problematic because any third party can cause the web server to request a certificate, sometimes without even intending to do so. And often for a hostname that will never be used again. This in turn wastes Let's Encrypt resources that could otherwise be spent issuing certificates for hostnames that will see active use. For instance, this behavior can easily be triggered by researchers scanning the Internet. One behavior we've seen in particular: some affected servers will request [hostnames of the form](https://crt.sh/?q=update.update) `update.update.update.update.update.update.update.update.example.com`, or `git.git.git.git.git.example.com`. We suspect this is triggered by researchers scanning CT logs, extracting hostnames, and making requests to those hostnames with "interesting" subdomains like `update` or `git` prepended. Those requests trigger issuance, which puts new hostnames in CT logs, which get the same treatment, resulting in hostnames like the above. Caddy has some built-in defense against this behavior: [users must enable restrictions for On-Demand TLS](https://caddy.community/t/serving-tens-of-thousands-of-domains-over-https-with-caddy/11179). For instance, one type of restriction is configuring an `ask` endpoint that answers the question of whether Caddy should request issuance. However, based on our observed client behavior, we suspect there are a number of hosts with an `ask` endpoint configured to simply return 200 for all hostnames. Our recommendation to Caddy users is to disable On-Demand TLS, or to make sure the `ask` endpoint only answers 200 for a specific set of pre-approved subdomains (and not deeply nested subdomains). Our recommendation to autocert users is to use a [HostPolicy](https://pkg.go.dev/golang.org/x/crypto/acme/autocert#HostPolicy) that allows issuance for a specific set of pre-approved subdomains (and not deeply nested subdomains). For instance, the policy provided by [HostWhitelist](https://pkg.go.dev/golang.org/x/crypto/acme/autocert#HostWhitelist) will achieve this. If you need certificates that work for many subdomains at once, [wildcard certificates](https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-wildcard-certificates) are a great option: they'll cover all subdomains one level deep from a base domain. Using a wildcard certificate will provide more reliability and faster service for your website, since your visitors won't need to wait on new certificate issuance each time they visit a new subdomain. Over the next few weeks we'll be deploying heuristics to block requests that seem to indicate unrestricted On-Demand TLS; for instance, requests that contain identical sequential domain labels from a specific list. If you run into requests that are blocked but shouldn't be, please post in the [Let's Encrypt Community Forum](https://community.letsencrypt.org/).