Certbot nginx plugin could not open file

Posted November 30, 2017 14.4k views
NginxLet's EncryptUbuntu 16.04


I have a simple personal website that I want to make HTTPS.

I setup my Nginx server block following this tutorial:

And I followed this tutorial to install Let’s Encrypt on my server block:

Everything worked like a charm, up to Step 4 where the following command:

sudo certbot --nginx -d -d

return this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not open file: /etc/nginx/sites-enabled/
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1):
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for
tls-sni-01 challenge for
Cleaning up challenges
Could not open file: /etc/nginx/sites-enabled/
Cannot find a VirtualHost matching domain In order for Certbot to correctly perform the challenge please add a corresponding server_name directive to your nginx configuration:

I checked the permissions on my server block file in /etc/nginx/ but it all look good:

├── [drwxr-xr-x]  conf.d
├── [drwxr-xr-x]  sites-available
│   ├── [-rw-r--r--]  default
│   └── [-rw-r--r--]
├── [drwxr-xr-x]  sites-enabled
│   └── [lrwxrwxrwx] -> sites-available/

I tried to access the log on /var/log/letsencrypt, but it wasn’t helpful:

2017-11-29 21:03:32,206:DEBUG:certbot.error_handler:Calling registered functions
2017-11-29 21:03:32,206:INFO:certbot.auth_handler:Cleaning up challenges
2017-11-29 21:03:32,478:WARNING:certbot_nginx.parser:Could not open file: /etc/nginx/sites-enabled/
2017-11-29 21:03:33,529:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.19.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/certbot/", line 861, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/dist-packages/certbot/", line 698, in run
    certname, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/", line 85, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python2.7/dist-packages/certbot/", line 357, in obtain_and_enroll_certificate
    certr, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python2.7/dist-packages/certbot/", line 318, in obtain_certificate
  File "/usr/lib/python2.7/dist-packages/certbot/", line 74, in get_authorizations
    resp = self._solve_challenges()
  File "/usr/lib/python2.7/dist-packages/certbot/", line 115, in _solve_challenges
    resp = self.auth.perform(self.achalls)
  File "/usr/lib/python2.7/dist-packages/certbot_nginx/", line 767, in perform
    sni_response = chall_doer.perform()
  File "/usr/lib/python2.7/dist-packages/certbot_nginx/", line 55, in perform
    vhost = self.configurator.choose_vhost(achall.domain)
  File "/usr/lib/python2.7/dist-packages/certbot_nginx/", line 242, in choose_vhost
    "") % (target_name))
MisconfigurationError: Cannot find a VirtualHost matching domain In order for Certbot to correctly perform the challenge please add a corresponding server_name directive to your nginx configuration:

I changed my server block file permissions to 777, but to no effect!

Where can I found a solution to this issue?

Thank you for your help.
Yohann Paris

  • Hi, can you please post the output of the following command? It tests the Nginx config and outputs the result—I’m suspecting that Certbot is able to open the file but not parse it properly.

    sudo nginx -t
  • I tried sudo nginx -t before, but everything is fine:

    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful

    I also run sudo nginx -s reload to be sure.

    For information here is the content of my server bloc:

    server {
        listen 80;
            listen [::]:80 ipv6only=on;
            root /var/www/;
            index index.html index.php;
        autoindex off;
            server_name *;
            location / {
                    try_files $uri $uri/ =404;
            autoindex off;
            location ~ /\.ht {
                    deny all;
  • I’m currently stuck in the exact same place, any luck? Only difference for me was that I had it working some months ago, but never set auto-renew. Now on trying to refresh the certificate I am getting the exact same errors, and ‘sudo nginx -t’ reads the same. I don’t think anything changed in my configuration since then, so I’m scratching my head....

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hey all,

I also had this problem but this ended up working for me:

It has to do with broken symlinks in /sites-enabled. A symlink may break for different reasons, in this case, nginx can still follow the link, but certbot cannot. Why? I don’t know tbh.

To fix, I simply removed the symlink and created a new one.

If you list the directory you can typically spot a broken symlink with red text and a black background, and a working symlink with blue text:

naderabbara@server:/etc/nginx/sites-enabled$ ls
brokensymlink    workingsymlink

I removed the broken symlink and created a new one:

sudo rm <broken symlink>
sudo ln -s path/to/nginx/conf nginx-conf

Hope it’s this simple for you.

  • Thanks for the report.
    Indeed, my symlink where red, and once I recreated them things started to work well.

    Unfortunately, now there is something not going well. Apparently a test done by certbot is not accepted by Let’s encrypt on version prior to 0.21.0.

    Even after updating apt-get I’m stuck in version 0.19.0, so I need to wait for the fixed version to be available on the packet manager.

    • I also had this problem. You could uninstall certbot and reinstall it and it may work, or you can force upgrade packages individually by running apt list --upgradable and then apt-get install <package>. That didn’t work for me.

      Alternatively, you can run the apt-get distro-upgrade command, and this will upgrade every package that has an available upgrade. However you should be wary this might destabilize your setup. I didn’t have anything serious on my droplet and it was backed up, so I went ahead and did this and it worked well.

      Good luck!