However, reconfiguring attempt failing by throwing following exception:
Running handlers:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[git.mydomain.ltd] (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.mydomain.ltd] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [git.sahaba.net] Validation failed, unable to request certificate
whereas hostname to IP resolves successfully through internal DNS as well as hosts file also updated with the same host info.
moreover, the /etc/gitlab/ssl/ does have all necessary certs created successfully - still failing.
Running handlers:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[git.mydomain.tld] (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.mydomain.tld] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [git.mydomain.tld] Validation failed, unable to request certificate
Strange is the http redirect is working and so do the SSL applied… then why the deployment failed in the end - any validation issue that causing this failure?
You could try to disable the HTTP to HTTPS redirect during initial certificate setup, because Lets Encrypt validation process is over HTTP http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> and I am not sure, but the redirect to HTTPS could interfere with the validation process.
Once the validation passed and you have a working setup you can enable the redirect again.
Running handlers:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[git.mydomain.ltd] (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.mydomain.ltd] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [git.mydomain.ltd] Validation failed, unable to request certificate
It looks like something blocks the traffic from Let’s Encrypt servers to your GitLab instance. Your GitLab instance must be reachable over HTTP (TCP/80) from public internet for the validation to pass.
No, you cannot skip validation with letsencrypt, even if it’s internal use only. Generate self-signed certificates, or use an internal CA for example. Letsencrypt requires a public DNS entry to be able to access your server, connect and verify to issue the certificate. And it needs to do this regularly, as certificates are only valid for 90 days, and cron jobs on the system will check regularly for this.
As per my previous message, the recommendation was generate self-signed certificate, or if you have an internal CA, then you can generate here also. If your internal domain that you are using is also the same as your commercial domain, eg: mydomain.com or whatever, then you can also purchase commercial certificate for that domain which would only require you to complete DV - domain validation - usually by receiving an email to verify you have control over it, and then once purchased, you can use that certificate on your internal server - even if the server is not publicly accessible.
There are plenty of articles on how to create self-signed certificates, or as well as configuring yourself a CA, be it on Linux or Windows. You can find these with google.
Then once generated, you put them in /etc/gitlab/ssl on your server with the files named as gitlab.mydomain.com.crt and gitlab.mydomain.com.key or whatever the URL is that you are using to access your server, and reconfigure gitlab and it’ll work with the certs, be it self-signed, CA generated or commercial purchased.
@msalmanmasood just a small addition to what @iwalker already mentioned.
You can also manage Let’s encrypt certificate manually (outside of GitLab). When you do it yourself, you can choose what validation method you want to use.
Most Linux distributions already have some package to install and manage Let’s Encrypt certificates.
So removed the letsencrypt SSL cert and key, applied the self-signed certificates by following the steps here [ 1] also commented out letsencrypt configurations and changed the parameter letsencrypt[‘enable’] = false and ran the gitlab-ctl reconfigure to apply the configurations as required.
Thanks @balonik and @iwalker for your continuous support throughout this effort here.