Failure to setup the Certbot on new server (Debian 9)

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: portal.encode1.com.au/

I ran this command: sudo certbot --nginx
I am following the step mentioned in the
Certbot - Debianstretch Nginx to install the certificates.

It produced this output:
Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/portal.encode1.com.au/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/portal.encode1.com.au/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

My web server is (include version):
nginx version: nginx/1.10.3

The operating system my web server runs on is (include version):
Debian GNU/Linux 9.13 (stretch)

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

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

I have one server and I am following the steps mention in the
Certbot - Debianstretch Nginx.
This is the new installation.
But I am getting error that pem file is not there. I do not know how to get it ?
Please help.

BR
Dhrupal

Hi @dhrupal1989 and welcome to the LE community forum :slight_smile:

Please show the output of:
certbot certificates

and

grep -Eri 'letsencrypt|server_name|listen|redirect|rewrite|cert|root|known' /etc/nginx
1 Like

@dhrupal1989, did you possibly get a certificate from Certbot before and then delete it for some reason (either with rm or with certbot delete)? Deleting a certificate that's in use can leave you with an invalid web server configuration, even if you use Certbot to perform the deletion.

Hello,
Thank you so much for your quick response. Please find the command output as below:

certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


No certificates found.


grep -Eri 'letsencrypt|server_name|listen|redirect|rewrite|cert|root|known' /etc/nginx
/etc/nginx/mime.types: application/x-x509-ca-cert der pem crt;
/etc/nginx/fastcgi.conf:fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
/etc/nginx/fastcgi.conf:fastcgi_param DOCUMENT_ROOT $document_root;
/etc/nginx/fastcgi.conf:fastcgi_param SERVER_NAME $server_name;
/etc/nginx/fastcgi.conf:# PHP only, required if PHP was built with --enable-force-cgi-redirect
/etc/nginx/fastcgi.conf:fastcgi_param REDIRECT_STATUS 200;
/etc/nginx/scgi_params:scgi_param DOCUMENT_ROOT $document_root;
/etc/nginx/scgi_params:scgi_param SERVER_NAME $server_name;
/etc/nginx/ssl/nginx.crt:-----BEGIN CERTIFICATE-----
/etc/nginx/ssl/nginx.crt:-----END CERTIFICATE-----
/etc/nginx/conf.d/fs.conf_bkp: listen 8735 default_server;
/etc/nginx/conf.d/fs.conf_bkp: listen [::]:8735 default_server;
/etc/nginx/conf.d/fs.conf_bkp: # listen 443 ssl default_server;
/etc/nginx/conf.d/fs.conf_bkp: # listen [::]:443 ssl default_server;
/etc/nginx/conf.d/fs.conf_bkp: # Self signed certs generated by the ssl-cert package
/etc/nginx/conf.d/fs.conf_bkp: root /var/www/html/fs;
/etc/nginx/conf.d/fs.conf_bkp: server_name _;
/etc/nginx/conf.d/fs.conf_bkp: # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/etc/nginx/conf.d/fs.conf_bkp: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
/etc/nginx/conf.d/nexc5.conf: listen 443 ssl default_server;
/etc/nginx/conf.d/nexc5.conf: listen [::]:443 ssl default_server;
/etc/nginx/conf.d/nexc5.conf: # Self signed certs generated by the ssl-cert package
/etc/nginx/conf.d/nexc5.conf: root /var/www/html/NexC5;
/etc/nginx/conf.d/nexc5.conf: server_name portal.encode1.com.au;
/etc/nginx/conf.d/nexc5.conf: ssl_certificate /etc/letsencrypt/live/portal.encode1.com.au/fullchain.pem; # managed by Certbot
/etc/nginx/conf.d/nexc5.conf: ssl_certificate_key /etc/letsencrypt/live/portal.encode1.com.au/privkey.pem; # managed by Certbot
/etc/nginx/conf.d/nexc5.conf: # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/etc/nginx/conf.d/nexc5.conf: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
/etc/nginx/conf.d/nexc5.conf: listen 443 ssl;
/etc/nginx/conf.d/nexc5.conf: server_name "~^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$"; # catch ip address
/etc/nginx/conf.d/c4.conf_bkp: listen 8443 default_server;
/etc/nginx/conf.d/c4.conf_bkp: listen [::]:8443 default_server;
/etc/nginx/conf.d/c4.conf_bkp: #listen 443 ssl default_server;
/etc/nginx/conf.d/c4.conf_bkp: #listen [::]:8443 ssl default_server;
/etc/nginx/conf.d/c4.conf_bkp: # Self signed certs generated by the ssl-cert package
/etc/nginx/conf.d/c4.conf_bkp: root /var/www/html/c4;
/etc/nginx/conf.d/c4.conf_bkp: server_name portal.noboxtelecoms.com;
/etc/nginx/conf.d/c4.conf_bkp: #ssl_certificate /etc/letsencrypt/live/portal.callcontinent.com/fullchain.pem; # managed by Certbot
/etc/nginx/conf.d/c4.conf_bkp: #ssl_certificate_key /etc/letsencrypt/live/portal.callcontinent.com/privkey.pem; # managed by Certbot
/etc/nginx/conf.d/c4.conf_bkp: # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/etc/nginx/conf.d/c4.conf_bkp: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
/etc/nginx/conf.d/fs.conf: listen 8735 default_server;
/etc/nginx/conf.d/fs.conf: listen [::]:8735 default_server;
/etc/nginx/conf.d/fs.conf: # listen 443 ssl default_server;
/etc/nginx/conf.d/fs.conf: # listen [::]:443 ssl default_server;
/etc/nginx/conf.d/fs.conf: # Self signed certs generated by the ssl-cert package
/etc/nginx/conf.d/fs.conf: root /var/www/html/fs;
/etc/nginx/conf.d/fs.conf: server_name _;
/etc/nginx/conf.d/fs.conf: # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/etc/nginx/conf.d/fs.conf: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
/etc/nginx/sites-available/default: listen 80 default_server;
/etc/nginx/sites-available/default: listen [::]:80 default_server;
/etc/nginx/sites-available/default: # listen 443 ssl default_server;
/etc/nginx/sites-available/default: # listen [::]:443 ssl default_server;
/etc/nginx/sites-available/default: # Self signed certs generated by the ssl-cert package
/etc/nginx/sites-available/default: root /var/www/html;
/etc/nginx/sites-available/default: server_name _;
/etc/nginx/sites-available/default: # deny access to .htaccess files, if Apache's document root
/etc/nginx/sites-available/default:# listen 80;
/etc/nginx/sites-available/default:# listen [::]:80;
/etc/nginx/sites-available/default:# server_name example.com;
/etc/nginx/sites-available/default:# root /var/www/example.com;
/etc/nginx/snippets/snakeoil.conf:# Self signed certificates generated by the ssl-cert package
/etc/nginx/snippets/snakeoil.conf:ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
/etc/nginx/snippets/snakeoil.conf:ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
/etc/nginx/uwsgi_params:uwsgi_param DOCUMENT_ROOT $document_root;
/etc/nginx/uwsgi_params:uwsgi_param SERVER_NAME $server_name;
/etc/nginx/fastcgi_params:fastcgi_param DOCUMENT_ROOT $document_root;
/etc/nginx/fastcgi_params:fastcgi_param SERVER_NAME $server_name;
/etc/nginx/fastcgi_params:# PHP only, required if PHP was built with --enable-force-cgi-redirect
/etc/nginx/fastcgi_params:fastcgi_param REDIRECT_STATUS 200;
/etc/nginx/nginx.conf: # server_names_hash_bucket_size 64;
/etc/nginx/nginx.conf: # server_name_in_redirect off;
/etc/nginx/nginx.conf:# listen localhost:110;
/etc/nginx/nginx.conf:# listen localhost:143;

