Tools has gained a new central function for receiving, storing and distributing Let’s Encrypt certificates between servers and user accounts.
Certificates that are already created with Certbot can be published to Tools after issuance or renewal. Tools validates the material, stores the PEM files privately and associates the certificate with the correct account. Certbot still handles the actual issuance process – Tools acts as the bridge for access, downloads and administration.
Certificates are collected in one place
Signed-in users can see the certificates assigned to their own account. The interface shows information such as domain names, additional included domains, status, expiry and when the certificate was last updated.
Administrators can assign owners, enable or disable certificates and manage download tokens.
External views and downloads identify certificates by UUID, so internal database IDs do not need to become public identifiers.
Download in the browser or automate it
The latest certificate bundle can be downloaded directly from Tools. A bundle can contain cert.pem, chain.pem, fullchain.pem, privkey.pem and metadata.
Servers that need to retrieve renewed certificates automatically can use the token-protected API download. The same certificate UUID can continue to be used after renewal, while the token can be rotated when necessary.
Ready-made shell and Windows/curl examples are included so another server can fetch the latest certificate without manual handling.
Renewal and import are designed to survive interruptions
Existing Certbot certificates can be imported into Tools. The import utility reports which certificates were published, queued for another attempt or skipped.
If Tools cannot be reached during publication, valid certificate material can be placed in a local retry spool instead of turning the entire renewal flow into a failure. Certbot material under /etc/letsencrypt remains the source and is not modified by the Tools bridge.
A certificate can also unlock its DNS zone
Certificate management is now connected to the DNS editor. An enabled Let’s Encrypt certificate assigned to a user can grant access to the DNS zone covered by that certificate. Wildcard domains are normalized before matching.
This means a user responsible for a certificate does not also need a separate DNS permission for the same zone just to manage it. Existing explicit DNS permissions continue to work as before.
Private key material is handled separately
Public certificate information can be displayed and used in more places, while private key material is treated as sensitive content. Download and administrative paths verify ownership and permissions before private files are released.
The result is a clearer path from Certbot to Tools and onward to the server or user that actually needs the certificate, without placing private PEM files in a public web structure.