And you can now exclude delegated sub-domains from Cert Spotter monitoring.

Last week, Mickaël Bergem published a blog post about his surprise when GitHub obtained an HTTPS certificate for his blog sub-domain, which was hosted on GitHub Pages. Bergem had not explicitly requested the certificate, and described its issuance as unpleasant.

There is no question that the certificate was legitimately issued under the rules governing publicly-trusted certificate issuance. As Bergem showed in his blog post, he had delegated the DNS for blog.securem.eu to mickaelbergem.github.io using a CNAME record. This gave GitHub technical control over blog.securem.eu, enabling them to request a certificate for the hostname using an "Agreed-Upon Change to Website" (section 3.2.2.4.6 of the Baseline Requirements).

But just because GitHub was allowed to do this, should they have? Was it OK for them to go and request a certificate for mickaelbergem.github.io without Bergem's explicit permission?

We think yes, it was completely OK. Furthermore, this practice should be encouraged and normalized.

The Web is moving to HTTPS, and in just a few months, Google Chrome is going to start labeling websites without HTTPS as "Not secure" in the address bar. If someone outsources the hosting of their website to a service such as GitHub Pages, that service has a responsibility to provide the site with HTTPS, and to do so, they must obtain a certificate. This process needs to be automatic. If it requires manual interaction with the user, such as requesting permission, it adds friction to the process of setting up a website and makes HTTPS unnecessarily more difficult compared to unencrypted HTTP. Even notifying the user that the service is about to request a certificate takes away their valuable attention that could be better spent elsewhere. And not all domain owners even know what a certificate is, nor should they need to. People outsource website operation so they don't have to concern themselves with details like the HTTP protocol, system administration, or TLS certificates.

What if you are a domain owner who operates sites yourself, but have delegated some sub-domains to third parties such as GitHub? Since you operate sites, you know what a certificate is and you're monitoring your domain for unauthorized certificates using Certificate Transparency. How should you handle your delegated sub-domains?

We think you shouldn't monitor these sub-domains. Since you're not the operator of the sub-domain, you have no way of knowing whether a certificate issued for it is legitimate. Alerts about certificates for the sub-domain would be unactionable noise. Instead, the third party operator (GitHub in this case) should monitor the sub-domain, since only they know which certificates they've requested. (Unfortunately, they won't know if you requested a certificate for the sub-domain, but this is an atypical case and could be handled by them sending you an email.)

To help domain owners with delegated sub-domains, we've rolled out a new Cert Spotter feature: you can now specify a list of sub-domains which are excluded from monitoring. We recommend you list any sub-domain which you've delegated to a third party operator. To add an excluded sub-domain, just visit your Cert Spotter Account Page and enter a sub-domain under the "Excluded Sub-Domains" section. You will no longer receive alerts for certificates issued for this sub-domain.

If you're a company which operates websites on behalf of your customers, and you want to make HTTPS easy for you and them, check out SSLMate for SaaS.