Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Hook command "service nginx start" returned error code 1
Error output from service:
There may or may not be an additional problem with your nginx configuration; if the above change doesn’t fix the problem entirely, please post the output of service nginx start.
Yes, I saw that they have disabled this option. Problem is, that I don’t want to open port 80. I still want to use port 443 as before with TLS_SNI-01. Is there a work around?
Validation on port 443 is no longer allowed for new domains. If you don’t want to open port 80, the only workaround is to use DNS validation.
Alternatively you can open port 80 temporarily in your pre-hook and close it again in your post-hook. Or you can leave it open and only serve a redirect to port 443. This article explains why that might not be as bad as you think.
In theory, there are some DNS plugins for certbot, if you can figure out how to install them. Alternatively you can use certbot certonly --manual --preferred-challenges dns, optionally with --manual-auth-hook and --manual-cleanup-hook to perform the required steps non-interactively. Or you can try an alternative ACME client such as acme.sh which may support your DNS provider if Certbot does not.
Yes, that should be no problem. You're already using the --standalone plugin, so changing it from tls-sni-01 to http-01 should make no difference to this (as long as port 80 is open) - if it was working non-interactively before, it should still do so. Is that not happening for you? What prompt are you seeing?
Or are you asking about automated renewal? That should work too, as long as you're not explicitly telling the renewal command to use tls-sni-01 as well. You just need a cron job or systemd timer running certbot renew twice a day, which may already exist depending on how you installed certbot.
pi@pcf-cloud:~ $ sudo certbot certonly --dry-run --pre-hook "service nginx stop" --post-hook "service nginx start" --standalone -n --rsa-key-size 4096 --agree-tos -m praxis@***domain***.de -d cloud.***domain***.de --preferred-challenges http-01
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: service nginx stop
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cloud.***domain***.de
Waiting for verification...
Cleaning up challenges
Running post-hook command: service nginx start
Failed authorization procedure. cloud.***domain***.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://cloud.***domain***.de/.well-known/acme-challenge/w8W1lBOaoVtYIJETph***CLeqgsaTyTBHSIpwLqtM: Error getting validation data
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: cloud.***domain***.de
Type: connection
Detail: Fetching
http://cloud.***domain***.de/.well-known/acme-challenge/w8W1lBOaoVtYIJETphfqXfXCLeqgsaTyTBHSIpwLqtM:
Error getting validation data
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
pi@pcf-cloud:~ $
This is usually caused by a DNS configuration problem on the site. Since you haven’t shared the domain, we can’t run our own tests to try to explain this, but you could try to run a DNS checking tool or use https://unboundtest.com/.
The certificate authority is much stricter than a browser in terms of the things it looks at in the DNS results, so the ability to reach the site in a browser does not mean that its DNS settings are OK from Let’s Encrypt’s point of view for certificate issuance.
First I had no port 80 part in my nginx configuration. Just open port 80 in my router wasn’t enough.
But now I face some issues with my router. I am currently on the move to a new provider. I need to test it with the new router next week. The old one did some trouble in the past. Existing port forwardings will still be executed but new ones not. A bit strange. Internally I can call the config with port 80 and it works perfectly fine. This is why I think it is not related to the webserver config itself.
as promised, here my feedback. Sorry for my late response but I moved to new ISP and had no internet this time.
Well, I opened port 80 as decided and then I ran certbot certonly --quiet --pre-hook "service nginx stop" --post-hook "service nginx start" --standalone -n --rsa-key-size 4096 --agree-tos -m $EMAIL -d $DOMAIN --preferred-challenges http-01. This was working fine.
But I still not understand why this is more secure than keeping port 80 closed and use 443 instead. Anyhow, thank you so much for assistance.
It's not more secure in general, but unfortunately a problem was discovered related to the configurations of some large shared hosting providers where the way that port 443 was shared among their customers would allow one customer to get a certificate for another customer's site if the validation was done the way that we were doing it. So we didn't want to run the risk of having this start to happen routinely. People are researching a way to prevent this so that validation on port 443 may be possible again some day.
