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.
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):
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 ?
@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.
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.
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.
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.
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.
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.