TLS certificate doesn’t work for *.pages.gitlab.gnome.org subdomains for users with a dot in their username
Summary
Previously reported downstream as https://gitlab.gnome.org/Infrastructure/GitLab/issues/395.
If I go to https://emmanuel.fleury.pages.gitlab.gnome.org/-/glib/-/jobs/273480/artifacts/_coverage/index.html, for example, I get the following from Firefox:
Did Not Connect: Potential Security Issue
Firefox detected a potential security threat and did not continue to emmanuel.fleury.pages.gitlab.gnome.org because this web site requires a secure connection.
What can you do about it?
emmanuel.fleury.pages.gitlab.gnome.org has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.
The issue is most likely with the web site, and there is nothing you can do to resolve it. You can notify the web site’s administrator about the problem.
Web sites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for emmanuel.fleury.pages.gitlab.gnome.org. The certificate is only valid for the following names: *.bugzilla-attachments.gnome.org, *.gitlab.gnome.org, *.gnome.org, *.gnome.pages.gitlab.gnome.org, *.id.gnome.org, *.las.gnome.org, *.openshift.gnome.org, *.pages.gitlab.gnome.org Error code: SSL_ERROR_BAD_CERT_DOMAIN
TLS certificates can’t do nested wildcards, and we can’t regenerate the TLS certificate for every possible username, so GitLab needs to escape dots in usernames for pages subdomains, or similar.
Steps to reproduce
Go to https://emmanuel.fleury.pages.gitlab.gnome.org/-/glib/-/jobs/273480/artifacts/_coverage/index.html.
What is the current bug behavior?
TLS certificate error
What is the expected correct behavior?
Page loads