Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key.
The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.
Although the poisoned pre-certificates† are logged as a necessary part of offering the least hassle product which is the business Let's Encrypt are in, they, like most CAs, also log the finished certificate shortly after.
Here's the pre-certificate for this web site's current certificate:
This is good practice, but it's also just easier, because if anything goes wrong, and sometimes things do go wrong, when the trust store says hey, please provide all certificates you issued with these properties, if you've logged them they are right there published in the logs for everybody to see - no bother, no risk - if you haven't then you need your own storage and better hope there aren't any mistakes. I'm sure LE do have their own copies if they needed them, but it sure is nice to know that's not what you're betting on.
† Poisoned pre-certificates are a "temporary" hack so that the certificate logging system can be demonstrated. If we ever really wanted this of course we'd develop a proper solution instead, right? Right? Every experienced software engineer knows that "temporary" usually means permanent in practice and so nobody was surprised by how this turned out.
While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list).
This means a 99% uptime on a 90 day rolling average, a 1 minute update frequency for new entries (24 hours on an older RFC). No split views, strict append-only, sharding by year, etc.
Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key.
The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.
Although the poisoned pre-certificates† are logged as a necessary part of offering the least hassle product which is the business Let's Encrypt are in, they, like most CAs, also log the finished certificate shortly after.
Here's the pre-certificate for this web site's current certificate:
https://crt.sh/?id=23696530376
and here, just a few later in the log, is the finished certificate:
https://crt.sh/?id=23696528656
This is good practice, but it's also just easier, because if anything goes wrong, and sometimes things do go wrong, when the trust store says hey, please provide all certificates you issued with these properties, if you've logged them they are right there published in the logs for everybody to see - no bother, no risk - if you haven't then you need your own storage and better hope there aren't any mistakes. I'm sure LE do have their own copies if they needed them, but it sure is nice to know that's not what you're betting on.
† Poisoned pre-certificates are a "temporary" hack so that the certificate logging system can be demonstrated. If we ever really wanted this of course we'd develop a proper solution instead, right? Right? Every experienced software engineer knows that "temporary" usually means permanent in practice and so nobody was surprised by how this turned out.
3 replies →
Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.
Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json
While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list).
This means a 99% uptime on a 90 day rolling average, a 1 minute update frequency for new entries (24 hours on an older RFC). No split views, strict append-only, sharding by year, etc.
I think OP's original idea would work.
2 replies →