Certbot on Debian 9 with Nginx: Could not automatically find a matching server block

Help
1

I’m using Certbot v0.21.1 (also tried latest certbot-auto, same issue). Trying to renew certificates for my domains I get an error message: “Could not automatically find a matching server block. Set the server_name directive to use the Nginx installer.” I have server_name defined and pointing to my domains in all of my server blocks in nginx config files.

Running nging -t command produces:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

How can I fix this?

My domain is: basebit.studio, waterlines.net

I ran this command: sudo certbot renew --dry-run

It produced this output:

Summary 
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/basebit.studio.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for basebit.studio
tls-sni-01 challenge for waterlines.net
tls-sni-01 challenge for www.basebit.studio
tls-sni-01 challenge for www.waterlines.net
Cleaning up challenges
Attempting to renew cert (basebit.studio) from /etc/letsencrypt/renewal/basebit.studio.conf produced an unexpected error: Could not automatically find a matching server block. Set the `server_name` directive to use the Nginx installer.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/basebit.studio/fullchain.pem (failure)

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/basebit.studio/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------
1 renew failure(s), 0 parse failure(s)

My web server is (include version):
Nginx v1.13.9

The operating system my web server runs on is (include version):
Debian v9.4

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No

2

Hi,

Can you try lookup your server name basebit.studio in any of your nginx configs ?

Thank you

3

How do you mean lookup my server name? (Any specific command I should run?)

Here is the excerpt from configs that defines server_name for basebit.studio:

server {
        listen               80;
        listen               443 ssl;
        server_name          www.basebit.studio;
        ssl_certificate      /etc/letsencrypt/live/basebit.studio/fullchain.pem;
        ssl_certificate_key  /etc/letsencrypt/live/basebit.studio/privkey.pem;
        # $scheme will get the http protocol
        # and 301 is best practice for tablet, phone, desktop and seo
        return 301 $scheme://basebit.studio$request_uri;
}

server {
    listen       80;
    server_name  basebit.studio cdn.basebit.studio;
...
...
4

Hi,

Do you have an ssl section of basebit.studio?

Thank you

5

SSL section for basebit.studio (located inside server block from above post):

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/basebit.studio/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/basebit.studio/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on; #ensure your cert is capable
ssl_stapling_verify on; #ensure your cert is capable
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
6

I guess certbot is confused by the fact that you have HTTP and HTTPS in one virtual host. The certbot autoinstaller probably isn’t going to work in this configuration. You may need to reissue your certificate with certbot certonly -a nginx if you want to keep this configuration.

7

@Patches Tried that command and it didn't work. I also tried splitting HTTP & HTTPS and it didn't work either.

Checking letsencrypt.log I've saw this line inside :

Could not parse file: /etc/nginx/nginx.conf due to Expected stringEnd (at char 154), (line:14, col:1)

It didn't make any sense to me as that line is just

http {

Then I started removing different parts of the http block and found out where certbot parser choked.
A commented out line inside one of a log_format definitions was causing problems. After removing that line certbot started working.

The problematic line: #'user_agent="$http_user_agent" '

log_format apm '"$time_local" client=$remote_addr '
               'method=$request_method request="$request" '
               'request_length=$request_length '
               'status=$status bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               #'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time';
8

@bmw @erica This looks like an upstream augeas bug?

9

Nginx doesn’t use augeas; this is a bug in our parser. Thanks for letting us know, I’ll add it to our bug tracker.

2 Likes
10

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