Hello,

I am never able to get a certificate from Certbot before for this server.
I have never used the rm or certbot delete.

BR
Dhrupal

Did you migrate the nginx configuration for that website from another server by any chance? Because the nginx configuration is clearly mentioning directives linking to a certbot acquired certificate.

1 Like

Hello,

I have one active server on which our product is running.
Now, I am preparing another server on new Hardware which will work as the Backup.
So suppose Active server crash somehow then this server will be handle the Traffic.

In this Backup server Installation, I am getting this error.
On the Active server there is all certificate. But I do not think that should affect here.

How did you come by the nginx configuration for the backup server you're preparing now? I mean, where did the configuration come from?

1 Like

I have copy the nginx.conf file from the active server where out product is running.
Its always going to be same for the any server in our product.
In active server, we have created this configuration file and which is working ok.

Here's the cause of your problems: the nginx.conf from your active server is referencing to certificates which are non-existing on your backup server.

1 Like

Yes, that is true.
Can u please help me how I can get this certificates ? or what I am doing wrong here ?
How can I resolve it ?

It produced this output:
Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/portal.encode1.com.au/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/portal.encode1.com.au/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

As I mentioned,
I am following this step:

Do not use references to non-existing files in your nginx configuration file, in this case the not yet existing certificates. I'll leave it up to you on how you wish to do that, as there are multiple ways.

If possible can u suggest the one way at least to resolve it ?
I am confuse so if you give some steps then it will be a great help.

  • Change the reference from a non-existing file to an existing file. For Let's Encrypt to work, it doesn't need to be a real certificate, a fake, self-signed certificate would suffice. However, if your server is "live" when you do that, all visitors to your HTTPS site would get a certificate error.
  • Modify your nginx configuration to a HTTP only situation and let certbot generate a new HTTPS virtualhost with the HTTP virtualhost as template. Depending on how your nginx is configured, it might be as simple as removing the HTTPS virtualhost and disable the HTTP to HTTPS redirect. That said, with a complicated nginx configuration, it might not be that simple.
1 Like

@dhrupal1989, one other way to describe this problem that @Osiris has identified:

Certbot usually expects your server to have a working HTTP server before it can request any certificates. Its specialty is converting an existing, correctly-functioning HTTP site into a correctly-functioning HTTPS site.

When you copied the post-Certbot nginx configuration onto a different server, it was no longer a valid HTTP-only configuration on that server (because it referred to already-existing certificate files, which are not present on the second server yet). Because this configuration is invalid, Certbot can't work with it to obtain a certificate there.

One option would be to copy the entire /etc/letsencrypt directory from the first server onto the second server (if so, you must do this ① in a secure, encrypted way, and ② in a way that preserves symbolic links). @Osiris may be unhappy with me for assuming this, but rsync -a on a modern Linux system is normally a valid method that meets these criteria.

Another option would be to start over with a completely new nginx configuration on the second server. (Then nginx will work there for HTTP, and so Certbot will work to convert it to HTTPS.)

A third option would be to manually edit the nginx configuration file on the second server to remove all of the HTTPS configuration sections that Certbot had added on the first server. (I think this is the method that @Osiris finds most straightforward, and I agree, if you have or can get at least a little familiarity with nginx configuration files.)

A fourth option would be to use certbot --standalone on the second server, and then, once the certificate is successfully issued, to re-run with certbot --nginx --force-renewal; this method is probably the most confusing and error-prone.

3 Likes

Thank you so much for this great explanation and its good learning for me.
Issue is resolved now.

Thanks a lot.

1 Like

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