PKI, certificates & ACME
A public key infrastructure (PKI) is the system that decides which keys a business trusts: certificate authorities (CAs) that sign certificates, rules for who may get one, and a way to revoke them. It sits under HTTPS, VPNs, Wi-Fi with 802.1X, mutual TLS between services, code signing and S/MIME mail. We build internal CAs with an offline root and online issuing CAs, certificate templates that match real roles, and revocation that actually gets checked.
What we do
- Internal CA design with offline root and issuing tiers
- ACME automation for web, mail and appliance certificates
- cert-manager and mTLS for Kubernetes services
- Certificate templates and 802.1X device certificates
- HSM and TPM key protection plans
- Expiry inventory, alerting and renewal ownership
- Preparation for 200, 100 and 47-day public certificates
- CA recovery and key-ceremony documentation
Manual certificate renewal does not survive shorter lifetimes. The ACME protocol (RFC 8555) automates domain validation and issuance, and tools such as cert-manager on Kubernetes, step-ca, Vault's PKI engine and Microsoft Active Directory Certificate Services (AD CS) put it to work. The CA/Browser Forum Baseline Requirements cut the maximum validity of public TLS certificates to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, with domain-validation reuse shrinking alongside. Anything still renewed by hand needs an owner and a timer now.
Private keys deserve hardware: hardware security modules (HSMs) reached through the PKCS #11 interface keep CA keys non-exportable, and AD CS can attest that a key lives in a TPM. We inventory every certificate, put expiry alerts in monitoring, plan algorithm agility for the post-quantum change and document recovery so a lost CA is an exercise, not a disaster. This works alongside our key-management and identity practices.
Leading platforms we work with
- Smallstep step-ca
- Microsoft Active Directory Certificate Services
- HashiCorp Vault PKI
- IETF ACME
- EJBCA
- cert-manager
- DigiCert
- Sectigo
- Let's Encrypt
- Venafi
Platforms and practices
- Offline root and online issuing CAs
- Certificate templates and auto-enrollment
- ACME clients and servers (RFC 8555)
- cert-manager on Kubernetes
- SCEP and network device enrollment
- OCSP and CRL design
- HSMs and PKCS #11
- TPM key attestation
- Short-lived certificates and mTLS
- CA/Browser Forum lifetime schedule
- Certificate inventory and expiry monitoring
References
- RFC 8555: ACME
- CA/Browser Forum: TLS Baseline Requirements
- Smallstep step-ca documentation
- Microsoft: Active Directory Certificate Services overview
- HashiCorp Vault: PKI secrets engine
- OASIS PKCS #11 Base Specification v3.0
- Wikipedia: Hardware security module
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use PKI, certificates & ACME for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreManaged IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhy do public TLS certificates now need automated renewal?
The CA/Browser Forum Baseline Requirements cut the maximum validity of public TLS certificates to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. At those lifetimes, manual renewal fails sooner or later. We automate it with ACME (RFC 8555) and give every certificate an owner.
Do we need our own certificate authority?
Often yes, for internal services, VPNs, Wi-Fi with 802.1X and mutual TLS between systems, where public certificates do not fit. We build an offline root with online issuing CAs and templates that match real roles. Public websites should keep using a public CA. We advise on which is which.
Where should CA private keys be stored?
In hardware. A hardware security module reached through PKCS #11 keeps CA keys non-exportable, and Active Directory Certificate Services can attest that a key lives in a TPM. The offline root stays powered down except when it signs. We document how to recover a lost CA before one is ever lost.
How do you stop certificates from expiring unnoticed?
We inventory every certificate, assign an owner, and send expiry alerts into your monitoring system. Renewal is automated wherever the protocol allows it, such as ACME or auto-enrollment. Anything still renewed by hand gets a timer and a named person, because an unnoticed expiry is an outage.
Is revocation actually checked?
Only if it is designed to be. We plan OCSP and certificate revocation list (CRL) publishing so that clients can reach them, test what happens when they cannot, and use short-lived certificates where that removes the need. Revocation that nothing checks gives a false sense of security.
Does this prepare us for post-quantum certificates?
It is the starting point. We plan algorithm agility so that moving to new algorithms is a configuration change, not a rebuild. Active Directory Certificate Services can already issue ML-DSA certificates, but chains and hardware support lag key agreement, so we test before we deploy anything in production.