Hello,
I use LE using both my cPanel server app and Cloudflare.
Today I got a CF Certificate Transparency email stating a new cert was produced by LE, for my domain, but checking both my CP app and CF - it is not used by either... hence - suspicious...
I checked the transparency log at https://crt.sh/ and indeed - there is such cert.
What can I do to trace back who asked for it? (at least source IP of the request action)
How can I revoke it?
Thanks
It's very likely Cloudflare. They do request certificates for you when your name is pointed to them, and may be just having it in reserve rather than currently deployed. And yes, it's very confusing because then they send you a notification that a new cert was issued without telling you that they're the ones who asked for it.
Thanks @petercooperjr .
I checked, before posting the above, the certs at CF for the relevant domain.
They present two - the active cert and a backup cert - none was matching the issue cert.
Also, they do send emails to alert when they begin working on a new cert (although it is cryptic and not mentioning the domain's name, but rather a cryptic using a zone code, a long random looking string).
I will ask them anyway.
But in a general note - why doesn't the log transparency doesn't show at least the source IP of the request for the cert?
Not to mention the ability to limit such request only from specific source IP/IPs/IP range(s), say using a DNS record field-value pair
Well, not all certificates are done though ACME with a clear "source ip", and it can be hard to balance the privacy needs (as you could be requesting from your home system and then deploying to a server). The CT logs are more about people verifying that the CAs are signing things correctly, and it'd be hard for anyone else to really know if the data was meaningful.
You can limit Let's Encrypt to a specific ACME account with CAA, though of course your CAA records are really in the control of your DNS provider, and I believe Cloudflare will add a CAA entry if needed for themselves (if they host your DNS) to issue certificates to manage the services you use them for.
Thank you @petercooperjr .
I really think the industry needs to come up with a way to enable domain owners to limit the sources of cert request using the request's source address.
And really, let's assume a similar case like mine, but if CF is not involved - what methods and/or tools do I have to learn about such possibly malicious cert?
I don't really disagree, and I can see the appeal. But the industry I think is moving more toward cryptographic identity, so if you have a DNSSEC-signed CAA record with the account identifier (which is tied to a public key), then you've got a pretty good assurance that it's the intended entity requesting the certificate. I mean, to some extent the whole reason we use TLS certificates in the first place is that IPs can be spoofed and BGP hijacked and so forth, so IP addresses in and of themselves may not be reliable.
So Certificate Transparency does tell you what certificates have been issued, and there are several tools to help one look through it. And if you're sure a certificate was issued by Let's Encrypt that shouldn't have been, you could revoke it (see the "Using a different authorized account" section).
Thank you very much @petercooperjr !
Well, it isn't much, this also needs improvement, as I practically have no way to investigate what led to the creation of a possible rogue cert.
Thanks again Peter, you were very helpful!
Contact Cloudflare. This is almost definitely due to Cloudflare. While Cloudflare may make some things they do visible to you, they do not make everything they do visible to you. They are constantly updating and changing their systems. Their "universal" and "backup" certificates are also staggered and without any user viewable history, so it's possible the certificate you are looking at is still one of theirs.
The next step you do should be asking Cloudflare's customer service to inspect this. You can also publicly ask them on whatever social networks people use for customer support and vendor embarrassment these days.
While it is still entirely possible that this is due to a third party system or rogue/malicious actor, this is almost definitely caused by the Cloudflare systems.
I keep saying "Cloudflare", because they have been the cause of so many issues here due to their misinformation and misdirection. If you are having any sort of question or concern with a domain on Cloudflare, they absolutely need to be your primary point for inquiry. They are not just controlling your traffic, but also your DNS.
Option A) This is a legit certificate that Cloudflare has not properly informed you about.
Option B) If this is a rogue certificate, Cloudflare controls both your DNS records and web traffic. The certificate was either issued because a rogue actor can manipulate your CF account, or has root access to the webserver your CF account points to. If your server is not compromised, the breech would have to be on the DNS/HTTP traffic that cloudflare controls.
Going beyond what @petercooperjr noted (only a subset of requests are from ACME and/or have an IP), the transparency logs just track the certificates – not the metadata about the certificate issuance. While I agree that would be a very useful addition, it does come along with both a large set of concerns and would be a fundamental shift to what these systems track and how they operate. Stashing some of this metadata into a certificate would help mitigate some of this, but we still have larger filesizes on the certificates, which brings up other concerns.
Thank you @jvanasco .
I opened a ticket at CF's support about this.
I hear and feel your pain about CF...
Of course, any change you make has plus and minus sides to it, but todays, cert issuance is too open to my taste.
Ideally It should be a combination of source IP validation (wan manipulation is something that I guess is not possible by most of the common attackers) and cryptography validation (request allowed only by presenting client certs to the CA?).
Today's situation needs to be improved promptly.
We basically already have that, though. The authentication needs to be from the IP of the authoritative DNS server for the domain name, or the IP that that DNS server returns for the A/AAAA record. And the cryptographic part can be added through DNSSEC-signing the zone, and by having a CAA record that restricts to a specific ACME account URI (which is basically just a name for a public key).
Of course if you're delegating the DNS server to someone else, then they're the ones actually in control of the name, so they can fulfill all of those requirements.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.