Our small IT team manages many services and devices, including internal websites, Exchange, and a large number of Ricoh, Lexmark, and Brother copiers. I'm trying to build a complete inventory of everything using TLS certificates, but I suspect we've missed some systems.
With public certificate lifetimes eventually dropping to around 47 days, I'm looking into ACME clients and automated renewal. That seems straightforward for servers and other systems that support ACME, but our printers and copiers require certificates to be manually imported and don't appear to offer useful automation APIs.
These devices are internal-only, yet our CTO currently prefers using a paid wildcard certificate for internal services. Would an internal CA or private PKI be a better approach? What certificate-management architecture and workflow should we plan for, especially for devices that cannot automate renewal?
5 Answers
For a small environment, an internal CA can be created with an established Windows PKI or another certificate-management platform. Distribute the CA root certificate through endpoint management or group policy, then issue separate certificates for internal applications and devices. You can choose a longer validity period for low-risk equipment, but build renewal and revocation procedures anyway instead of relying on certificates that last for decades.
The first step is an inventory: certificate subject and SANs, device or service owner, where the private key is stored, issuer, expiration date, and renewal method. Categorize each entry as public ACME, internal ACME, manually managed internal, or public-but-not-automatable. That gives you a realistic transition plan instead of trying to force ACME onto hardware that does not support it.
The shorter lifetime rules apply to publicly trusted certificates, not certificates issued by your own internal CA. For internal-only systems, establish a private PKI and issue certificates from it. Devices that support ACME can renew automatically, while printers and other appliances can receive longer-lived, device-specific certificates through a documented manual process. Check compliance requirements first, since some frameworks may still require shorter lifetimes or formal exceptions.
Avoid putting a wildcard private key on lots of printers and other movable devices. If that key is copied or extracted, every service using the wildcard is affected, and you may not even know where the key was installed. Prefer individual certificates per device, with names that identify the specific printer or service, and keep an inventory of them.
A practical split is: use public ACME certificates for internet-facing services, run an internal ACME service or private CA for internal servers, and use traditional private-CA certificates for hardware that cannot automate renewal. For public services that cannot run an ACME client themselves, terminate TLS on a reverse proxy or load balancer and automate renewal there. Exchange and similar platforms may need their own renewal and import procedure, so test that process before the deadlines become frequent.
Don't overlook the ACME challenge itself. DNS validation may also require frequent updates, so the certificate automation account needs controlled access to the relevant DNS zones or a delegated validation zone.
Even when a longer internal certificate is technically valid, vulnerability scanners or auditors may flag it. Make sure the exception and business justification are recorded rather than assuming the private CA makes the requirement disappear.