Error finalizing order :: policy forbids issuing

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

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

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.

1 Like

Thanks for the replies. Here is the CSR:

-----BEGIN CERTIFICATE REQUEST-----
MIICoDCCAYgCAQAwGjEYMBYGA1UEAxMPd2ViYXBwLnp0bmEub3JnMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA79mqgIY4z9n+JVXPTDk10SlyTmbOEnrP
tGeSjxXM4V4ewSHqOpHin1o5I01dFS8qR1bg8G6w6oRDqJoBFOGyB4T3NtN31KLz
zt7ZI/ckhIjPHCRFb4zuWrPeP/NwIt0f8UTVKoruzoOQUsMkem7UTCXjhFH7pbZJ
sikt4hgVJr5Vo60mAmk0XkJMmT0M+HWIv6FEX5VKnPWXHeABrteZ3hCGffvXv1vY
2DhK0dwALGkKXctFS4L3x3WD7j+qY72PN/t7wt5LfAL55HZU+I5pPuf9RroOxpLt
dVzDm8rkfN5k+0ZXmfyn2RSQ+4EO71WlXSjnYwzXyUxkOgFdqK2MRwIDAQABoEEw
PwYJKoZIhvcNAQkOMTIwMDAuBgNVHREEJzAlghJDTj13ZWJhcHAuenRuYS5vcmeC
D3dlYmFwcC56dG5hLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA28c9OfaD9LFLUb68
FThBREmmbjatte1F6rzu720cr3QM/8z7LCiLKf17WvcldxRH2+fKTfUx3bexxmJi
nQXej9MO4puW49hRNpsdtTpU1+i0xsW6NZkogfVGnfW04QzwijTSOmaGJqVTZh90
T0kRJvnPXz0g+TnxE0bk+PZPY3ddGziso3MnB3IqJswjwZFZHLszlAfYrFmNgKuC
5hFmr/9A+61gJsQhQQIm/IcugSdbFq7iDz1WdLcq0+sane4Wq7WW8TilkYQfCfq6
FZc/QM9w75dHQeg99MAlULp9Gjj+saSuB99Fw+fJTx+ggAdp9irC2ygFCahfX68v
3Vh8eQ==
-----END CERTIFICATE REQUEST-----

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

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:

  1. CN=webapp.ztna.org
  2. 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

2 Likes

Hi @ZTNA, welcome to the forum :wave:

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

1 Like

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

-----BEGIN CERTIFICATE-----
MIIFXTCCBEWgAwIBAgISA9Ca/uy/a/iQVFubR/3Ao8qAMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA1MDUwNTIxNTBaFw0x
OTA4MDMwNTIxNTBaMB4xHDAaBgNVBAMTE2ludGVybmFsYmEuenRuYS5vcmcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyJUKeRorliJCQ54zaAck2ub6O
iqrlRl9JJNGlosMO7LFVkbPlFTcaK8crh9OO2yqCNSlSJyGuuor1hIQHAB8VR5U0
lPj0ifCQYfUGj1PecfS/qUlcmeeHJUH4O2WOu8Xf+Ty19d8gZ7Ej/rKvKyP4TNLU
3iWzm4bjXxpoQ1S4ZMAUlanfeSSribj7Yk4JcHYO7ks3/L4VNuxN9U6LG6sRjhcD
eSiqpp4LHWc/ksDlvzzyyeHh+cDOO0KVV5vNHHTv47Anldv7GdNF3kUt/8OGi/1N
9CmchMsXVYTikYAtBGAp4icqlGF+tJ551rYC836vMlxIQVLF2yn48UtN0yQLAgMB
AAGjggJnMIICYzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFC+KRVRPl18fu2+IX/E5
mexJ3HWWMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUF
BwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wHgYDVR0RBBcwFYITaW50ZXJuYWxiYS56dG5hLm9yZzBMBgNVHSAE
RTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRw
Oi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkCBAIEgfQEgfEA7wB1
AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAABaoan4ogAAAQDAEYw
RAIgTGIQ/E+0PAmm+a9+AXBArn5z2dmtisFK9p6H803XGnMCIEx+HtGvQIYiuHAN
aw+tnsmVkVyQYfVYNIvqQtJXt+g3AHYAKTxRllTIOWW6qlD8WAfUt2+/WHopctyk
wwz05UVH9HgAAAFqhqfirgAABAMARzBFAiA25rWEP3zfoxOAt2IYOwJRTj0EYFcN
nhBX5+M1iw1srgIhAIQRZn1tt+S1vOM2tGuPxSMMK6E0DXM2TAVoHJyh9ceXMA0G
CSqGSIb3DQEBCwUAA4IBAQAHvu8N/7OJdBqkDOlHGcph7vXSw2JNK6CKlUBcsMZe
6YGYosaFT7TatblluUrJ/ktQgxnkGF18YKhpKs9JkmbTBgIKEJ7lKtnHT6tHzCIz
x7LXThEQi84PCbwVrBqWejr0u5N7VGv5zksLTPREEQ1PdK4nXEtvlqAce9VJ2qsE
zwkNwLcpOKG3A4f/OKeYLT4ZNItXwrYCBVlnOH1zGzYxD0QChP9xIQCIovG+XD+z
N4fvt/lZcaZE2J9Y0C0Z+bf2YU0vhnyc6TZLnp6tnjgNWSe8ldXEJVC9ZbuuS/Xp
uhQJjZmx76r744IiECmNt5G1RqDHICw/h0IJbV923zlb
-----END CERTIFICATE-----

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:

-----BEGIN CERTIFICATE REQUEST-----
MIIClDCCAXwCAQAwHjEcMBoGA1UEAxMTaW50ZXJuYWxiYS56dG5hLm9yZzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALIlQp5GiuWIkJDnjNoByTa5vo6K
quVGX0kk0aWiww7ssVWRs+UVNxorxyuH047bKoI1KVInIa66ivWEhAcAHxVHlTSU
+PSJ8JBh9QaPU95x9L+pSVyZ54clQfg7ZY67xd/5PLX13yBnsSP+sq8rI/hM0tTe
JbObhuNfGmhDVLhkwBSVqd95JKuJuPtiTglwdg7uSzf8vhU27E31TosbqxGOFwN5
KKqmngsdZz+SwOW/PPLJ4eH5wM47QpVXm80cdO/jsCeV2/sZ00XeRS3/w4aL/U30
KZyEyxdVhOKRgC0EYCniJyqUYX60nnnWtgLzfq8yXEhBUsXbKfjxS03TJAsCAwEA
AaAxMC8GCSqGSIb3DQEJDjEiMCAwHgYDVR0RBBcwFYITaW50ZXJuYWxiYS56dG5h
Lm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAlfUFuHcIPBfP07L9JxBbwogLILesLRbN
D8eHztJbEEgD5vO9hpmsTJrNDnHFyhhqa7fCNW4ZRs7luL10rVvtVHIPVc59e5ZG
QzwKLEZr1rkjTKir73YSjz736+LKTushxKjFnKpEM7CsUejq265KzuK3Gbu2I//t
JBqd+lud/BPaNpYfxqg35346BWQX/hHCxdmSJHwck6slgFpeecMzcEJqaLRGD8Tx
koCZi4jvteIlbM1B6wQUlh9ZSH8OLLG3K9U9hyXSnt/dr7gwaOzRW7tZBEqRv99e
uDUX5jeq18lIQTC7S1Em1lFh748qXD8eTeq6g3fqdt9Aw8T+JgAtaQ==
-----END CERTIFICATE REQUEST-----

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?

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

4 Likes

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