List of domains blocked with "Policy forbids issuing for name"

[tbehling]

Hello,

I understand from this forum post there are various “transient” domain names under which Let’s Encrypt will refuse to issue a certificate, which gives the error “Policy forbids issuing for name”. I am working on a project involving Let’s Encrypt and it would be a big win for our users if it were possible to either obtain a copy of this list or query an API to check a domain against it, before trying to request an authorization. Would either be possible?

Thank you!

Ted Behling

[cpu]

Hi @tbehling,

@tbehling

I understand from this forum post there are various “transient” domain names under which Let’s Encrypt will refuse to issue a certificate, which gives the error “Policy forbids issuing for name”.

There are very few of these "transient" domain names (like the EC2 case you mention). 99% of the entries are for large financial institutions and brands you would expect to find on the Alexa top 100 list.

@tbehling

I am working on a project involving Let’s Encrypt and it would be a big win for our users if it were possible to either obtain a copy of this list or query an API to check a domain against it, before trying to request an authorization.

Can you expand on your use-case? Why is it problematic to find out at the time of the new-authz request that the domain doesn't meet the issuance policy requirements?

The new-authz endpoint is an API that you can use to check the domain if you are cognizant of pending authorization limits (this only matters for cases where the domain is allowed and a pending authz is created. None will be created for a domain that the policy blocks).

We do not presently make the list of high-value domain names blocked by the issuance policy public. I don't expect this will change in the short term.

Thanks!

[tbehling]

Hi @cpu, wow, thanks so much for the quick reply.

The use case I have is perhaps relatively minor. What I’m considering is an optimization for my tool’s UI to give early, inline feedback about whether the hostname that’s configured would be rejected by Let’s Encrypt when the certificate is later actually requested. This prevents a slightly awkward experience of attempting to enable Let’s Encrypt and then later receiving a notice of the failed authorization call.

I completely understand not making the blacklist public. Based on your comments, maybe a valid approach could be to request an authz, check the response state, and then cancel it. But, I don’t see an ACME API call to cancel an authorization; did I miss something? If there’s not one then maybe I’d need to refactor my use of the API to split apart the authorization (performed synchronously) from the issuance (performed asynchronously).

[cpu]

Hi again @tbehling,

@tbehling

This prevents a slightly awkward experience of attempting to enable Let’s Encrypt and then later receiving a notice of the failed authorization call.

Aha. Yes, I understand that giving this feedback later in the process is somewhat awkward.

@tbehling

Based on your comments, maybe a valid approach could be to request an authz, check the response state, and then cancel it. But, I don’t see an ACME API call to cancel an authorization; did I miss something?

Are you using an existing ACME client (certbot, lego, etc) or have you written an integration from scratch?

You might not need to cancel the authorization at all. In the case where the domain isn't blocked you'll need the authorization that is returned in order to continue issuance for the domain. In the case where the domain is blocked, no authorization is created so you can just return the error to the user and not worry.

If you do decide you'd like to try and create an authorization ahead of time, look at the result, and cancel the created authorization in the case the domain wasn't blocked there is a way to do so. Check out the section of the rate limits page called "Clearing Pending Authorizations".