Add certificate transparency monitoring service to Let's Encrypt


#1

I am making myself familiar with certificate transparency, a system to monitor all issues certificates. It is supposed to help identify rogue certificates. But like no flaws in open source software are found unless someone looks for them, it is important for domain owners to look through all issued certificates to spot oddities. There are several services that allow people to enable certificate transparency monitoring for their domain, however since this is an additional measure people have to do, I assume most domains won’t be monitored. When wondering about how to improve it, I had the idea that it would be a good service for a certificate authority to check certificate transparency for certificates issued by other CAs for domains in certificates issued for their customers. Since Let’s Encrypt is a innovative CA, I was wondering if you would consider adding support to Let’s Encrypt to notify your users if other CAs issue certificates for the same domains that you issued certificates for.

Update:
It appears that someone else at the certificate transparency working group also sees CAs as an important certificate transparency monitor:

"A CA might performing monitoring on behalf of the Subjects to which it issue certificates, an important example of third-party monitoring."
https://trac.ietf.org/trac/trans/ticket/39#comment:6


#2

What’s wrong with crt.sh? Granted, that’s Commodo, but still, it is a very functional service referenced from LE’s own docs.

Also, I’d be much obliged if you toned down the persuasive language a little.


#3

For Let’s Encrypt, I think the more important thing would be getting to the point where SCTs are included as part of the certificate (a WIP which is almost complete, I think?) to meet Chrome’s upcoming certificate transparency requirement. Although I do agree with @till that new CT monitors would be great if implemented automatically as part of Let’s Encrypt (or other CAs for that matter), the resources to do so are probably best allocated elsewhere right now. As @Ersatz mentioned, there’s already crt.sh and a plethora of others, some with automated email notifications (such as https://sslmate.com/certspotter and https://www.digicert.com/certcentral/certificate-monitoring.htm).


#4

And there is also https://www.google.com/transparencyreport/https/ct/?hl=en which @serverco pointed out to me in another thread.


#5

Sorry for the late reply. I made a mistake with my e-mail filter and missed the notifications about the answers.

crt.sh is a useful tool but it is also an opt-in service therefore only domain owners benefit from it who actively use it. And other service providers cannot know if a domain owner issued a certificate or if it is the result from an attack. But the CA that issues certificates properly to the domain owner knows that certificates from other CAs are more likely fraud certificates and could therefore notify the domain owner without triggering too many false warnings.


#6

Do they, now? The namesake website to this forum handle was listed as a SAN on a Let’s Encrypt cert for my development server, however soon after I enabled cloudflare, and their cert was also issued to me. I still use the LE cert to communicate between my backend server and cloudflare, while their cert is shown to browsers.

Now, I could of course use the cert they issue me, but since it doesn’t have the same trust chain as the LE cert, it would cause more headaches than necessary should I want to turn off cloudflare proxying in the first place. My setup works for me, and as a responsible domain owner I know to check services like crt.sh and google’s certificate transparency.

Irresponsible domain owners won’t care even if you send a carrier pidgeon to their doorstep and threaten their family if you don’t fix the rogue certs.


#7

Of course you can always construct or show extreme examples where it does not help. Nevertheless your use case is not the typical one. And if you argue that responsible domain owners can already check their certs manually, then I ask, why does Let’s Encrypt exist? Responsible domain owners could get cheap or free certificates even before Let’s Encrypt existed. The big change is that Let’s Encrypt made it easier to get certificates and configure servers properly. Therefore it is logical for me that Let’s Encrypt should also favor making it easier to use certificate transparency instead of telling that there are more complicated ways to achieve the same. And the world is not as black and white as you suggest, there are not only responsible domain owners who implement every available security feature and irresponsible domain owners who do nothing. Or in your example they would be responsible enough to use Let’s Encrypt but would not care about rogue certs? It is a strange idea to me. I would assume that irresponsible domain owners do just not use encryption…


#8

I would personally like to see this as a service from someone else other than the CA.

One of the exciting things about Certificate Transparency is how it can help in the case when a CA has been hacked, when it has a malicious insider, or when a government tries to force it to issue a fraudulent certificate. In these cases the CA might not be prepared to tell people about the problem, but CT can still reveal what has happened.

For these cases, someone independent from the CA would probably be best-positioned to notice and publicize the problem, because the independent party will presumably not be subject to the same problems that facilitated the misissuance in the first place.

I would also agree that CAs should not consider other CAs’ issuance likely to be malicious, as the web PKI explicitly allows certificates from several different CAs with overlapping subject coverage and validity to coexist, and we’ve seen a number of cases where people do this intentionally. For example, I saw one site where a web developer got a Let’s Encrypt cert for testing purposes while initially rolling out HTTPS, and then switched to a different paid certificate for the public deployment. We’ve also seen overlapping validity when people use a CDN like CloudFlare, where they may have a Let’s Encrypt cert for their origin server and a different cert for the CDN service. Because of cases like this I don’t think we can make a presumption that overlapping issuance is malicious or even suspicious.

But, I agree that it would be valuable for more domain registrants and sysadmins to be able to get notifications about all certificate issuance for their domains. Most of the time, I think conflicts of interest and single points of failure can probably best be minimized by having these notifications come from someone other than a CA.


Certificate transparency (CT) monitoring for Let's Encrypt certificates
#9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.