How to obtain the public fullchain for a domain from Certificate Transparency (CT) Logs

Is there a reliable way to obtain the most recent full chain (these are all publicly available certificates), for my (or any) domain, from CT Logs?

As far as I can tell from the documentation, certbot will not automatically resort to just updating the public material if there is no need to renew and therefore no need to actually perform an ACME challenge.

The reason I ask is this: For reasons I won't get into, I need to distribute certificates to some backend servers. The certificate management and renewal is centralized in a single public server running certbot. The private key is kept through most renewals and rolled over less frequently (which makes it feasible to copy the private key over manually). But the public material still needs to be updated, because of the signature and other possible occasional changes up the trust chain. So, currently, I have scripts which periodically copy the certificates via SSH after renewal.

However, this is public information and I would prefer not to keep this SSH venue open just to be able to update the public certificates on the backend servers every three months. So, is there an API or some other reliable method for me to query Let's Encrypt CT Logs and obtain the most recent public fullchain cert for a domain?

1 Like

I'm not sure I follow..

You're talking about not doing something every three months. I assume the certificate is being issued by that central server and you don't want to retrieve the newly issued certificate using SSH, but use CT logs, as long as the private key is kept the same?

Well, Let's Encrypt does log the certs to different certificate logs. I'm not sure if there is a guarantee you can find it at "CT log X" or "CT log Y", I think it's not set in stone which logs are used.

Maybe LE always pushes the certs to their own logs? See Certificate Transparency (CT) Logs - Let's Encrypt for more info about those.

3 Likes

Well, yes. That's the gist of it. My concern is not really about having to do it every three months. It's currently automated anyway. My concern is having an additional system user with SSH access to the central server just for the purpose of distributing these certificates. I wouldn't mind doing it manually with admin access when the private key rolls over every year, so that I could close this extra point of entry into the server.

I actually already knew about Oak, but was not able to find documentation on the API. Only now I realize that it is all documented in RFC 6962. Ops, my bad! Sorry. :sweat_smile:

1 Like

You can always pull the certificate chain instead of pushing it. This way you don't have to keep that SSH user open.

3 Likes

That's a good point! Surely better than grappling with CT Logs.

1 Like

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