Installing Cert in AWS EC2 Centos 6 - installed but, can't generate cert

I appeared to have installed LE successfully but, when trying to generate a cert I only get errors. In the shell I get:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
An unexpected error occurred:
There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently.
Please see the logfiles in /var/log/letsencrypt for more details.
[ec2-user@ip-10-0-2-39 letsencrypt]$

and in my log I see:
Error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently.

However, when checking my /etc/letsencrypt I don’t see any actual certs (only see in my /renewals a meta, priv_key and regr json files).

I’m on Amazon EC2 Centos 6 and my Python is 2.7.12 in ec2-user/.pyenv/versions/2.7.12 [but don’t see a letsencrypt dir in site-packages there if that matters].

Any help getting a cert would be appreciated!

Hi @enjoypb,

What you’re seeing right now is a rate limit associated with trying repeatedly but unsuccessfully to get a cert. The certificate authority is essentially telling you to stop because whatever you’re trying isn’t working (and it fears that you may even have an automated script trying it without any human intervention).

If you wait 1 hour, you will be permitted to try again. At that point, you will get a different error message that explains specifically what’s going wrong, and you can post a new topic here with the particulars of that error (which should be something that we can then help you to resolve).

Thanks Schoen. I’m not sure if it’s ok to post to this thread but, this is the error I was receiving earlier:

FailedChallenges: Failed authorization procedure. mydomain.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to my.ip.address.here:443 for tls-sni-01 challenge

I had opened up my Security Groups to include all ports, and one specifically for 443 but, no go. Can you tell if this is a port related error?

Thanks again.

This could be caused by a firewall forbidding connections to port 443, or by Certbot’s inability to reconfigure your web server to listen on port 443. The former is slightly more likely, but both are possible.

You could try running echo "It worked" | nc -l 443 on your web server (as root) and then nc mydomain.net 443 from another Unix machine elsewhere on the Internet (not the same AWS instance). If you see “It worked”, then you don’t have a firewall problem; otherwise, you do.

I keep getting a permission denied trying to run netcat.

Could this be related to (not sure how to articulate) the fact I am using (redirecting 443?) to port 8443 with my geoserver?

Maybe you’re not running it as root?

Possibly—I’m afraid I don’t know what a geoserver is!

Certbot is expecting to be able to make Apache listen on port 443 and then have it receive inbound connections from the Internet on port 443 using your public IP address. Does your redirect mean that that wouldn’t be able to work?

I tried with sudo as well but, no go. I ran this: netstat -ntl and see that 8443 is open but, no mention of 443.

Is this something where I can temporairly open 443, create the cert, then change back to the 8443 routing? Geoserver is actually running on Tomcat which is the port I’m using to the best of my knowledge. (Lot of Greek in all of this to me).

What error message did you see when you tried to run it?

If inbound connections from the Internet to port 443 are being forwarded to port 8443 on your server, then that would prevent Certbot from completing the proof of domain control, because Certbot would try to reconfigure something listening on port 443 on your machine, yet the outside world can never see or talk to that service. In that case (if I’ve understood how the port forwarding is working, which I’m not quite positive I have), getting rid of that port mapping temporarily would let the process complete. Still, this doesn’t seem like an ideal long-term solution because Let’s Encrypt certificates expire in 90 days, and you’ll have to repeat the process regularly.

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