Fix error “Unable to install the certificate” on Ubuntu server Nginx with two domain names

When installing I got the error “Unable to install the certificate”. I am installing next cloud on Ubuntu server 18.04 with Nginx. I have two Nginx config files. They are:

  • /etc/nginx/conf.d/default.conf
  • /etc/nginx/conf.d/nextcloud.conf

When I ran the certbot command, defult.conf did not have a server_name set so that may be why it was unable to install the certificates. It did not set up either of the configuration files to use the certificate. Now they both have the server_name set like so:

  • /etc/nginx/conf.d/default.conf as server_name blue.[myDomain].com;
  • /etc/nginx/conf.d/nextcloud.conf as server_name bucket.blue.[myDomain].com;

The command I ran and output it gave is bellow. My question is, is there a way to rerun the certbot command and get it to install the certificate and set up the Nginx configuration files or is there instructions for doing that manually?

Thanks for your help.

I ran this command:
sudo certbot --nginx --agree-tos --redirect --staple-ocsp --email [myEmail]@gmail.com -d bucket.blue.[myDomain].com,blue.[myDomain].com

It produced this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for blue.[myDomain].com
http-01 challenge for bucket.blue.[myDomain].com
Using default addresses 80 and [::]:80 ipv6only=on for authentication.
Waiting for verification…
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/conf.d/nextcloud.conf
Could not automatically find a matching server block. Set the server_name directive to use the Nginx installer.

IMPORTANT NOTES:

  • Unable to install the certificate
  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/bucket.blue.[myDomain].com/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/bucket.blue.[myDomain].com/privkey.pem
    Your cert will expire on 2020-02-27. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the “certonly” option. To non-interactively renew all of
    your certificates, run “certbot renew”
  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.

My web server is (include version):
nginx version: nginx/1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

My hosting provider, if applicable, is:
Self

I can login to a root shell on my machine:
Yes

I’m using a control panel to manage my site:
No

The version of my client is:
certbot 0.27.0

My domain is:
kenzua

Please show file:
/etc/nginx/conf.d/nextcloud.conf

1 Like

Sure. The content of /etc/nginx/conf.d/nextcloud.conf is bellow. Thanks

server {
    listen 80;
    server_name bucket.blue.kenzua.com;

    # Add headers to serve security related headers
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;

    #I found this header is needed on Ubuntu, but not on Arch Linux. 
    add_header X-Frame-Options "SAMEORIGIN";

    # Path to the root of your installation
    root /usr/share/nginx/nextcloud/;

    access_log /var/log/nginx/nextcloud.access;
    error_log /var/log/nginx/nextcloud.error;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
    # last;

    location = /.well-known/carddav {
        return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
       return 301 $scheme://$host/remote.php/dav;
    }

    location ~ /.well-known/acme-challenge {
      allow all;
    }

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Disable gzip to avoid the removal of the ETag header
    gzip off;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;

    location / {
       rewrite ^ /index.php$uri;
    }

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
       deny all;
    }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
       deny all;
     }

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
       include fastcgi_params;
       fastcgi_split_path_info ^(.+\.php)(/.*)$;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       fastcgi_param PATH_INFO $fastcgi_path_info;
       #Avoid sending the security headers twice
       fastcgi_param modHeadersAvailable true;
       fastcgi_param front_controller_active true;
       fastcgi_pass unix:/run/php/php7.2-fpm.sock;
       fastcgi_intercept_errors on;
       fastcgi_request_buffering off;
    }

    location ~ ^/(?:updater|ocs-provider)(?:$|/) {
       try_files $uri/ =404;
       index index.php;
    }

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the PHP block
    location ~* \.(?:css|js)$ {
        try_files $uri /index.php$uri$is_args$args;
        add_header Cache-Control "public, max-age=7200";
        # Add headers to serve security related headers (It is intended to
        # have those duplicated to the ones above)
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;
        # Optional: Don't log access to assets
        access_log off;
   }

   location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
        try_files $uri /index.php$uri$is_args$args;
        # Optional: Don't log access to other assets
        access_log off;
   }
}
1 Like

I added the /etc/nginx/conf.d/nextcloud.conf to this tread.

Confusing/Contradicting…

Please show output of:
nginx -T | grep -i server_name

Thanks for your help. Here is the output of that command.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;
  server_name blue.kenzua.com;
fastcgi_param  SERVER_NAME        $server_name;
fastcgi_param  SERVER_NAME        $server_name;
    server_name bucket.blue.kenzua.com;

Everything “looks” OK.
But, for some reason, ‘certbot’ is unable to properly parse through the config and doesn’t locate the server_name entry for bucket.
[passing this to someone more proficient in these matters: @schoen]

2 Likes

Hi @Alphonso

the installation can’t work.

Your command uses two domain names. Checking your domain you have created that certificate.

But you use two vHosts with one domain name -> that’s a mismatch.

So you have two options:

  • Use one vHost with both domain names and the existing certificate
  • use two vHosts with one domain name, create two certificates, every with one domain name and use that.

PS: Or install the existing certificate manual, later use certonly.

2 Likes

Is it possible to use the first option and still have a different root folder for each domain name? I was looking around for examples of how to do this and did not see anything that looks like what I am expecting.

For the second option, is it correct that I would leave the Ngnix configuration as is and run the certbot command twice? Once for each domain?

Thanks for your help.

1 Like

As added: You can install the certificate manual.

Yes, that’s required. Two certificates -> run Certbot twice.

PS: If you want different vHosts with different roots, normally, different certificates are the best solution.

1 Like

Sounds good. I will go with two different certificates then. To clarify I just add certonly and rerun the command with one domain name to use the current certificate with one domain name? Like so:

sudo certbot certonly --nginx --agree-tos --redirect --staple-ocsp --email [myEmail]@gmail.com -d bucket.blue.[myDomain].com

Then if I want one on the second domain, I would just rerun the organl command with just that domain? Like so:

sudo certbot --nginx --agree-tos --redirect --staple-ocsp --email [myEmail]@gmail.com -d blue.[myDomain].com

1 Like

If you have two port 80 vHosts, you don’t need certonly. Then Certbot should be able to install the certificates.

2 Likes

In nginx it is possible (albeit incredible over complicated - but possible).

If you are essentially not going to use the port 80 connections (by redirecting them all to port 443), then you should use a single port 80 block and handle all your challenge requests from a single point.

1 Like

I ran the certbot command for each of the domains and they seemed to work as expected. I did have trouble getting one of them to redirect 80 to 443. I had to comment out the IPv6 stuff in the default config. It sounds to me like what you are saying is related to that. I have what looks like a port 80 redirect in both vhost files. Something like bellow. So would it be best to only have that in one file?

server {
    if ($host = blue.kenzua.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  listen 80;
  server_name blue.kenzua.com;
    return 404; # managed by Certbot
}
1 Like

If all port 80 vhost configs redirect to port 443, then yes; You can combine them into just one single vhost config.

1 Like