0

I am running gitlab on ubuntu 14. The previously configured cert has expired (no cron entry was setup for renewal). I am trying to setup certbot (with let's encrypt) to renew the cert and then setup the crontab entry for auto renewals. When I run certbot, I get a message copied below (is there a location where I can grab a more detailed error message):

command being run:

./certbot-auto certonly --webroot -w /opt/gitlab/ssl -d git.xyz.com

git.xyz.com is a valid domain (I replaced the actual domain with xyz). The directory /opt/gitlab/ssl exists and the user being used to run the command has read/write privileges on that directory and its contents.

Error Failed authorization procedure. git.xyz.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to git.xyz.com

IMPORTANT NOTES:

- The following errors were reported by the server:

   Domain: git.xyz.com
   Type:   connection
   Detail: Could not connect to git.xyz.com

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Any thoughts on how I can debug this issue better?

forgot to mention: I can access the URL from an external network (the domain name is correct) and currently no firewall was configured to stop traffic on port 80/443 (I even shut off the firewall to test as well).

ali haider
  • 1,140
  • 3
  • 16
  • 29
  • You should do exactly what the message advises you to do. – Michael Hampton Dec 02 '16 at 19:42
  • forgot to mention: firewall was turned off, I can access the URL in a browser from an external network – ali haider Dec 02 '16 at 20:13
  • I think we'll have to look, then. [What is the domain name?](http://meta.serverfault.com/q/963/126632) – Michael Hampton Dec 02 '16 at 20:18
  • I just added a user on that gitlab instance 30 minutes ago bypassing the ssl cert alert in the browser - and no, I'm not sharing the URL – ali haider Dec 02 '16 at 20:20
  • How is the DNS set up? Does the A record exist? – gxx Dec 02 '16 at 20:25
  • the A record is setup to point to git.xyz.com - perhaps I did not explain this, the git.xyz.com (with https://) was working before the cert expired. I am trying to revive the setup - thanks – ali haider Dec 02 '16 at 20:36
  • Well, it doesn't has to mean much, that it's working for you if you're using your browser. A `CNAME` or `AAAA` record would work as well for you, whereas it wouldn't for Let's Encrypt. That's why the error message mentions a `A` record. – gxx Dec 02 '16 at 20:39
  • thanks - as per my earlier comment, the A record is pointing to git.xyz.com – ali haider Dec 02 '16 at 20:55
  • You're using web root so did you edit the GitLab NGINX configuration to serve challenges? – Ginnungagap Dec 04 '16 at 22:49

1 Answers1

1

I'm not sure if this is of any help, but at least I could imagine that this is the problem:

  • You're redirecting automatically to https if connecting via http.
  • This redirect applies to Let's Encrypt as well, so they'll get your invalid, due to the date, cert.
  • At this point the connection won't be successful, leading to the error shown to you.
  • Also, you're making use of HSTS. I'm not sure if Let's Encrypt does respect this header, if they've once seen it.

So, what to do? I'm not sure as well, but here are some hints:

  • Disable the http to https redirect, and try again.

  • If HSTS is respected:

    • Set the HSTS header to something really short, like one second, put this config in place, run the Let's Encrypt client again, so they're getting the new header, disable the redirect, wait some time, and run the client again.

    • If this doesn't work: Get a different cert, which is valid, for example issued by StartSSL, install it and try again.

For the future:

  • Set up automatic cert renewal and, additionally, put monitoring in place which at least will warn you if something like this might happen again, before it's happening.

Do something good:

  • Create a ticket or write a post into their forum / an email explaining what happened and asking if they could check for these errors, and give the people a hint (aka a better error message).

(Minor: If you don't want to make your domain public, you should remove it out of your post.)

gxx
  • 5,591
  • 2
  • 22
  • 42
  • danke - I forgot to remove the domain from the post - the post has been fixed (not the reported issue). I will go over your suggestions. – ali haider Dec 02 '16 at 21:36
  • @alihaider Did this help? – gxx Dec 04 '16 at 00:04
  • sorry for the radio silence - I had to revert to other pressing items. I will update the post when I get back to the item. Danke for sharing, accepting answer. – ali haider Dec 04 '16 at 02:58
  • Nite on the HSTS section, reducing it doesn't work since the longest period is the remembered one, new StartSSL certificates are no longer valid AFAIK, LE doesn't remember or respect the HSTS header. – Ginnungagap Dec 04 '16 at 22:53