Error finalizing order :: policy forbids issuing

ZTNA · May 7, 2019, 4:28am

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

_az · May 7, 2019, 4:34am

I believe you can email security@letsencrypt.org with your request.

But make sure it is actually a forbidden domain rather than a mistake you have made with a CSR - they can end up with an identical error message.

ZTNA · May 7, 2019, 4:41am

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.

Warm Regards,
A grateful user

fefrei · May 7, 2019, 6:17am

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.

ZTNA · May 7, 2019, 6:36am

Thanks for the replies. Here is the CSR:

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.

Thanks.

Warm Regards,
A user that keeps on trying

_az · May 7, 2019, 6:45am

That is a bad CSR. You have your domain duplicated twice within the CSR:

DNS:CN=webapp.ztna.org, DNS:webapp.ztna.org

It's a bit hard to see from the output, but this is literally these two domain names:

CN=webapp.ztna.org
webapp.ztna.org

The first of which triggers this error on the Let's Encrypt side:

The request message was malformed :: Error creating new order :: Invalid character in DNS name

cpu · May 7, 2019, 12:44pm

Hi @ZTNA, welcome to the forum

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

ZTNA · May 7, 2019, 6:13pm

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

cpu · May 7, 2019, 6:24pm

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:

$> openssl req -in /tmp/csr.pem -noout -text
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: CN=internalba.ztna.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b2:25:42:9e:46:8a:e5:88:90:90:e7:8c:da:01:
                    c9:36:b9:be:8e:8a:aa:e5:46:5f:49:24:d1:a5:a2:
                    c3:0e:ec:b1:55:91:b3:e5:15:37:1a:2b:c7:2b:87:
                    d3:8e:db:2a:82:35:29:52:27:21:ae:ba:8a:f5:84:
                    84:07:00:1f:15:47:95:34:94:f8:f4:89:f0:90:61:
                    f5:06:8f:53:de:71:f4:bf:a9:49:5c:99:e7:87:25:
                    41:f8:3b:65:8e:bb:c5:df:f9:3c:b5:f5:df:20:67:
                    b1:23:fe:b2:af:2b:23:f8:4c:d2:d4:de:25:b3:9b:
                    86:e3:5f:1a:68:43:54:b8:64:c0:14:95:a9:df:79:
                    24:ab:89:b8:fb:62:4e:09:70:76:0e:ee:4b:37:fc:
                    be:15:36:ec:4d:f5:4e:8b:1b:ab:11:8e:17:03:79:
                    28:aa:a6:9e:0b:1d:67:3f:92:c0:e5:bf:3c:f2:c9:
                    e1:e1:f9:c0:ce:3b:42:95:57:9b:cd:1c:74:ef:e3:
                    b0:27:95:db:fb:19:d3:45:de:45:2d:ff:c3:86:8b:
                    fd:4d:f4:29:9c:84:cb:17:55:84:e2:91:80:2d:04:
                    60:29:e2:27:2a:94:61:7e:b4:9e:79:d6:b6:02:f3:
                    7e:af:32:5c:48:41:52:c5:db:29:f8:f1:4b:4d:d3:
                    24:0b
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:internalba.ztna.org
    Signature Algorithm: sha256WithRSAEncryption
         95:f5:05:b8:77:08:3c:17:cf:d3:b2:fd:27:10:5b:c2:88:0b:
         20:b7:ac:2d:16:cd:0f:c7:87:ce:d2:5b:10:48:03:e6:f3:bd:
         86:99:ac:4c:9a:cd:0e:71:c5:ca:18:6a:6b:b7:c2:35:6e:19:
         46:ce:e5:b8:bd:74:ad:5b:ed:54:72:0f:55:ce:7d:7b:96:46:
         43:3c:0a:2c:46:6b:d6:b9:23:4c:a8:ab:ef:76:12:8f:3e:f7:
         eb:e2:ca:4e:eb:21:c4:a8:c5:9c:aa:44:33:b0:ac:51:e8:ea:
         db:ae:4a:ce:e2:b7:19:bb:b6:23:ff:ed:24:1a:9d:fa:5b:9d:
         fc:13:da:36:96:1f:c6:a8:37:e7:7e:3a:05:64:17:fe:11:c2:
         c5:d9:92:24:7c:1c:93:ab:25:80:5a:5e:79:c3:33:70:42:6a:
         68:b4:46:0f:c4:f1:92:80:99:8b:88:ef:b5:e2:25:6c:cd:41:
         eb:04:14:96:1f:59:48:7f:0e:2c:b1:b7:2b:d5:3d:87:25:d2:
         9e:df:dd:af:b8:30:68:ec:d1:5b:bb:59:04:4a:91:bf:df:5e:
         b8:35:17:e6:37:aa:d7:c9:48:41:30:bb:4b:51:26:d6:51:61:
         ef:8f:2a:5c:3f:1e:4d:ea:ba:83:77:ea:76:df:40:c3:c4:fe:
         26:00:2d:69

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?

ZTNA · May 7, 2019, 7:49pm

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.

Warm Regards,
A very grateful user

system · June 6, 2019, 7:49pm

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