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

Help
1

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.

2

The announcement 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.

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 and from the author of Posh-ACME about possibilites you might want to explore.

3

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

    // 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.

4

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:

Without actually causing more spam domains.