Hello experts,
I am having trouble getting certificates issued to my newly registered domain. I attempted to register a subdomain with a blacklisted word before I knew there was a policy against high-value domains.
Since then, I have been unable to issue any certificates even with innocent subdomain names. My preference is not to post the domain publicly so if someone could message me to assist with clearing this up, it would be greatly appreciated. Thanks in advance.
Warm Regards,
A newly educated user regarding blacklisted domain words
I am fairly certain I have been blacklisted because I was able to get a certificate for a non-high-value keyword URL on my domain. I followed exactly the same process for subsequent requests and they all fail with the policy forbidden message. This started right after I unknowingly requested a certificate containing a keyword in a high value domain. Thank you for the tip, I will send them an e-mail.
Requesting a high-value domain won’t cause any blacklisting, so this is very likely a problem with your CSR. If you don’t want to post more details (which you can do – issued certificates are public anyway), you should very closely inspect the domains you are trying to get certificates for.
The hostname I am requesting the SSL Certificate for is: webapp.ztna.org
I have used the same CSR tool/method to create a half-dozen certificates previously and only started having problems after accidentally requesting the high-value domain certificate.
It looks like @_az has already spotted the problem with your CSR (Thanks!).
I just wanted to comment quickly to confirm @fefrei's comment: It isn't possible to get blocked by Let's Encrypt for trying to issue for high-value domain names. The only thing to be aware of in this case is the failed validation rate limit. If you trip that rate limit future requests will fail with a rate limiting error (but only for one hour).
How about this certificate that was successfully issued using the same method?
I’m just confused as to why it worked in the past and is not currently working using the same method. Thanks
Something must have changed in the way the tool makes CSRs, or in the way you used the tool. I checked the server-side Let's Encrypt logs to find the CSR that was used to issue the certificate you shared above. Here's the PEM encoding of the CSR that was sent on 05/05/2019 to issue the certificate:
You can see using openssl that unlike the first CSR you shared that @_az noticed had a malformed "CN=" prefix on one of the SAN domain names the CSR above doesn't and that's why it worked:
Can you share what tool/method you're using and maybe we can spot what the difference was between your earlier uses that made a valid CSR and your current usage that is generating an invalid CSR?
I identified the error in the tool used to generate the CSR (private cloud-based application). It was taking the CN= from the DN field and applying it to the SAN field, which appears to have correctly been rejected during the signing process. Once I modified the CSR so the SAN field does not take the CN=, it appears to work fine.
Thank you to everyone who contributed here; I have submitted a request to enhance the CSR tool’s creation process to prevent issues like this.
