Producing certificats manually, problems with connecting

My domain is:

I ran this command:
sudo certbot certonly --standalone -manual -d

It produced this output:
The server could not connect to the client to verify the domain :: Fetching Timeout during connect (likely firewall problem)

My web server is (include version):
The operating system my web server runs on is (include version):
Ubuntu 16.04
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
Plesk (letsencrypt on this Pleskversion is no longer functioning)

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 0.31.0

Hi, in the past i produced certificates manually that i uploaded to the server. In the meantime i have changed from a textfile to a DNS-Record for the validation.

Because i now am in an awkward position that Hosteurope will not support the Install i would like to produce the certificates manually again to upload them, we will renew the server very soon but for now i need to produce certificates.

Should i try this on an ubuntu system with version 18.04? My laptop has a newer version of Ubuntu.
Could this be caused by old files in .well-known/acme-challenge/ where there are several textfiles.


Hi @janvl, and welcome to the LE community forum :slight_smile:

You have to remove "--standalone" from that command:


Thank you rg305

I ran this without --standalone, then i get a question apache/nginx/standalone where i answered with standalone.
I have stopped nginx and apache because with those active it will not work (port 80 is occupied), and in the past i used --standalone to get the certificate-files on my local machine.

I have the idea that certbot cannot find a "fitting" textfile because i used the dns-record, is there a way to produce a fitting textfile manually?


1 Like

Your DNS has both an A and AAAA record for IPv4 and IPv6. Connections using IPv6 fail with a timeout. Let's Encrypt servers favor IPv6 so you should correct your IPv6 or remove the AAAA record from your DNS.

Also see Let's Debug test site for info (link here)


Are you running certbot on the same system that will be using the cert?

Maybe you need to update that version.

Oh my!

Maybe you can use the snap version...
Certbot Instructions | Certbot (


Thanks MikeMcQ and rg305

I will try the several options, first de-activate IPv6.

The installation with snap is an idea but i am about to get e new PC where i will run Kubuntu 22.04 together with Windows 11 professional. The 9th a hospitalisation and an operation broke my planning ;-(.



i run certbot on my local machine, not the server where the certificates must come.

I have removed the AAAA-records - the result is that now says everything is ok.

Then i ran "certbot certonly --standalone -manual -d" the result is a 404 for the textfile in .well-known/acme-challenge/.

Obviously certbot searches for a text-file that is not there.

When i run the command several times (with webroot or standalone) i get

Type: unauthorized
Detail: Invalid response from

I remember that when i used this a few years ago i got an acme-challenge-string presented that i had to copy in a file in the directory on the server so the domain was authorised and the certificates were produced on my local machine. I then copied them on the server.

Please any suggestions?


1 Like

The thing to do would be to upgrade Ubuntu and Plesk to a version which is not end-of-life.

If you want to try use Certbot:

  1. Identify what directory your domain ( is served from, i.e. the document root of Moodle.

  2. Use that directory when you call Certbot with the webroot plugin:

    certbot certonly --webroot -w /path/to/moodle/ -d --dry-run

This is assuming that you are running Certbot on the Plesk server where Moodle is running.


What _az describes is best. But, the process you used "a few years ago" sounds like a manual request. The command in your first post did not use the correct format for that. See the below topic for the proper format (basically, leave off --standalone and use --manual with two leading dashes)


That's why it failed!
Good eye @MikeMcQ !!!


Thanks _az

the customer has been informed that we need to move to another server, for many reasons.

I will try and run certbot directly on that server but i do not know in what aspect Plesk has modified the way certbot is working on that server. That is why i tried the manual procedure again.


1 Like


deleting the IPv6 records made it possible to generate the certificates with Plesk.
So for the meantime I will delete those - renew the certificate - enter the IPv6 records again.

This way i gain some time to initiate a move to another server without Plesk but with ISPConfig where certificates are renewed automatically.

Just for my own knowledge i will try what you advised, in case off . . . .

Thanks and regards,

1 Like

Maybe your IPv6 address is wrong?

These commands are one way to check your public IP for IPv4 and 6

curl -4
curl -6

I can't connect using IPv6 and neither can Let's Debug (


Possibly hitting the Rate Limits?


Hi Mike
the IPv6 Adress is OK, just with certbot in this settings it will not work with IPv6, it works without.

Hi barff7709
3 or 4 times is not enough to break it.



If that IP was correct then something in your system still does not handle IPv6 properly.

What does this show?

sudo netstat -pant | grep :80

Here is what happens when I try IPv4 and 6 (Let's Debug similar failure). Note this has nothing to do with Let's Encrypt I am just trying to reach your "home" page

(IPv4 correct)
curl -I4 -m10
HTTP/1.1 301 Moved Permanently
Server: Apache

(IPv6 fails)
curl -I6 -m10
curl: (28) Failed to connect to port 80 after 5001 ms: Connection timed out

Hi Mike,

when i look at the certificate for with Firefox ist says the certificate is valid to Thu, 30 Mar 2023.

When i lokk with DNSLytics i see the correct IPv4 and IPv6 addresses through which the domain resolves.

So, deleting the IPv6 records, then run the renewal for the certificate with plesk and afterwards put the IPv6 records back in the DNS solves my problem for now.
The cause, a server that is too old, must be solved within the coming 3 month's. I have already a Server with Ubuntu 22.04 where i am testing. A server that was new installed does not have trouble running certbot, i already have done that 3 times.

I do thank you for the trouble you took and for giving me the solution to solve my (temporarily problem).



You still might want to consider uising the Staging Environment while debuging and testing.


You are right, i have made a note for future problems.



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