Q:

updating ssl cert for gitlab using certbot & lets encrypt

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).  

A:

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.)

