Error when using certbot to create certificate

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., 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: certbot

It produced this output: “there were too many requests of a given type” (I know this is because I used too many certificates in one week) but also "nginx: [emerg] cannot load certificate “/etc/letsencrypt/live/lcnwiki/xyz-0001/fullchain.pem”: BIO_new_file()failed (SSL error: 02001002:system library:fopen:No such file or directory:fopen(’ /etc/letsencrypt/live/’,‘r’) error nginx: configuration file /etc/nginx/.conf test failed

The nginx plugin is not working; there may be problem with your existing configuration."
(I think I messed with it too much while trying to add certificate).

My web server is (include version): Vultr console which I think can run both Apache and nginx

The operating system my web server runs on is (include version): I have safari, firefox and chrome

My hosting provider, if applicable, is: Vultr

I can login to a root shell on my machine (yes or no, or I don’t know): 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): no

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

Screen Shot 2020-03-01 at 8.18.25 PM|690x166

Hi @Terranihil,

It looks like you’ve deleted a certificate that nginx was actively using, and so nginx can no longer start up.

You could look at your nginx configuration with

sudo grep -r /etc/letsencrypt/live /etc/nginx

to find where this certificate is currently being referenced by the nginx configuration.


Thanks @schoen . This is what I got when I did that.

If you try moving that mediawiki_https.conf file elsewhere (outside of /etc/nginx/conf.d), nginx should be able to start up again. Perhaps Certbot created it and based on a mediawiki.conf file, or perhaps you created it yourself based on something else that Certbot created earlier?

1 Like

@schoen I probably created it myself. I am not sure how to “move” it though. This is the first time I use something like this so I don’t know much.

I tried updating nginx using apt-get update and apt-get install nginx but it did not work.The same error showed.

@schoen can you explain how to move the mediawiki_https.conf some where else?

I was referring to the Unix mv command, something like

mv /etc/nginx/conf.d/mediwiki_https.conf /root

Do you also have a non-HTTPS Mediawiki configuration file in /etc/nginx/conf.d?

@schoen The mv command did not give an output. Certbot shows a different error now, and the website is still down.

I am unsure how to check if I have a non-HTTPS Mediawiki configuration file.

Yes, that means that it worked properly. :slight_smile:

To take one miniscule example, there is a core value in the Unix culture, which Raymond calls “Silence is Golden,” that a program that has done exactly what you told it to do successfully should provide no output whatsoever. It doesn’t matter if you’ve just typed a 300 character command line to create a file system, or built and installed a complicated piece of software, or sent a manned rocket to the moon. If it succeeds, the accepted thing to do is simply output nothing. The user will infer from the next command prompt that everything must be OK.


You could try sudo service nginx start to see if it comes up. (Amusingly, I think this command violates the “silence is golden” principle I just mentioned above, because I think it will explicitly tell you whether or not the service was able to be started.)

This Certbot error shows that you repeated the process too many times so Certbot can’t get a new certificate for your domain from Let’s Encrypt right away. If you haven’t deleted the old certificates, you should still be able to use one.

Try ls /etc/nginx/conf.d to see which configuration files are present there. Perhaps there is one called something like mediawiki.conf?

1 Like

@schoen The first command gave no output. The second did.

@schoen In Ubuntu cockpit, The Apache HTTP Server failed, while the nginx server (which was previously failed) is now active. The site is still down.

It is now listening on port 80 (HTTP), although you might not notice this success because the HTTP service tries to redirect you to port 443 (HTTPS), which is currently not available.

Could we see the mediawiki_http.conf contents? For example cat /etc/nginx/conf.d/mediawiki_http.conf.

1 Like


It cut off some of the top code.

@schoen I think I have nginx on port 80.

Maybe you could run certbot certificates to see what existing certificates you have that Certbot knows about. (If you’ve modified or deleted things in /etc/letsencrypt, Certbot might be confused and might not give the complete picture.)

It should be possible to get Certbot to do a reinstall of an existing certificate (that it knows about) with --reinstall, which could recreate a working HTTPS configuration without re-requesting the certificate from the certificate authority. There are other things that could go wrong with that, but they’re different from the things that are currently going wrong. :slight_smile:

@schoen No certificates apparently.

@schoen Chrome used to say that the site was not certified etc, but now it says it cannot connect to the server, so I didn’t think it was a certificate issue. But I am not the expert here so I don’t know. This is what Ubuntu cockpit says when I click on the “failed” Apache server.

@schoen Sorry for multiple replies. But I ran commands grep -ri listen /etc/nginx and grep -ri listen /etc/apache2 to look at the ports and this is what came up.

It seems that you deleted /etc/letsencrypt/live/, which stopped nginx from starting up. After you moved the /etc/nginx/conf.d/mediwiki_https.conf file out of /etc/nginx/conf, nginx is no longer looking for that file but is also no longer attempting to provide HTTPS (which is what I expected would happen).

Could you run ls -lR /etc/letsencrypt/{live,archive,renewal} so we could see what the current state of /etc/letsencrypt is?