This is not a problem which would be limited to your case.
A recent Dec. 2019 gitlab-org/gitlab issue 38255 (now gitlab-org/omnibus-gitlab issue 4900 describes the same issue, for a lot of people.
For others who may face the same problem, you should comment out all the block mentioned by @Azylog , including the acme_certificate ‘staging’ and end lines
But it’s a serious lack of conformity to the Let’s Encrypt announcements. If method is not changed to POST-as-GET before November 1st, 2020, even the production certificate won’t be issued and this workaround won’t be any use.
This is related to ACME v2 — Scheduled deprecation of unauthenticated resource GETs, active from yesterday.
After Dec 4th, unauthenticated
HTTP GETrequests to ACME v2 resource URLs will return HTTP status code of 405 “method not allowed” and a body containing a JSON problem with type “urn:ietf:params:acme:error:malformed”.
POST-as-GETrequests authenticated by a signature from an account other than the creating account will return an HTTP status code of 403 “forbidden” and a body containing a JSON problem with type “urn:ietf:params:acme:error:unauthorized”.
Note: unixcharles/acme-client 2.0.5 will use POST-as-GET, which should fix this issue.
The merge request 3782 shows the next version 12.6 of GitLab Omnibus will use acme-client 2.0.5.
This will be backported into the next releases of 12.2.x through 12.5.x
Current workaround, proposed by Ahmed Mo7eb :: أحمد محب:
- delete old certificate from ssl folder
- install Cerbot «manually» (#
sudo certbot certonly -a manual) &
(You must make port 80 and 443 available in firewall)- write your Domain name in order
- go to:
/var/opt/gitlab/nginx/www/.well-known/acme-challenge/
«Create file with the name that appeared»- press Enter
- Congratulation!
Update January 2020: this is supposed to work with GitLab 12.6.2.
No need to patch certificated.rb anymore.
The Mohammad Saberi adds in the comments (January 15th, more than a month later):
Finally, I could activate LetsEncrypt SSL on Gitlab 12.6.4, but with disabling staging part of
certificate.rb.
| type | description | stage | group | info |
|---|---|---|---|---|
|
reference |
Automatic Let’s Encrypt SSL certificates for GitLab Pages. |
Create |
Editor |
To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments |
GitLab Pages integration with Let’s Encrypt (FREE)
Introduced in GitLab 12.1.
The GitLab Pages integration with Let’s Encrypt (LE) allows you
to use LE certificates for your Pages website with custom domains
without the hassle of having to issue and update them yourself;
GitLab does it for you, out-of-the-box.
Let’s Encrypt is a free, automated, and
open source Certificate Authority.
WARNING:
This feature covers only certificates for custom domains, not the wildcard certificate required to run Pages daemon (FREE SELF). Wildcard certificate generation is tracked in this issue.
Requirements
Before you can enable automatic provisioning of an SSL certificate for your domain, make sure you have:
- Created a project in GitLab
containing your website’s source code. - Acquired a domain (
example.com) and added a DNS entry
pointing it to your Pages website. The top-level domain (.com) must be a
public suffix. - Added your domain to your Pages project
and verified your ownership. - Verified your website is up and running, accessible through your custom domain.
The GitLab integration with Let’s Encrypt is enabled and available on GitLab.com.
For self-managed GitLab instances, make sure your administrator has
enabled it.
Enabling Let’s Encrypt integration for your custom domain
Once you’ve met the requirements, enable Let’s Encrypt integration:
-
On the top bar, select Main menu > Projects and find your project.
-
On the left sidebar, select Settings > Pages.
If this path is not visible, select Deployments > Pages.
This location is part of an experiment. -
Next to the domain name, select Edit.
-
Turn on the Automatic certificate management using Let’s Encrypt toggle.
-
Select Save changes.
Once enabled, GitLab obtains a LE certificate and add it to the
associated Pages domain. GitLab also renews it automatically.
Notes:
- Issuing the certificate and updating Pages configuration
can take up to an hour.- If you already have an SSL certificate in domain settings it
continues to work until replaced by the Let’s Encrypt certificate.
Troubleshooting
Error «Something went wrong while obtaining the Let’s Encrypt certificate»
Introduced in GitLab 13.0.
If you get an error Something went wrong while obtaining the Let’s Encrypt certificate, first, make sure that your pages site is set to «Everyone» in your project’s Settings > General > Visibility. This allows the Let’s Encrypt Servers reach your pages site. Once this is confirmed, you can try obtaining the certificate again by following these steps:
-
On the top bar, select Main menu > Projects and find your project.
-
On the left sidebar, select Settings > Pages.
If this path is not visible, select Deployments > Pages.
This location is part of an experiment. -
Next to the domain name, select Edit.
-
In Verification status, select Retry verification ({retry}).
-
If you’re still getting the same error:
- Make sure you have properly set only one
CNAMEorADNS record for your domain. - Make sure your domain doesn’t have an
AAAADNS record. - If you have a
CAADNS record for your domain or any higher level domains, make sure it includesletsencrypt.org. - Make sure your domain is verified.
- Go to step 1.
- Make sure you have properly set only one
Message «GitLab is obtaining a Let’s Encrypt SSL certificate for this domain. This process can take some time. Please try again later.» hangs for more than an hour
If you’ve enabled Let’s Encrypt integration, but a certificate is absent after an hour and you see the message, «GitLab is obtaining a Let’s Encrypt SSL certificate for this domain. This process can take some time. Please try again later.», try to remove and add the domain for GitLab Pages again by following these steps:
-
On the top bar, select Main menu > Projects and find your project.
-
On the left sidebar, select Settings > Pages.
If this path is not visible, select Deployments > Pages.
This location is part of an experiment. -
Next to the domain name, select Remove.
-
Add the domain again, and verify it.
-
Enable Let’s Encrypt integration for your domain.
-
If you’re still getting the same error:
- Make sure you have properly set only one
CNAMEorADNS record for your domain. - Make sure your domain doesn’t have an
AAAADNS record. - If you have a
CAADNS record for your domain or any higher level domains, make sure it includesletsencrypt.org. - Go to step 1.
- Make sure you have properly set only one
24 Aug 2021
I moved source.small-tech.org, our self-hosted GitLab instance, to Eclips.is a few months ago and noticed today that the Let’s Encrypt certificate had failed to renew.
When I looked on the server, the outdated Let’s Encrypt certificates were in /etc/gitlab/ssl as expected but, when I looked in the GitLab configuration file (/etc/gitlab/gitlab.rb), the Let’s Encrypt integration section was entirely commented out.
Having absolutely no memory of how I created the original certificates, I tried enabling those settings and reconfiguring GitLab (sudo gitlab-ctl reconfigure) and got the following errors:
Error executing action `run` on resource 'ruby_block[create certificate for source.small-tech.org]'
RuntimeError
------------
[source.small-tech.org] Validation failed, unable to request certificate
Cookbook Trace:
---------------
/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb:111:in `block (3 levels) in class_from_file'
Error executing action `create` on resource 'acme_certificate[staging]'
RuntimeError
------------
ruby_block[create certificate for source.small-tech.org] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [source.small-tech.org] Validation failed, unable to request certificate
Cookbook Trace:
---------------
/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb:111:in `block (3 levels) in class_from_file'
Error executing action `create` on resource 'letsencrypt_certificate[source.small-tech.org]'
RuntimeError
------------
acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 26) had an error: RuntimeError: ruby_block[create certificate for source.small-tech.org] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [source.small-tech.org] Validation failed, unable to request certificate
Cookbook Trace:
---------------
/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb:111:in `block (3 levels) in class_from_file'
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[source.small-tech.org] (letsencrypt::http_authorization line 6) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 26) had an error: RuntimeError: ruby_block[create certificate for source.small-tech.org] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [source.small-tech.org] Validation failed, unable to request certificate
The fix
Going by what worked for someone else, I did the following:
-
Deleted the
/etc/gitlab/ssldirectory. -
Enabled the following two properties in
/etc/gitlab/gitlab.rbunder the Let’s Encrypt integration section:letsencrypt['enable'] = true letsencrypt['auto_renew'] = true -
Reconfigured GitLab:
sudo gitlab-ctl reconfigure
And that seemed to fix things.
Documenting it here in hopes it might help somebody else (e.g., future me) 
WildTuna
Posted on May 20, 2022
• Updated on May 21, 2022
Столкнулся недавно с проблемой обновления GitLab до версии 12.6 из-за ошибки реконфигурации, вызываемой попыткой обновления сертификата Let’s Encrypt. Так получилось, что обновление пришлось на день, когда был просрочен сертификат. Не беда! Отключаем использование сертификата в /etc/gitlab/gitlab.rb и запускаем реконфигурацию вручную:
nano /etc/gitlab/gitlab.rb
// Находим это строку и выставляем значение false
letsencrypt['enable'] = false
// Сохраняем файл и выполняем реконфигурацию
gitlab-ctl reconfigure
Enter fullscreen mode
Exit fullscreen mode
Теперь GitLab успешно применит новые параметры и сможет обновиться. После завершения обновления возвращаем использование Let’s Encrypt в /etc/gitlab/gitlab.rb, снова реконфигурируем GitLab и… снова получаем прежнюю ошибку!
Running handlers:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[git.hostname.com] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for git.lapaygroup.ru] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [git.hostname.com] Validation failed, unable to request certificate
Enter fullscreen mode
Exit fullscreen mode
Огорченный полез гуглить. Оказалось, проблема не только у меня, но четкого решения проблемы нет. После пары часов изучения баг-трекера GitLab и тщетных попыток устранить проблему мой рецепт решения был найден, и он очень простой:
- проверить, что порты 80 и 443 открыты;
- проверить домен на сайте Let’s Encrypt;
- установить параметры в /etc/gitlab/gitlab.rb:
nginx[‘redirect_http_to_https’] = true
nginx[‘redirect_http_to_https_port’] = 80
- удалить файлы проблемного сертификата из папки /etc/gitlab/ssl;
- запросить новый сертификат: gitlab-ctl renew-le-certs.
В моем случае оказался закрыт 80 порт и что-то случилось с правами на файлы сертификата в /etc/gitlab/ssl — при обновлении GitLab не мог их заменить.
Надеюсь, мой рецепт поможет решить проблему и вам!


