Our small organization has many services using TLS certificates, including internal applications, servers, and networked copiers from vendors such as Ricoh, Lexmark, and Brother. I am trying to build a complete inventory, but I know some certificates are probably being overlooked.nnMost of our internal devices require certificates to be manually imported, and they do not appear to support ACME or an API for automated installation. Our CTO currently prefers using a paid wildcard certificate for internal services, although I am wondering whether an internal certificate authority would be safer and more practical.nnWith public certificate lifetimes expected to become much shorter, I would like to understand the normal workflow. Which systems should use a public ACME client, which should use an internal PKI, and what is the best approach for devices that require manual certificate installation? Are there additional concerns around DNS validation, wildcard certificates, Exchange, or compliance that I should plan for?
5 Answers
Do not overlook DNS validation. Public ACME automation often depends on regularly updating DNS TXT records, so the certificate-management system needs controlled access to the relevant DNS zones. Also inventory special cases such as Exchange, since some products require their own certificate-import or binding steps even when certificate issuance is automated.
A practical internal setup can combine Windows PKI or another private CA with an internal ACME service. Servers and applications that support ACME renew automatically, while printers and older appliances receive individually issued certificates through a documented manual process. Make sure endpoints trust the private CA chain, and test CA and intermediate-certificate rotation before it becomes urgent.
For a public service that needs a certificate but cannot perform ACME itself, terminate TLS on a reverse proxy or load balancer. Automate the public certificate renewal there, then use a separate certificate between the proxy and the backend. This keeps the short-lived public certificate away from the appliance that cannot be automated.
Avoid putting one wildcard private key on lots of devices. If that key is copied or a printer is stolen, every service using the wildcard may need to be replaced. For internal devices, issue individual certificates from a private CA and maintain an inventory of where each one is installed. If manual replacement is unavoidable, choose a reasonable lifetime and track renewal dates rather than relying on a single shared wildcard.
Separate public and internal certificate management. Public-facing services that support ACME should use it for automated issuance and renewal. For internal-only systems, an internal CA is usually the better fit, especially for printers and appliances that cannot run an ACME client or expose an API. The shortened lifetimes apply to publicly trusted certificates; an internal CA can use different lifetimes, subject to your security and compliance requirements.
Compliance can still affect the choice. Some vulnerability-management tools or auditors may flag long-lived certificates, so document the exception and confirm what your regulatory requirements actually demand.