# False positive: test.api.app.uca.edu.ar blocked as recursive on-demand issuance

**URL:** <https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603>\
**Category:** Help\
**Created:** [July 2, 2026, 2:52pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603 "2026-07-02T14:52:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mariano\_dinetti](https://avatars.discourse-cdn.com/v4/letter/m/a88e57/32.png) [@mariano\_dinetti](https://community.letsencrypt.org/u/mariano_dinetti)\
**Post date:** [July 2, 2026, 2:52pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603/1 "2026-07-02T14:52:12Z")

</div>

Hello,

We operate the domain uca.edu.ar (Pontifical Catholic University of Argentina).

We are trying to issue a certificate for:  
test.api.app.uca.edu.ar  
using certbot.

The request is rejected with:  
Disallowed identifier requested ::  
Cannot issue for "test.api.app.uca.edu.ar":  
domain name contains too many subdomain labels indicative of recursive on-demand issuance

The hostname is a legitimate production/testing hostname and is not generated by any on-demand TLS mechanism.

Additional information:  
- DNS resolves correctly.  
- The domain is statically configured in Nginx.  
- We are not using Caddy On-Demand TLS.  
- We are not using autocert.  
- Certificate issuance fails even when requesting only this FQDN.

Command executed:  
certbot certonly --nginx -d test.api.app.uca.edu.ar

Could this domain be reviewed as a false positive?

Thank you.

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [July 2, 2026, 3:08pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603/2 "2026-07-02T15:08:31Z")

</div>

The [announcement](https://community.letsencrypt.org/t/blocking-some-on-demand-issuance-caused-by-internet-scanning/245553) says to post here if you run into false positives.

Though for the last person who did so, it didn't seem like Let's Encrypt was going to be able to make exceptions so easily.

> [@Certificates denied for subdomain with error: "domain name contains too many subdomain labels indicative of recursive on-demand issuance"](https://community.letsencrypt.org/t/certificates-denied-for-subdomain-with-error-domain-name-contains-too-many-subdomain-labels-indicative-of-recursive-on-demand-issuance/246162/2):
>
> I…

Just posting those links to give some context; I think we'd need to wait for someone from Let's Encrypt staff to post to get any sort of definitive answer.

As a workaround, if you need something more urgently, you might want to look into trying some other CAs if Let's Encrypt isn't going to be able to support you. There are several that are also free and support the same ACME protocol for automatic use. There are some comparison charts [from the author of Certify the Web](https://acmeclients.com/certificate-authorities/) and [from the author of Posh-ACME](https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/) about possibilites you might want to explore.

---

<div class="post-metadata">

**Author:** ![Phil](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/phil/32/76801_2.png) [@Phil](https://community.letsencrypt.org/u/Phil)\
**Post date:** [July 2, 2026, 3:48pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603/3 "2026-07-02T15:48:13Z")

</div>

Hi @mariano_dinetti,

First of all, sorry about that. Here's what happened:

1. Our `blockedOnDemandLabels` list includes `test`, `api`, and `app` amongst others
2. [wfe2/wfe.go states](https://github.com/letsencrypt/boulder/blob/cee9fc675ed3f98af2b3a90fa41ca5b4e58e799e/wfe2/wfe.go#L2836)

> // looksLikeRecursiveOnDemandRequest returns berrors.RejectedIdentifier if any  
> // identifier has:  
> // - at least four domain labels; and either  
> // - two identical blockedLabels in a row, or  
> // - any three blockedLabels in a row. \<===========

3. You attempted to issue for (1) `test` (2) `api` (3) `app` .uca.edu.ar

Unfortunately without some code changes on our side, you won't be able to issue for that specific subdomain. However, you _could_ try something like `devtest.api.app.uca.edu.ar`.

This system isn't perfect as evidenced by your valid use case, but it has shed unnecessary load from deficient ACME client implementations.

---

<div class="post-metadata">

**Author:** ![sebastiannielsen](https://avatars.discourse-cdn.com/v4/letter/s/e9bcb4/32.png) [@sebastiannielsen](https://community.letsencrypt.org/u/sebastiannielsen)\
**Post date:** [July 2, 2026, 8:27pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603/4 "2026-07-02T20:27:18Z")

</div>

> [@Phil](#):
>
> This system isn't perfect as evidenced by your valid use case, but it has shed unnecessary load from deficient ACME client implementations.

One solution could be to make a DNS request for a random label at the leftmost position. In this case, it would be `[RANDOM].test.api.app.uca.edu.ar`

like:  
`tjhsrs.test.api.app.uca.edu.ar`

If this request FAILS, then SKIP the on-demand test alltogether.

Why this would work:  
The recursive issuance is based among a DNS wildcard connected to a web server, which gives the endless labels.  
By testing for a DNS wildcard, by trying to look up a domain that WOULD EXIST if the DNS set up would be like \*.uca.edu.ar, then you defend against recursive on-demand TLS, while still allowing legit domains with many different "BlockedLabels" to exist.

By requiring `[RANDOM].test.api.app.uca.edu.ar` to fail, you effectively test for wildcard.

This would COMPLETELY block on-demand issuance - since if theres no DNS record for the extra label (like `git.api.test.example.com`) then the request would not reach the on-demand TLS server.

this would also resolve this:

> [@Certificates denied for subdomain with error: "domain name contains too many subdomain labels indicative of recursive on-demand issuance"](https://community.letsencrypt.org/t/certificates-denied-for-subdomain-with-error-domain-name-contains-too-many-subdomain-labels-indicative-of-recursive-on-demand-issuance/246162/2):
>
> I…

Without actually causing more spam domains.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [August 1, 2026, 8:27pm UTC](https://community.letsencrypt.org/t/false-positive-test-api-app-uca-edu-ar-blocked-as-recursive-on-demand-issuance/248603/5 "2026-08-01T20:27:57Z")

</div>

Closed on August 1, 2026, 8:27pm UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
