Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
Run it from OpenMediaVault (Debian-based NAS OS) which has an Let'sEncrypt "plugin". I pressed Generate certificate.
It produced this output:
My web server is (include version):
Debian 8 Jessie
The operating system my web server runs on is (include version):
OpenMediaVault 3.0.89 Erasmus
My hosting provider, if applicable, is:
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
As you can see I get this error:
The web1-web3 are webservers running NGinx, which right now only presents a simple html-file, maybe that is the problem?
The important one is the which is for Ombi, why is it failing? I did the same reverse proxy setup as everything else. Why does it give me an error?
I know I get this error, I had no idea there was a limit, and I kept trying to renew the cert because of the errors.
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains:
I would like to fix everything before running it again in 7 days.
Could you take a look at the log file in /var/log/letsencrypt that’s mentioned here? It’s running Certbot behind the scenes but not showing you all of the output. However, the log file should have more details, probably including an error message that explains more about why the challenge failed.
Thanks. The key part of that is that when the Let’s Encrypt CA tries to connect to your server to access a challenge test file, your server returns a 404 Not Found error. That in turn means that Certbot failed to place the test file in a place where it would be publicly accessible at the expected path. That in turn means that the OpenMediaVault Let’s Encrypt plugin did not specify the correct location to place challenge test files, which in turn could be because you changed something in your web server configuration or used an unusual or non-default configuration, or because the OpenMediaVault Let’s Encrypt plugin is buggy in some way.
I would suggest contacting the developers of the plugin and asking them for help figuring out what went wrong.
By the way, the line
Using the webroot path /srv/91a2af43-24c7-475f-b28b-3cb663d2aa7e/Media/OMV/Web/WWW for all unmatched domains.
in your output is a possible clue. It suggests that, for some domains, Certbot was not given (by the plugin) a specific path at which to save the test files, and therefore it used a default one (based on the path it was told for one of the earlier domains). This is probably wrong because normally each domain needs to serve files from a different directory on disk, and Certbot needs to be told what directory that should be for each domain, yet it was apparently not told that here.
It is possible to set the WebRoot yourself in the plugin, and it is explained: “The root directory of the files served by your internet facing webserver.”. So I set this to my main Nginx webserver (instead of the standard /var/www/openmediavault/, which I guess is for the OpenMediaVault web admin interface).
Do you have any other ideas? I will try to reach out to the developers of the plugin.
It will probably need to be set per-domain somehow, assuming that the webroots of the individual domain names are different. After doing this, you might get a different error in the log file (assuming that the process still doesn’t work).
Are you able to set the webroot per-domain, or only globally? I’m still concerned that your different sites should most likely have different webroots, in which case there is no way that specifying only one webroot can be correct for all of the sites.
Huh! So I think the plugin developer didn’t totally think this through, because the underlying Certbot program allows (though it doesn’t require) multiple webroots, which is normally appropriate when using multiple different domains. However, the plugin doesn’t seem to support this feature—with the single webroot field there.
Maybe the plugin developer didn’t know about that functionality and therefore didn’t include it in the plugin?
In Certbot, you can specify any number of -w options on the command line, and each -d option uses the most recent-w as the source of its webroot for that particular domain. When different domains host different content, this is required in order to make each domain pass the challenge!
When you use the HTTP-01 challenge with --webroot, it is a requirement that the certificate authority will always start by connecting to the challenge URL via HTTP, not HTTPS. However, the certificate authority is also willing to follow redirects, including to an HTTPS target, and will accept a challenge file that is found at the end of a series of one or more redirects.
The best test is to manually create a file test.txt in .well-known/acme-challenge under your specified webroot, and then see if you can see it in a browser at the corresponding location on the web site. If not, this will prevent the --webroot authentication from working.
@cpu, could you tell us what the underlying reason for this was? I think I remember a few other cases where you were able to get more detailed information from the server side.
The underlying error says that we read an EOF in response to the HTTP request. I can't remember seeing this one before but it sounds as though the challenge server is closing the connection abruptly/improperly.