Policy forbids issuing for name on Amazon EC2 domain

Hi,
I’m trying to setting up SSL for my Amazon EC2 instance, I’m running all inside a Docker with debian stretch.
I have completed all the installation step that i found here http://letsencrypt.readthedocs.org/en/latest/contributing.html#hacking

Lauch:
./letsencrypt-auto certonly --debug --standalone -d ec2-xx-xx-xx-xxx.eu-central-1.compute.amazonaws.com

I got always:
2016-03-17 14:07:06,111:DEBUG:acme.client:Received response <Response [400]> (headers: {‘Content-Length’: ‘119’, ‘Expires’: ‘Thu, 17 Mar 2016 14:07:06 GMT’, ‘Server’: ‘nginx’, ‘Connection’: ‘close’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Thu, 17 Mar 2016 14:07:06 GMT’, ‘Content-Type’: ‘application/problem+json’, ‘Replay-Nonce’: ‘bq91H6NUkarUPrJzeJvm5ZlP44UsD0D3YDjLGOpzam4’}): ‘{“type”:“urn:acme:error:malformed”,“detail”:“Error creating new authz :: Policy forbids issuing for name”,“status”:400}’

I think that the installation is completed properly and the problem is in the domain name that Amazon assigned to me.
Letsencrypt accept Amazon ec2 domains ? How can i debug properly my error ?

Thanks for support
AleS

1 Like

amazonaws.com happens to be on the blacklist Let’s Encrypt uses for high-risk domain names (i.e. phishing targets, etc.).

There’s nothing you can do about this on your end, other than use your own domain name. If you’re looking for a free option, check out http://www.dot.tk/. CloudFlare provides free DNS servers.

(I believe EC2 instances are kind of ephemeral, so I’m not sure if you can rely on the hostname being the same forever - so this is probably a good idea for other reasons as well. Admittedly, I’m not too familiar with AWS.)

3 Likes

Thanks for the fast-reply.
I already have a sub-domain on no-ip because, as you say, amazon domains are not very reliable, but I’m waiting to see if it will be added to PSL List.

I’ll definitely try the dot.tk

Thank you
AleS

@pfg is correct. We specifically list the amazonaws domans because we know they are ephemeral. We might certify one as belonging to you today, and then it could belong to someone else tomorrow.

3 Likes

That’s understandable.

On the upside, you only need one domain for all your containers, existing and future ones; each container can have its own certificate with a separate IP and a subdomain of your fully-qualified domain name.

Why not use Route 53, you could automate that with the same tools you are already using on AWS.

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