To recap that: Several popular CDNs or bulk virtual hosts let you type in any hostname and say you're going to host it with them. They figured that if the people who really own that name don't agree, they just wouldn't point their DNS records to the relevant servers and so it's fine. Let's Encrypt's tls-sni family of validations do a DNS lookup for the name to be validated, but then request SNI for a different invalid hostname as a signal. If a CDN or bulk host used for say, example.com allowed another customer on their service to say they wanted the invalid hostname as their "real" name, they could pass the tls-sni validation for example.com and get a certificate issued.
Naively we often assume that it's OK to let users pick names in a service without taking any step to validate that the person asking is entitled to the name. We may even kid ourselves that the custom name doesn't implicitly convey any legitimacy, that @MileyCyrus might be just some 14 year old from Swansea named Miley Cyrus, that mcdonalds.com could be a family web site of the McDonald clan, or that firstname.lastname@example.org could just be some bloke who works the doors at a local nightclub. But the reality is that users think names convey meaning even if you specifically tell them otherwise.
GitLab won't be the first to get bitten by this, and they won't be the last.
I got a notification the cert was going to expire soon so I went through my usual renewal process, only to get redirected to the linked post from the new domain button immediately after deleting the custom domain. So the custom domain now 404s which is the last thing I would have wanted.
I'd strongly suggest a warning get attached to the delete domain custom domain button, or something similar, until this is fixed.
That's pretty brutal for anyone whose cert is expiring right around this time, though.
Gitlab pages only lets you add cert/key details at the point you add the domain (afaik anyway), so you need to delete it and re-add it with the renewed key. It's tedious enough, but it's really only the last step that needs to be done manually.
I really hope that GitLab will simplify this, especially with Chrome soon warning on any HTTP site.
Handling all the edge cases is extremely challenging to do so with good UX
When a customer validates ownership do they keep it forever? How long? Do you rescan for txt records? How often? Do you handle customers leaving gracefully? How do you handle new customers re-setting up their domain on a new account?
It's a big mess and it's a lot better to do what cloudfront does and give customers a unique name to CNAME to
Rest assured that when domain verification rolls out, there will be an email notification you'll receive regarding a grace period to address your required user actions prior to re-verification.
If you have any further questions about this plan, feel free to contact us directly at email@example.com
Looking over how GitLab handles setting up custom domains, it's pretty clear they were affected by that. I thought it was pretty much decided that's more a problem with the Baseline Requirements than with individual service providers like GitLab though. Mozilla even went so far as to forbid CAs from using two of the Baseline Requirement validation methods as a result of that vulnerability. Assuming the CAs comply this shouldn't be an issue anymore, right?
Or were you referring to something else?
I did something like that too, a while back. Particularly a problem for people who "retire" services without cleaning up, and who use DigitalOcean, CloudFlare, and similar services.