I’m trying for a while now to set up a Let’s Encrypt certificate for a custom domain pointing to a gitlab pages.
The settings are telling me the following:
GitLab is obtaining a Let's Encrypt SSL certificate for this domain. This process can take some time. Please try again later.
This has been the state for more than a week and this is the third time i’m doing this. The settings page is telling me the verification worked just fine so i’m kinda lost.
I’m happy for all the help i can get!
same here, just added a domain with gitlab ssl integration a couple hours ago, no problem for http://domain.com (it does have a certificate and https is working on the custom domain), but for http://www.domain.com it keeps saying it’s obtaining a certificate, although ownership was already verified
2 Likes
Same here.
https://low-tech-websites.gitlab.io/project1 is working fine (of course)
http://project1.ploumpouloum.com/ simply doesn’t work.
The site is available since two days ago …
I followed the instruction at https://gitlab.com/help/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md and everything seems to be OK …
I cannot disable SSL (it seems to be forced now).
Hi,
can you try to disable the pages and re-enable it again? Deleting the entry and re-adding the domain may also be a better option to re-trigger the let’s encrypt challenge.
If the issue persists, I’d suggest creating a new issue for gitlab.com related problems, i.e. only admins can investigate on why the pages certificate request fails or is pending.
Cheers,
Michael
Hi,
Thank you for your suggestion, I will try and keep you informed.
Thank you as well for the pointer to the right issue tracker, I found a similar issue indeed (https://gitlab.com/gitlab-com/support-forum/issues/5051)
Cheers,
Benoît
@rolandMod Where exactly did you see that status message?
I have the problem that my gitlab page is using the wrong certificate, namely the *.gitlab.io one instead of the one for my custom domain, see https://jobatech.de/. Verification worked fine, though. I also tried to remove and re-add the domain in the settings as suggested by @dnsmichi. Still no luck.
What else can I do? Where can I check the Let’s Encrypt status in the settings?
Hi,
can you share a screenshot of the settings/verification status you are seeing? Also, please add the DNS settings you did.
Cheers,
Michael
Hi @dnsmichi,
I’m having the same issue. Seems like the LetsEncrypt process is hanging. Here’s a screenshot of the Domain page:
Also, the DNS settings as requested:
Hi @skorov,
the DNS settings are not live, I cannot query them.
dig -4 volkis.com.au txt
; <<>> DiG 9.10.6 <<>> -4 volkis.com.au txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36976
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;volkis.com.au. IN TXT
;; ANSWER SECTION:
volkis.com.au. 300 IN TXT "MS=ms66340232"
volkis.com.au. 300 IN TXT "ca3-09816457cc8045ddbcf7e914b367eef6"
volkis.com.au. 300 IN TXT "v=spf1 include:spf.protection.outlook.com -all"
;; Query time: 446 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Tue Mar 24 12:09:40 CET 2020
;; MSG SIZE rcvd: 176
The nameservers for your zone are Cloudflare and the zone TTL is 86400. That might be the answer.
Cheers,
Michael
Did I misunderstand the instructions?
I was under the impression these are the correct settings:
➜ ~ dig -4 _gitlab-pages-verification-code.handbook.volkis.com.au txt
; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> -4 _gitlab-pages-verification-code.handbook.volkis.com.au txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2426
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_gitlab-pages-verification-code.handbook.volkis.com.au. IN TXT
;; ANSWER SECTION:
_gitlab-pages-verification-code.handbook.volkis.com.au. 300 IN TXT "gitlab-pages-verification-code=db0b0328b9f5088a88e867ffc29cdf65"
;; Query time: 59 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Mar 24 22:35:12 AEDT 2020
;; MSG SIZE rcvd: 159
Do I need to add a record other than the above?
It seems that the TXT record is not specified in the zone itself. Querying it directly, it leads to the result shown above. If I query the zone itself, it returns no TXT records - and this is how the mechanism works, it fetches the resource records (RRs) from the zone and checks whether the verification code is in there.
Can you share the content of your webform where it says Add Record, Cname, TXT … I am specifically interested in the Name and Content columns.
Cheers,
Michael
Good morning @dnsmichi!
Thanks for your ongoing support.
I’m a little confused by your last response. Specifically, I’ve been following this part of your docs: https://gitlab.com/help/user/project/pages/custom_domains_ssl_tls_certification/index.md#for-subdomains
… and the Domain section of the Pages settings area. Here’s the screenshot again:
Edit: I just realised the info you wanted (coffee helped)! Here’s a screenshot of the fields. I had to hack the DOM to expand the columns since Cloudflare’s UI doesn’t allow it. 
Note that my intention is to have handbook.volkis.com.au direct to the GitLab Pages site. There should be no change for volkis.com.au which currently directs to our main website hosted elsewhere.
Please let me know if you need any more info and thanks again. 
Hi,
sorry for the late response, I was in the middle of answering and waiting for some insights on the lets encrypt side.
As always, looking closely on the intention of DNS entries is required 
And now that I look at the GitLab screenshot, the domain was verified - and the Let’s Encrypt process being kicked off.
I’ve forwarded the lets encrypt not being visible problem to our engineers. If the problem still persists, please do open an issue to highlight your problem with GitLab.com and pages.
Cheers,
Michael
No problem at all!
Seems like it’s all fixed on my end. Out of curiosity, what was the problem? (Apart from DNS, which as we know, is always the problem. 
)
Thanks again for helping me out.
Honestly, I don’t know what exactly the problem was. I could imagine that there are so many Let’s encrypt requests that we again hit the rate limit from GitLab.com and the processing takes longer than the average hours. I did not ask though, I am a bit busy in my 5th week at GitLab, still onboarding
Coupled with the DNS time-to-lives and zone updates, this makes the whole process really slow. I’ve told @jmeshell about it and on the longer run, we truly want to enhance the experience
Kind regards,
Michael
It looks like we have a documentation update to change the CNAME reference in the domain to A.
This seemed to be a Let’s Encrypt issue with CNAME when creating a custom domain.
2 Likes