I own a domain I bought a few months back which is managed by CloudFlare’s service in DNS-only mode. As I intended to only use CloudFlare’s DNS service, I disabled every option except the DNS related features. This is what Cloudflare calls DNS-only mode. For a few months now, CloudFlare has been entrusted with my Domain’s DNS records. The DNS entries are controlled by me via the CloudFlare web interface. That is at least what I thought at the time.
Unauthorized certificate issued by Comodo
After hearing about the Certificate Transparency project and while trying to understand it and its search engines, I stumbled across crt.sh provided by Comodo.
You can imagine my surprise when I found out that my recently bought domain shows very recently issued certificates. As I never issued any certificates during the time that I have owned the domain, I was very concerned to see a certificate issued by “COMODO CA Limited” just a few weeks ago.
A quick look inside the unauthorized Comodo certificates revealed that they were issued for the CN (Common Name) “csni241244.cloudflaressl.com”. These certificates were wildcard certificates for a number of domains.
Request for a Statement from CloudFlare
As the CN points to CloudFlare, I got in contact with their support to find out why certificates were issued without my knowledge and without my permission. Especially as the Cloudflare account I used to configure the DNS records for my domain was set to DNS-only mode right from the beginning, there should have been no SSL certificate issued. I requested a statement and demanded that they stop issuing certificates with my domain in them as I use Cloudflare’s account only in DNS-only mode. CloudFlare refused with the following statement:
“We automatically issue certs for domains pointing to us, even if you set SSL to ‘off’. You simply won’t see this certificate used on your site, but it will still have been issued.”
When I insisted in a second request that I disapprove and want them NOT TO ISSUE certificates any more with my domain in them (as I operate in DNS-only mode), they refused repeatedly.
“This is not something we’re able to do I’m afraid – by using CloudFlare we automatically issue certificates for a zone, since we operate as a reverse proxy and sit in front of all requests for your site, unless you’re operating in DNS-only mode.
Rest assured these are not used in any other context unless you enable SSL on your domain.”
CloudFlare as DNS provider is entrusted with many domains in the belief that the customer itself is in control of their domain and the related DNS records. By issuing these Comodo certificates, CloudFlare shows that domain owners and Cloudflare customers seem to give the full control of the domain to Cloudflare.
What is the danger of this
With CloudFlare being in control of the DNS and having a wildcard certificate without the domain owner’s knowledge would give CloudFlare the possibility to run a MITM on many, many domains without anybody noticing as the certificates are valid and issued by a trusted CA. I understand that CloudFlare offers more then DNS-only services which require the issuance of such certificates, but doing so without the consent of the user/owner is, from my perspective, very suspicious and unacceptable behaviour.
Even with the main service of Cloudflare being a MITM-like service, the settings for a DNS-only domain should be respected.
Requesting a Statement from Comodo
As the issuing CA, Comodo must have validated the ownership of the domain before
issuing the certificates. My assumption at this point is that the validation was
performed via DNS challenge. As Cloudflare does not have access to the webcontent, specially not in DNS-only mode, only the DNS verification remains. This means that Cloudflare is performing the following actions without consent from the user / account holder:
- CloudFlare manipulated the DNS records to pass the validation without any
consent from the owner/account owner - CloudFlare requests Certificates for domains where SSL options are
explicitly switched off without informing the domain owner/account owner
Comodo’s response confirmed my assumption of DNS based validation. Comodo stated as well that they do not feel responsible as the control of the domain was transferred to Cloudflare. That they create certificates without the knowledge of the domain owner seems to not be of their concern.
Comodo suggested the use of CAA DNS records to avoid Cloudflare creating further certificates in the future. Comodo pointed out in its request to use CAA records that those are only honored by very few CA’s while many DNS providers do not provide the possibility to set them.
A quick check turned out that Cloudflare does not support the CAA record type. That means, the suggested countermeasures will not work in this situation. To sum up, they do not feel responsible as they have verified that Cloudflare is in control of the domain.
Request for support from Google Certificate Transparency
Even with the certificate transparency, companies and CA’s seem to ignore any report of unauthorized issued certificates. After addressing the mailing list behind the CT log, listing the certificates in question, I got referred to another mailing list.
But as CA’s are allowed to use DNS verification like Cloudflare did to verify the “ownership” of the domain, the CT community as well as the CA does not see any fault on their end. Even the fact that Cloudflare is issuing certificates without informing the customer, seems to be of no interest to anyone in the community.
The most interesting answers I got was that they “believe” it is OK as this will “probably” be mentioned in the “Terms of Service” (TOS) or the Policies – which it is not. A different answer mentioned later, “they do state it: in a blog post from 2014. They appear to believe this is sufficient notice”. I have checked the blog article which describes the way they issue certificates (multiple domains, wildcard, …) but does not state that this is done even when in DNS-only mode.
While reading through the mailing list, it was clear that I am not the first nor the only one reporting this unexpected behaviour. The mailing list even shows mentions about Cloudflare users uploading their own certificate to their account, even in this case, CloudFlare still issues certificates without the permission of the domain owner/account owner.
Burrying something like this forced certificate issuance in an old article with possibly hundreds of others on a blog is worrying. Who knows what else is buried on this blog which should in fact be part of the TOS or the referenced policies.
Conclusion
The CA (Comodo) did nothing wrong here as they properly validated the domain to be under control of the certificate requester (CloudFlare) via DNS verification. The CT community therefore has no reason to act. So everything is fine? Personally, I think not.
It seems, according to the CT comunity, the understanding of a DNS provider is like this. “… because YOU GAVE CONTROL TO CLOUDFLARE.” As I am signing up for a DNS service, the understanding seems to be that I give up any control over my domain to the DNS provider.
Personally I think this is a step too far. When I sign-up for a web-hosting, for example, I do not give up the control of my web-content when I upload it so the provider can manipulate it as they please. The same way when signing up for a VPS, the data on it is still mine even when the VPS is technically not my server, data-center, etc.
A DNS provider in my opinion is a content provider/distribution service like a web-hosting provider. They distribute the content (web-content, DNS entries, etc) I, as the customer, provide to them. Of course, when using the full service of Cloudflare, issuing certificates is required.
As such, my understanding is that Cloudflare is acting against its own TOC and Policies. I have learned my lesson and will never use Cloudflare again. I am also disappointed about Comodo not even being willing to check Cloudflare’s issuing practice. I can only hope that Cloudflare is changing its behaviour of forcing all users, even with disabled SSL option, into certificates without their approval/consent.
Finally, a CAA record is widely unsupported and therefore out of the question to protect a domain from this sort of incident, at the moment. First, only a handful of DNS providers support such an entry and second, only a limited number of CA’s respect such an entry – So it seems like a waste of time at the moment. I can only suggest to every owner of a website/domain to keep an eye on the CT lists for certificates that were not authorized.
The following CT search engines can be used to find issued certificates:
You can even use a service like Cert Spotter from SSLMate to monitor the CT logs for new certificates matching your domain.
I will follow the developments on this and when I get the possibility to issue CAA records, I will definitely set them. The success of such CAA resource record might be a different story but might be better than nothing.
Read more of my posts on my blog at https://blog.tinned-software.net/.
Thanks Spencer for contacting me with some very interesting details about the CAA records mentioned in the Article. Below are the details and some thoughts about the CAA records.
I checked the RFC and indeed, both listed authors seem to be from Comodo at the time of writing the RFC.
Internet Engineering Task Force (IETF) P. Hallam-Baker Request for Comments: 6844 Comodo Group, Inc. Category: Standards Track R. Stradling ISSN: 2070-1721 Comodo CA, Ltd. January 2013I found an description of the DNS Certification Authority Authorization and its current state. The so called “CA/Browser Forum”, where Comodo is a member, voted for the CAA in Ballot 125 from 2014-10-14. In this vote, the decision for the CAA resource record was made.
In March 2017 the CA/Browser Forum voted (Ballot 187 from 2017-05-08) to make CAA mandatory. As of this, beginning with September 2017 (six months after the vote), all CAs should honor the CAA records.
Interestingly, in the list of exceptions is the following point:
So, if the CA is also in charge of the domain’s DNS, or one of their affiliates, they can skip the check of CAA records set by the domain owner. So if Cloudflare would allow CAA records and Comodo would have a contractual partnership (an affiliation), they are allowed to ignore the CAA records. Personally, I think these exceptions make the whole concept of CAA records not completely useless, but at least not trustworthy, as you never know if the CAA records will be checked or not.
Additionally, as Spencer mentioned, the CAA records as such do not avoid unauthorized creation of certificates at all. They might make it a bit harder to achieve it as they have to be from the same CA, but as I understood the CAA specification, anyone who is able to successfully validate a domain with a CA could simply request the certificate from the CA listed in the CAA record.
Again, a big thank you to Spencer for the detailed insight which pointed me in this direction.