"The error was: NoInstallationError()" issue on Nginx/CentOS7 with --nginx

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. https://crt.sh/?q=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:


I ran this command:

sudo certbot --nginx

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError()

2018-03-15 18:22:14,627:DEBUG:certbot.main:certbot version: 0.22.0
2018-03-15 18:22:14,627:DEBUG:certbot.main:Arguments: ['--nginx']
2018-03-15 18:22:14,627:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-03-15 18:22:14,645:DEBUG:certbot.log:Root logging level set at 20
2018-03-15 18:22:14,645:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-03-15 18:22:14,646:DEBUG:certbot.plugins.selection:Requested authenticator nginx and installer nginx
2018-03-15 18:22:14,647:DEBUG:certbot.plugins.disco:No installation (PluginEntryPoint#nginx):
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/certbot/plugins/disco.py", line 126, in prepare
  File "/usr/lib/python2.7/site-packages/certbot_nginx/configurator.py", line 131, in prepare
    raise errors.NoInstallationError
2018-03-15 18:22:14,647:DEBUG:certbot.plugins.selection:No candidate plugin
2018-03-15 18:22:14,647:DEBUG:certbot.plugins.selection:Selected authenticator None and installer None

My web server is (include version):

nginx version: nginx/1.12.2

The operating system my web server runs on is (include version):

CentOS 7

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):



This error is certbot can’t find your nginx.

Can you kindly run the following command and share the output?

which nginx
yum info nginx
nginx -V

Thank you

Referrence: https://github.com/certbot/certbot/issues/4937


thanks for your reply. I wish it was so simple. See below. Any help is hugely appreciated.
Also, I already saw that GitHub post earlier, and also created the symlinks. The issue remains.

which nginx

yum info nginx
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.vooservers.com
 * epel: mirror.bytemark.co.uk
 * extras: mirrors.melbourne.co.uk
 * remi-safe: mirror.netweaver.uk
 * updates: mirror.bytemark.co.uk
Installed Packages
Name        : nginx
Arch        : x86_64
Epoch       : 1
Version     : 1.12.2
Release     : 1.el7
Size        : 1.5 M
Repo        : installed
From repo   : epel
Summary     : A high performance web server and reverse proxy server
URL         : http://nginx.org/
Licence     : BSD
Description : Nginx is a web server and a reverse proxy server for HTTP, SMTP,
            : POP3 and IMAP protocols, with a strong focus on high concurrency,
            : performance and low memory usage.

nginx -V
nginx version: nginx/1.12.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) 
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'

Would you recommend to reinstall nginx?


I’m not sure what’s happening with your Nginx installation. But yes, if you can.

Thank you

OK, I’ll try that tomorrow first thing and report back. I installed (and started using) nginx only today, and everything is working well. The issue is only certbot.

Hi @lguariento,

I agree with @stevenzhu that this error ordinarily means that Certbot can’t find your copy of nginx, which doesn’t necessarily mean that nginx isn’t installed. :slight_smile:

Maybe you could try running

sudo which nginx

and also

sudo nginx -t

Hey, wait a minute: sudo which nginx returns

which: no nginx in ($PATH:/opt/jdk1.8.0_152/bin:/opt/jdk1.8.0_152/jre/bin:/usr/bin)

! Without ‘sudo’ is fine (/usr/sbin/nginx). What does it mean? What shall I do, then?


Well, that shows that root has a different PATH from your regular user and that’s also why it’s having trouble finding nginx.

Maybe you could figure out where root’s PATH is set from and add in /usr/sbin at the end.

If you have trouble with this, a temporary workaround could be

sudo env PATH="$PATH" certbot --nginx

which will run Certbot using your regular user’s PATH as root’s PATH.


Thank you a million. I now have a nice green lock on my address bar.



One thing to be aware of is that certbot renew (which is normally supposed to be run automatically from cron) might or might not work on your system because of this issue. You might want to keep an eye on this to investigate whether or not automated renewal is or isn’t working for you. Let’s Encrypt certificates expire after 90 days and certbot renew will start attempting to renew your certificate if run after 60 days from now (May 14, 2018).

So, do I have to do anything in the meantime, or do I just wait and see what happens on the 15th of May?

If you just want to test, you can run certbot renew now and check the output.

In the mean time,

You might try use this as crontab job:
env PATH="$PATH" certbot renew --quiet (add the path variable before certbot renew command)

In this way, the issue might solved. (Still a workaround though)

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

Processing /etc/letsencrypt/renewal/editor.curioustravellers.ac.uk.conf
Cert not yet due for renewal


The following certs are not due for renewal yet:
  /etc/letsencrypt/live/editor.curioustravellers.ac.uk/fullchain.pem expires on 2018-06-12 (skipped)
No renewals were attempted.

…is this good news :slight_smile: ?

Hard to say, since it didn't actually attempt a renewal (since one wasn't due yet). Maybe try with --dry-run to see what would happen if a renewal was due.

Although if you run that from root's cron, $PATH is just root's path anyway, right? So maybe echo "$PATH" as a normal user and put the literal path in the cron job. (ie, if echo "$PATH" prints, say, /bin:/usr/bin:/usr/sbin, then put env PATH="/bin:/usr/bin:/usr/sbin" certbot renew --quiet in cron)


This is not a totally realistic test because it uses the command-line environment rather than the crontab environment, which can often be different.

This is a potentially valid solution, but its effects similarly won't be known until mid-May.

There is a way to test somewhat more realistically with --force-renew but I don't think I really want to encourage people to ever put than in a cron job, even for testing purposes. :slight_smile: So if you don't mind waiting, @lguariento, I would suggest waiting until May and then seeing what happens.

1 Like

Uhm… with the --dry-run I get a

Attempting to renew cert (editor.curioustravellers.ac.uk) from /etc/letsencrypt/renewal/editor.curioustravellers.ac.uk.conf produced an unexpected error: Failed authorization procedure. editor.curioustravellers.ac.uk (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://editor.curioustravellers.ac.uk/.well-known/acme-challenge/cHAGyYrzSI53A6y2fo_4_jzvX1hH1S3ooJUzJsNnTHE: Timeout. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/editor.curioustravellers.ac.uk/fullchain.pem (failure)

error. I have a /var/www/certbot folder with 755 access and a

server {
    server_name .curioustravellers.ac.uk;
    charset utf-8;
    location "/.well-known/acme-challenge/" {
        root /var/www/certbot;

…etc in my ‘vhost’ file. What am I missing?

What happens if you combine the two?

sudo env PATH="$PATH" certbot renew --dry-run
1 Like

Same thing. I think the problem is that I cannot access


(it gives me 404 in the browser). What should I add to the configuration in order for it to be accessible?

Hmm, when I try to access your site over HTTPS I get a timeout. You get a 404, which is an odd difference. Do you have a firewall blocking port 443 for particular IP ranges or something like that?

1 Like