Error creating certificate(s)


I have issue with creating new certificate. am using this command to create:

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 tls-sni-01

but now server returns:

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:

Any idea what I need to do to create certs again?

Kind regards

You need to change tls-sni-01 to http-01. See IMPORTANT: What you need to know about TLS-SNI validation issues for more information.

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.

the only workaround is to use DNS validation.

How is this working?

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 which may support your DNS provider if Certbot does not.

OK, I will open port 80.

For me it is more important to get a new cert automatically without being prompted. Is this possible?

Kind regards

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

 - The following errors were reported by the server:

   Domain: cloud.***domain***.de
   Type:   connection
   Detail: Fetching
   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:~ $ 

What is going wrong?

Kind regards

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

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. :rofl:

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.

I will update the case next week.

Thank you for your help so far…

Kind regards


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. :slight_smile:

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.

Kind regards

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.

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