I ran this command: certbot certonly --standalone --preferred-challenges tls-sni -d brain.baxtersnet.com
It produced this output:There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently
My operating system is (include version): Ubuntu 16.04
My web server is (include version): n/a
My hosting provider, if applicable, is: me
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
I just want to generate a certificate to use with my QNAP device. I can import a certificate however I need to generate it first. I’m using UBuntu in a container to run certbot. Plan was to create certificates into a share which can then be loaded into the QNAP. QNAPs support for you does not extend to using my own domain only theres and there seems to be no other way.
This is my first time messing with certificates, not the first in front of a computer though. I have several devices that I want to Encrypt and my plan was to do this from the one container rather than on each server, especially as these are all applications running in various places.
The particular error message that you saw means that you tried unsuccessfully to get certificates too many times and have therefore been blocked. This will only last for an hour, and then you’ll be able to try again.
The previous attempts before you got blocked should have had a different error message, which should refer to the underlying problem. Do you remember what the error message was originally? It might also have been logged in a file in /var/log/letsencrypt.
One thing to check is whether the domain name brain.baxtersnet.com is actually pointed directly at your Ubuntu container, or at least that port 443 of brain.baxtersnet.com is pointed to it. That’s a prerequisite for the command that you used.
So brain is one of the servers I want to create a certificate for. It is the actual QNAP box. The container I am running the command on is on the same QNAP however it has its own IP address. Can I generate a cert without it trying to connect to something?
If not does it need to reach “brain” or the container through which I’m running the command?
If you can update DNS records for your DNS zone, you don’t need to accept an inbound connection. Currently acme.sh is probably the most capable tool for this purpose.
(Certbot can also do this, but doesn’t have as much functionality as acme.sh for the DNS authentication method.)
If not, you do need to receive an inbound connection. The inbound connection needs to come to the IP address referred to by the domain name you want the certificate for, but it needs to connect to the system or container where the client (like Certbot) is running. There are some more elaborate workarounds possible if this doesn’t work in your setup, such as generating HTTP 301 redirects, but the simplest case is that you have an inbound connection to the address pointed to by the domain name, and that connection is received by the command that you’re running.
Okay, then I guess I run NGINX up on the container and point at the
container. Can I generate different certificates for different devices
even when those devices have different IP’s to the one I will generate the
certificate on?
I have nginx currently working as a proxy to route various domain names to
appropriate servers. I want each of those servers to move to SSL.
What you can do in this case is make each server generate an HTTP 301 redirect from /.well-known/acme-challenge/ to the same location on the machine that's running the ACME client. Then if you use the HTTP-01 challenge type (e.g., Certbot's --webroot), the ACME client can pass challenges that are issued for the other domain names.
We've had some discussions about this on the forum before. Some of the results for