It's not explicitly documented -- and it's subject to change, of course -- but you can examine Let's Encrypt certificates or the CT logs themselves to see where Let's Encrypt is currently logging. They usually use most of the current, usable, high volume logs.
The only public logs Let's Encrypt currently operates are, as far as I know, testflume and oak -- the former is for testing, and the latter is currently pending approval in the Apple and Google CT programs. I'm not sure what use Let's Encrypt currently makes of either log.
What problems are you having? I just successfully logged a random certificate to the Oak 2020 shard.
Ah. Well, the first three logs in the list in your first post have "Status: Ceased"...
I have no idea why it says so many other logs -- three Oak shards, and other logs from other operators -- have ~93% uptime or are "Bad". I don't know how that monitor works, and most of the website isn't loading.
That list includes a lot of logs, with different statuses. Certainly logging to some of them is not expected to work, or may not be useful, depending on your intentions.
Ok thank but your CA must be publishing precert to a predefined log list in your issuance code
Structure
My concern is clear with your first reply where you you successfully logged a certificate in real time . Can we get a oak CTL to get near real-time log
It definitely is. Let's Encrypt's CA software, Boulder, is open source. But the CT configuration files aren't public, and I don't work for Let's Encrypt, so I don't have access to them.
I assume that's mostly so that they can flexibly change it as necessary. Adding a separate step to update the documentation would be an additional complication. And for users, the important thing is that they continue to use logs approved by Apple and Google, not preciesly which ones a given certificate uses.
Let's Encrypt staff might have more to say, but I wanted to respond with what I could.
I'm not sure I understand your question.
Do you want to know to which logs Let's Encrypt the CA submits precertificates or certificates as they're issued? If so, why? And that information can be determined by analyzing the logs themselves, though that's not really easy to do.
Do you want to know something about the logs operated by Let's Encrypt the CT log operator? If so, why? What do you want to know?
Is something going wrong?
The CT ecosystem is near real-time. Even narrowing it to web monitors, if you do a search for Let's Encrypt's current intermediate on crt.sh, you'll see precertificates that are 5-10 minutes old. Despite crt.sh being backlogged and the website using caching.
