i know this is maybe a little bit off topic but i think that the implications are interesting for this ca too.
I am neither the owner of the domain “rsajeey.info” nor do i have any contact to the owner.
What make it interesting for here are two things.
CloudFlare build an Certificate that domain and even (CN=sni181034.cloudflaressl.com , Serial 00:83:7F:6C:15:31:6D:77:B1:98:26:15:54:3B:C1:98:61) even the domain was miss-configured that it point to my server.
-> This raise for me the question how could the owner of this domain prove that he have control over that domain?
I secured my side with “Content-Security-Policy” that deny http access , inline style or script. Now cloudflare translate the query into an http request and modify the page content.
-> This is an classical “Man In the Middle” use-case.
Now the question:
Since i am neither owner nor did i have access to the DNS-Server. It would be possible the get an LetsEncrypt Certificate for this domain, because i can place the requested challenge into the server.
So what i think there should be always an email notification went to the domain owner (based on the whois record). Since i know this is bad for dyndns the mail should contain an option to disable the notification for that domain.
There are a number of BR-compliant domain validation methods that do not require control over the IP address behind a domain. Since CloudFlare controls the authoritative DNS servers for that domain, they might just use a DNS-based mechanism similar to DNS-01 behind the scenes.
I’m not sure if automatic email notification without any kind of opt-in is viable. A better approach would probably be for domain owners to use a Certificate Transparency Monitor such as CT Advisor. A number of CAs offer similar services.
Although I do not think it is likely that this was intentional, under CA/B policies nothing forbids the legitimate owner of rsajeey.info (let’s call this person Steven, for convenience) from deciding it will be fun to show the exact contents of your site on their site ( a site for which they are entitled to ask for a certificate). They could do this before, or after, receiving the certificate, and by a wide variety of methods although simply proxying all HTTP requests to you is one of the simplest.
In law, if you were quite outraged by this (i sense you are in fact only a little annoyed, but mostly intrigued as to how it happens) and thought Steven had done it on purpose to trick people, you could have a claim of Reverse Passing Off. However in this actual example I cannot imagine this would succeed as you must show Steven intended to convince other people that this was Steven’s work, and I think it’s obvious instead there is some sort of mistake.
@pfg i think the problem with opt-in of mail notification is no problem.
You can include in the LE policy that the domain owner accept an email notification for his domain,
that after the first mail can be turned of. Since it is for security and not advertising i know in germany it
is no problem an i can not think there any where else it would cause an problem. Because
a) The owner use LE and had accept this notification
b) LE was missused by someone and the owner should be informed about this.
The CT-Advisor or any Certificate Transparency Monitor imply that the owner know about the problem
that there could be an misused certificate for his domain. It is the same problem as with the CAA record.
Let se if from an point more in the real world. If someone use your Address to order goods and say
i want order it in Name X with Address X but deliver the goods to Address Y, anyone would be annoyed
if you do not check that Name X authorize it. If you deliver it to Address Y and some time later because of payment problem contact X he could blame that you did id by own risk. And this would not even change if you say we have an dictionary where you can check if we have you as contact in your database.
I do not have an problem with it. Because i see the domain name in the server request from cloudsource there would be no problem to block the request.
Since i use Content-Security-Policy the delivered page is rendered unusable because cloudfare modify the content.
I am not sure if in can use HSTS and KeyPin in the meta tag but even without it i could damage the domain if i would be pissed.
Steps:
a) set valid PIN and preload hsts header
b) register the domain for preloading
c) define an really long pin time and limit the key to the exact cloudflare certificate.
Or even worse ad for these requests massive advertisings or even worse things.
Than the real domain owner would have the problem.
No my only point is that i was interested how it could haven that an certificate is created even if the domain
is not under the control of the owner.
Then the question is why does your server serve any content for a domain it doesn't know? One explicitly does not serve requests with unknown Host: headers because it allows exactly that: random people pointing their domain into your server and claming your content as their own. It's basic HTTP server configuration best practice.
The server is protected against framing (HTTP-Headers). In this case someone could use part of the content and make it look like it is his own content. This is not wished.
If someone point the domain record to my side, from my perspective it is the other way round.
It looks like i own this domain. And none would think that the content is owned by another person who
is “technical” only in charge of the dns record.
For example i can prove in google that i am “domain owner” that mean:
Get Access to click and search statistik.
Block the domain out of the google index.
Get valid certificates for that domain
Can decide what content i like to present.
(Include the text “The domain owner is to stupid to setup the DNS correctly”
On the other hand this allows me to easy intercept any traffic from my mobile device only by changing the hosts entry in the phone. So it was not setup accidentally like this, it was by full purpose.
If someone points DNS records to your site, your server will see requests with header Host: $otherdomain. Simply don’t serve those. Don’t put your webroot in a wildcard vhost or on the plain IP address. Always be explicit about which vhost is allowed on your server.
