I am trying to request a certificate for one of the domains (db.de) owned by the organization I am working for.
The subdomain I use in the request is: “itfabrik.noncd-test.db.de”.
I am utilizing the letsencrypt client in manual mode on Ubuntu 16.04.1 LTS calling “letsencrypt certonly --manual”.
In the logfile appears the following Error message: Error: urn:acme:error:rejectedIdentifier :: Policy forbids issuing for name
I would like to kindly ask if it is possible to change the policy so that I am allowed to request certificates for db.de-Domains?
I’ve opened a pull request to unblock issuance of db.de. Unfortunately your request comes at an unlucky time and we’re in a code/config freeze for the holiday period. I’m afraid it may take into early 2017 to make this exemption. Thank you for your patience! I’ll update this thread when I know more.
The baseline requirements that we have to meet as a CA wishing to be included in various browser root programs mandates that we maintain a list of "high value domains" that we won't issue for without explicit action. To be extra cautious we also look for permutations of some high value domains and in this case db.de is a TLD permutation of db.com, the Deutsche Bank
Since 6 weeks I’m struggling to request Let’s Encrypt certificates for our domain pnc.at.
I also get the “policy forbids issuing” - message.
I think, it will be the same reason - the domain pnc.com (belongs to some bigger bank as far as I know) will be seen as permutation.
Is there any communication channel to request unblocking?
Is there any way to check, if a domain is blocked? - This helps saving many hours of testing and debugging.
Posting on the community forum is usually enough - if there's no risk involved in removing the entry, the boulder team will typically amend the list within a week or two. No guarantees, though.
The list itself is not public; this was discussed a while back. However, if you get the "policy forbids issuing" error, that's definitely a blacklisted domain, so one way to know is to attempt to validate ownership for your domain. Perhaps it would make sense to create a documentation page for this and reference it in the error message.
Yes. Alternatively, consider Jamie Zawinski's passive aggressive error message design. Each time somebody didn't read the message and sent Jamie an email asking for advice that was already right there in the message, Jamie made the message a paragraph longer. Once your software spits out a novella, humans can't help but be intrigued as to whether it might have some clue as to their problem and they often read it...
I went ahead and cut a pull request to fix this for you. I expect it will be deployed to production in the next week or so along-side the other adjustments for @mc81 and others. I'll update this thread when I know it has been deployed.
What do you folks think the confusing part is here? I’m open to suggestions but I thought the “Policy forbids issuing for name” error was fairly self-explanatory.
I think the best way to improve clarity here is to publish the list but we have some work to do before this can happen.
You're experiencing nerd view I think. You know that Boulder has these policies, in fact that Public CAs in general have such policies, and so the message "Policy forbids issuing for name" makes you immediately think "Oh, I bet the FQDN I wanted a certificate for is subject to some sort of Policy specific to that name". But for the average Certbot user, all of this is unfamiliar territory. Also, the policy involved is likely to be opaque to them, if you work for (a hypothetical sports facility named) Robert Butler Swimming in Hong Kong, there's no reason for you to imagine that RBS means anything special and might be affected by special name policy, but of course the Royal Bank of Scotland has other ideas... So, it can be helpful to spell out exactly what happened, the below isn't intended to be copy-pasted, in particular I'd solicit feedback from users who ran into this (e.g. in this thread) but it's the sort of thing I'd expect to see in a more verbose message from end-user software.
Sorry, something about the specific DNS name you've asked for: exact.name.here.example means we weren't able to issue you with a certificate. This might be because it's very similar to the name of an important organisation, or it has something else unusual about it. Try asking us on our community site community.letsencrypt.org, please explain that you encountered the error "Policy forbids issuing" and give the exact name which experienced the error to find out more about the policy which affected you and whether we can grant an exemption so that you can use Let's Encrypt for this name.
I agree to you, @tialaramex and I like your suggestion. It also took me some time to figure out, what to do next and I was not sure if I made a mistake. After some searching I found this forum category and got some very helpful information from @cpu.
From my point of view it would have been helpful to get a hint how to deal with this issue (this is most important) and if possible some background information.
Policy forbids issuing for your.requested.dns.domain.example
The baseline requirements that we have to meet as a CA wishing to be included in various browser root programs mandates that we maintain a list of "high value domains" that we won't issue for without explicit action.
To get help have a look at the forums and create a new topic in the "Issuance Policy" category: Issuance Policy - Let's Encrypt Community Support
I do not know if there are other reasons which may result in the "Policy forbids issuing for name" error.
Probably the previous Error message might be a bit long for the logfile - so a better way could be to append a link to the message like:
So my suggestion would be to add a link to a documentation website with the benefit of easier maintenance (changes can be made to the website without releasing and deploying new software) and keeping messages in logfiles clear.
The entire .mil TLD is off-limits due to an agreement between Let's Encrypt and IdenTrust who provide cross-signing. Since this TLD is used only by the US military ordinary users shouldn't notice
Let's Encrypt obeys US laws which prohibit providing any service to some foreign governments or other entities. If the US government is prejudiced against your government then even if you work for, say, the department of education or sanitation or something, you may be unable to obtain certificates for names obviously related to the government
Also I am not sure if CAA rejection would give a "Policy forbids" error, probably @cpu or someone can say. CAA control lies with the domain owner, it's a means by which they can express a preference (not all CAs will obey this, for now) for particular Certificate Authorities to issue or not issue certificates for names in that domain, through adding DNS records.
What might be useful/nice would be to set up a few pages explaining common rejection reasons and modifying the error messages slightly from something like “Policy forbids issuing for name” to “Policy forbids issuing for name. See: https://letsencrypt.org/errors/forbids-name” or something. You don’t need to provide a paragraph in the error message, and directing to a whole page allows easy updating of the responses without tying to a Boulder deployment cycle.
Thank you for your effort.
I’ll try to get the certificate for pnc.at after you updated this thread here.
At the moment the certificate issuance is still blocked by policy.
This is off-topic - see our most-recent transparency report regarding legal requests. If you have further questions please open a new thread in the issuance policy category. Thanks
@RiP63 it was the Staging environment that was updated yesterday. I believe we should have production ready by end of day. I have a few threads to bump when this happens and I'll make sure this is one of them.
