Cool, since I switched to Let’s Encrypt a long while ago, I missed that various tools now require TLS expiration be no longer than 398 days away (and preferably even 397 days).
It equals one leap year + one month + “a little room to handle the messiness of dates.”
then posts a lot of quotes from references to the history on how that reason came to be. I have archived and listed the links below.
Most of the discussion was during a very hectic time in life: after a single sided bad accident my mentally retarded brother was in and assisting him during his recovery period, I developed cancer and had extensive treatments against it. All the more reason for missing all this:
Though in practice there still are a few sites not having HTTPS (usually old blogs, sometimes old forums too), almost all have (thanks Let’s Encrypt!) and many not even support HTTP any more.
provides way more granular control over permissions
allows a hierarchy of repositories on which you can specify that permission control
Already 2. and 3. combined are a huge advantage, though we will see that 3. also makes some of the subcases (hosting as user.gitlab.io from account gitlab.com/user where user is your username) is harder than the similar user.github.io, github.com/user combo.
So here we go, starting with a similar set of links:
page projects as or under wiert.gitlab.io (like wiert.gitlab.io/wiert)
a gitlabstatus.wiert.me plain html (or maybe markdown) page project that eventually will show some status information (kind of like status.gitlab.com, but for different things).
The beauty of GitLab is that it supports hierarchies of repositories through groups and subgroups, so I already had these subgroups hoping they would cover both the first and second kind of page projects:
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Now I got in a confusing situation as the page indicated “There are currently no pipelines.”, but an enabled blue “Run pipeline” button:
By default there is no CI/CD pipeline, but there is an enabled blue “Run pipeline” button: confusing.
Clicked the “Run pipeline” button nonetheless, and that created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job and deployed the page.
Warning: When using Pages under the general domain of a GitLab instance (gitlab.io), you cannot use HTTPS with sub-subdomains.
The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io
For wiert.gitlab.io/wiert, try B (failed, and therefore interesting to understand why):
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
If a user wiert exists and occupies gitlab.com/wiert, then a group named wiert cannot occupy gitlab.com/wiert, and therefore a project named wiert within that group won’t be deployed to wiert.gitlab.io/wiert.
Maybe this can be shortened like “if there is a user wiert, then no group named wiert cannot be used to contain a project named wiert to host as wiert.gitlab.io/wiert“.
Let’s find out!
For wiert.gitlab.io/wiert, try C (success, steps 1, 3, 4, 7 and 8 were the key ones):
Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert
The odd but cool thing is that the actual project now ended up at gitlab.com/wiert/wiert:
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io. The HTTP does not redirect to the HTTP version, as I did not tick the
☐ Force HTTPS (requires valid certificates)
For wiert.gitlab.io, try B (failed, and therefore interesting to understand why):
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
Basically the whole namespace.gitlab.io part of the documentation is a placeholder for the actual namespace that belongs to the leaf group the pages project is in (in my case wiert.me).
So this is the new DNS entry, for which I had to wait until the DNS TTL to time out and effectuate:
New DNS gitlabstatus.wiert.me CNAME record pointing to wiert.me.gitlab.io
Note that this DNS administrative interface from WordPress.com does omit the final period of the CNAME destination (officially this would be wiert.me.gitlab.io.)
After the CNAME DNS record, I also made the TXT DNS record:
New DNS TXT record for verification of gitlabstatus.wiert.me
Then I waited a little for the DNS TXT record to be saved and try the verification of the TXT record.
Even then, verification took some time. I had to click the refresh button a few times before verification succeeded:
The DNS TXT record for gitlabstatus.wiert.me finally got verified
Now I could press blue “Save Changes” button below and waited for the CNAME record DNS TTL to expire so I could check the domain and – hopefully – the TLS certificate to be requested by Let’s Encrypt:
After the gitlabstatus.wiert DNS TXT record got verified, I could save the domain information
After the old CNAME record DNS TTL expired and the new CNAME record came into effect, the domain became available as http://gitlabstatus.wiert.me/:
Waiting for gitlabstatus.wiert.me to become active
After verification, the “Domains (1)” bit changed from this:
Domain gitlabstatus.wiert.me information before verification
to this:
Domain gitlabstatus.wiert.me information after verification
Note the HTTP does not redirect to the HTTP version, as I did not tick the
☐ Force HTTPS (requires valid certificates)
In retrospect, this could have been shorter when I had done the DNS part later, which is contrary to how to do this with GitHub.
Conclusion
The conclusion seems this:
Gitlab Page repositories to be published as or under wiert.gitlab.io need to reside directly under user wiert. Having them reside under a different group like wiert or wiert.me won’t work.
Or in more generic terms:
When creating pages as user.gitlab.io you have to put your pages projects directly under your user account gitlab.com/user.
Putting them under groups or leaf groups fails, no matter if the (leaf) group is named user or otherwise.
In addition, you can add custom domains to any Gitlab repository (even one that never stated out as a GitLab Pages repository). It will work as soon as the domain DNS mapping is setup through both a CNAME mapping record and TXT verification record.
Under “Settings” -> “Pages”, add a new domain name to the repository: now it automatically becomes a GitLab Pages repository.
When adding the domain, the settings page will show both a DNS CNAME record and DNS TXT record; ensure both are applied on your primary DNS name server and replicated to all authoritative DNS name servers.
Save the new page.
Check if the page is available on the new domain you added.
Optionally under “Settings” -> “Pages” enable the “Force HTTPS (requires valid certificates)” option and save.
TLS information
Note: I saved the TLS information – including certificates here:
Certificate Checker provides an easy-to-use solution to check certificates, certificate chains, and TLS configurations. To run Certificate Checker for publicly-accessible web sites you can go to: https://certchecker.app and enter in there a URL to check.
Users can easily run Certificate Checker in an internal network to validate or troubleshoot their TLS configuration. To run it on a local network you can run the Docker image as described below. You can also build the application and deploy it on an existing server.
Sometimes it is easier to have current and public CA signed TLS certificates for internal servers than to setup and maintain an internal CA and register it on all affected browsers (including mobile phones).
For quite some time now, Chrome (think years) refuses to prompt for saving passwords whereas Firefox and Safari do prompt and save them, even for site types that it used to save passwords for in the past.
It has been annoying enough for too long now that I tried to do better than the Google searches I used back when I saw this happen first.
Yesterday and today, he is maintaining a Twitter thread on things that have broken.
Quite a few things have, including some versions of curl, on which a lot of infrastructure relies (the certificate for it got fixed later on 20120930), see:
Yes, I know the pluimers.com web server is rated B from a TLS perspective. Will be working on it, but I’m still recovering from rectum cancer treatments, and have an almost 1.5 year backlog to get through.
Let’s Encrypt has done loads of work over the past lustrum to prevent trouble like cross-signing, issuing the successor certificates, and more.
The problem is that people like you and me have refrained from keeping their clients and servers up-to-date, so some security issues will occur. Hopefully they are limited to non-functioning communication and not leaking of data.
The Wiert Corner - irregular stream of stuff 