5

I've recently installed Gitlab CE on my Ubuntu server. My desired domain for running Gitlab is https://git.mydomain.com (This is a sample URL), so I prefered to use Lets Encrypt to enable SSL on the server. At the end of installation, I received this error: 

Running handlers:
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[git.mydomain.com] (letsencrypt::http_authorization line 5) had an error: Acme::Client::Error::Malformed: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: Acme::Client::Error::Malformed: Method not allowed

I've read many pages to find the solution, but none of them were not useful. May you help me to activate SSL on this Gitlab instance please?

Mohammad Saberi
  • 12,864
  • 27
  • 75
  • 127
  • If you are using a 12.2.x version of GitLab, you should see an update in the next few days with a fix. See my edited answer below. – VonC Dec 10 '19 at 14:58

3 Answers3

9

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 GET requests 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-GET requests 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 :: أحمد محب:

  1. delete old certificate from ssl folder
  2. install Cerbot "manually" (#sudo certbot certonly -a manual) &
    (You must make port 80 and 443 available in firewall)
  3. write your Domain name in order
  4. go to: /var/opt/gitlab/nginx/www/.well-known/acme-challenge/
    "Create file with the name that appeared"
  5. press Enter
  6. 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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you for the answer you provided. Azylog's answer did not solved the problem, but regarding to your note, it seems I have to wait for the next release of Gitlab – Mohammad Saberi Dec 10 '19 at 17:35
  • @MohammadSaberi Or simply the next GitLab minor update: you don't have to wait for the next 22nd of this month. – VonC Dec 10 '19 at 18:16
  • I updated Gitlab to 12.5.4, but the problem still exists and I got that error again while enabling https on the URL – Mohammad Saberi Dec 11 '19 at 08:28
  • @MohammadSaberi 12.5.4 was part of a critical security release batch (https://about.gitlab.com/blog/2019/12/10/critical-security-release-gitlab-12-5-4-released/) which did not yet include the backport I mention in the answer. Said backport was announced yesterday: I suspect we need to wait a few more days before the actual release. – VonC Dec 11 '19 at 08:39
  • you are right. It was my mistake... Thanks for replying my comments and question – Mohammad Saberi Dec 11 '19 at 09:12
  • After waiting for an official an minor update, and updating to version 12.6.0, the previous problem still exists! `(letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25)` – Mohammad Saberi Dec 23 '19 at 11:32
  • @MohammadSaberi OK, you might want to update the issue ticket, and let them know. – VonC Dec 23 '19 at 11:35
  • @MohammadSaberi This is supposed to be fixed with GitLab 12.6.2 (January 2020). – VonC Jan 06 '20 at 08:19
  • finally, I could activate LetsEncrypt SSL on Gitlab 12.6.4, but with disabling staging part of `certificate.rb` – Mohammad Saberi Jan 15 '20 at 14:44
  • @MohammadSaberi Thank you for this feedback.I have included your comment in the answer for more visibility. – VonC Jan 15 '20 at 14:55
6

A workaround is described in gitlab-issues:

Modify

/opt/gitlab/embedded/cookbooks/letsencrypt/resources/certificate.rb

and comment out the staging part (line 25 to 38).

Worked for me (tm).

Fredrik
  • 206
  • 1
  • 7
  • 2
    This worked for me. I was having problem running `gitlab-ctl reconfigure`, it was throwing error with letsencrypt http_authorization error. commenting out the staging part reconfigured it and I was able to upgrade gitlab-ce packages. – Tuhin Jan 29 '20 at 21:00
1

The problem which we faced is different but the error is same.

(In my case, letsencrypt certificate was expired and renew flow is broken for GitLab 12.2.5-ee.0.)

What we did is...

  • Upgrade to the latest version of Gitlab (Current stable version is: 12.7.6-ee.0 )
  • Edit the gitlab.rb
  • Remove the old certificates
  • Reconfigure the GitLab server

I wrote the detailed steps here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4900#note_292031191

Manan Shah
  • 1,042
  • 2
  • 14
  • 26