Renew cert with a GitLab instance produce error

I ran this command: certbot renew

I can’t show my domain, it’s a company service

It produced this output:

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


Processing /etc/letsencrypt/renewal/domain.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for domain
Cleaning up challenges
Attempting to renew cert (domain) from /etc/letsencrypt/renewal/domain.conf produced an unexpected error: Problem binding to port 80: Could not bind to IPv4 or IPv6… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/domain.co/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/domain.co/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)

My web server is (include version): nginx

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0


I have installed with omnibus and configured GitLab with https.

I used letsencrypt for this task.

Everything is running on a CentOS 7 server.

I have tried to mannually renew the cert with the following command :

certbot renew

But it fail :

Attempting to renew cert (domain) from
/etc/letsencrypt/renewal/domain.conf produced an unexpected error:
Problem binding to port 80: Could not bind to IPv4 or IPv6… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/domain/fullchain.pem (failure)

I have searched around and it looks like it’s because I have a running web server, but when I check any running service I have the following output :

systemctl status nginx

Unit nginx.service could not be found.

systemctl status httpd

Unit httpd.service could not be found.

I checked port 80 and 443 to see if they’re taken with my custom script :

#!/bin/bash

function is_port_free {
    netstat -ntpl | grep $1 -q ;
    if [ $? -eq 1 ]; then
        echo "free"
    else
        echo "taken"
    fi
}

port80=$(is_port_free 80)
if [ "$port80" == "taken" ]; then
    echo "Port 80 is taken"
else
    echo "Port 80 is free"
fi

port443=$(is_port_free 443)
if [ "$port443" == "taken" ]; then
    echo "Port 443 is taken"
else
    echo "Port 443 is free"
fi

Here is my output :

Port 80 is taken
Port 443 is taken

And here is my cron :

0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew

My gitlab.rb conf :

external_url 'https://domain'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/letsencrypt/live/domain/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/domain/privkey.pem"
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem"
#letsencrypt['enable'] = true

Do I have to stop my gitlab instance with gitlab-ctl stop, renew cert with certbot renew and start gitlab gitlab-ctl start ?

I don’t really like this solution, because my gitlab is on production.

The date I created the old certificate is 03/05/2019 and expire 01/08/2019.

Thanks for any help

If you are using nginx on the host with proxy_pass, it should be a fairly simple matter of:

certbot renew -a nginx --dry-run

If that ends up working in the end (without --dry-run), you can leave your cron job as-is, Certbot will remember to use -a nginx the next time.

Standalone is only suitable when you have no webserver at all.

Thanks for the reply I tested with the command and it output me :

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


Processing /etc/letsencrypt/renewal/domain


Cert is due for renewal, auto-renewing…
Could not choose appropriate plugin: The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(“Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.”,)
Attempting to renew cert (domain) from /etc/letsencrypt/renewal/domain.conf produced an unexpected error: The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(“Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.”,). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/domain/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/domain/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)

So it looks like nginx is configured in a non-standard way by GitLab Omnibus. You’d need to pass additional parameters to Certbot to tell it how to identify your nginx installation.

Alternatively, setup a webroot (location /.well-known/acme-challenge { ... }) in your nginx setup and use --webroot with Certbot.

Have you seen https://docs.gitlab.com/omnibus/settings/ssl.html though? It looks like GitLab can issue its own certificate without using Certbot.

1 Like

I have also tried to renew with gitlab command (gitlab-ctl renew-le-certs) but it doesn’t renew, here is the ouput I get :

Starting Chef Client, version 13.6.4
resolving cookbooks for run list: ["gitlab::letsencrypt_renew"]
Synchronizing Cookbooks:
  - gitlab (0.0.1)
  - postgresql (0.1.0)
  - redis (0.1.0)
  - registry (0.1.0)
  - mattermost (0.1.0)
  - consul (0.1.0)
  - package (0.1.0)
  - gitaly (0.1.0)
  - letsencrypt (0.1.0)
  - nginx (0.1.0)
  - runit (4.3.0)
  - acme (3.1.0)
  - crond (0.1.0)
  - compat_resource (12.19.1)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 0 resources

Running handlers:
Running handlers complete
Chef Client finished, 0/0 resources updated in 11 seconds

I’m sorry I’m pretty lost with your first part of the answer

What I meant with the first part of my response is that if you have the ability to modify your nginx configuration permanently, you can do something like:

location /.well-known/acme-challenge {
    root /var/www/letsencrypt
}

Reload nginx, and then run:

mkdir -p /var/www/letsencrypt && certbot renew --webroot -w /var/www/letsencrypt

However, I suggested that before I realized that GitLab has a first-party integration for Let’s Encrypt. It would be much better if you could use that instead. But if you’re having trouble with that feature, I think you should go get help from the GitLab community instead. It’s unlikely that somebody here would be able to understand and solve your GitLab-specific problem.

Thank you for the reply i’ll try to get an answer on their community

I can also share the output of netstat -plnt:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:9100          0.0.0.0:*               LISTEN      26388/node_exporter
tcp        0      0 127.0.0.1:9229          0.0.0.0:*               LISTEN      26385/gitlab-workho
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      6315/unicorn master
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      745/nginx: master p
tcp        0      0 127.0.0.1:9168          0.0.0.0:*               LISTEN      26392/puma 3.12.0 (
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      22430/sidekiq 5.2.5
tcp        0      0 127.0.0.1:9236          0.0.0.0:*               LISTEN      26465/gitaly
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3158/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      3045/master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      745/nginx: master p
tcp        0      0 0.0.0.0:8060            0.0.0.0:*               LISTEN      745/nginx: master p
tcp        0      0 127.0.0.1:9121          0.0.0.0:*               LISTEN      26394/redis_exporte
tcp        0      0 127.0.0.1:9090          0.0.0.0:*               LISTEN      29847/prometheus
tcp        0      0 127.0.0.1:9187          0.0.0.0:*               LISTEN      26403/postgres_expo
tcp        0      0 127.0.0.1:9093          0.0.0.0:*               LISTEN      26383/alertmanager
tcp6       0      0 :::9094                 :::*                    LISTEN      26383/alertmanager
tcp6       0      0 ::1:9168                :::*                    LISTEN      26392/puma 3.12.0 (
tcp6       0      0 :::22                   :::*                    LISTEN      3158/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      3045/master

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