Public key infrastructure sits behind secure websites, private APIs, signed software and trusted devices. The certificate is the visible part. The useful system is everything around it: identity checks, keys, issuers, renewal, revocation and clear ownership.
01
The certificate expired, but the real problem started earlier
Imagine a growing services business with a public website, a customer portal and several internal APIs. The first TLS certificate was installed years ago by one developer. It renewed successfully, nobody thought about it and the business carried on.
The company then added more domains, cloud services, a staff VPN, automated deployments and integrations with suppliers. Some certificates came from a public certificate authority. Others were created internally. A few were installed manually during urgent work. Nobody kept a reliable inventory because every certificate looked like a small technical detail.
One morning an internal API certificate expires. The customer portal can no longer retrieve a case status. Staff see vague errors, customers see missing information and the team spends hours working out which connection failed.
The immediate fix is to replace the certificate. The important lesson is that the business did not really have a certificate problem. It had an ownership and lifecycle problem. Nobody could answer which certificates existed, where they were installed, who was responsible for them or how quickly one could be revoked if its private key was exposed.
That is where public key infrastructure, usually shortened to PKI, becomes useful. It turns certificates and cryptographic keys from scattered files into a governed trust system.
02
What is PKI in plain English?
NIST defines PKI as the framework used to issue, maintain and revoke public key certificates. The wider definition includes the people, policies, processes, software and infrastructure needed to administer certificates and public and private key pairs.
In plain English, PKI helps one system decide whether it should trust the digital identity presented by another system, person or device.
A certificate acts like a signed digital credential. It connects an identity, such as a website name, application or device, to a public key. A certificate authority signs that credential. A browser or another system can verify the signature and follow the certificate chain back to a trust anchor it already accepts.
PKI is therefore more than encryption. It supports three related jobs: authentication helps confirm who or what is at the other end of a connection, integrity helps reveal whether signed information has been changed and confidentiality helps establish secure communications so information cannot be read in transit by an unauthorised party.
The padlock in a browser is one familiar result. It is not proof that a website is honest or that the company behind it is well run. It means the browser has established an encrypted connection and successfully validated the certificate presented for that domain under its trust rules.
03
Public and private keys solve different parts of the problem
Public key cryptography uses a mathematically related key pair. The public key can be distributed. The private key must remain under the owner's control.
The two keys make useful operations possible without sharing the private secret. A system can verify a digital signature using the public key. In some cryptographic schemes, information encrypted for a recipient can be recovered only with the corresponding private key. Modern TLS combines asymmetric techniques with faster symmetric encryption rather than using public key cryptography for every byte of a session.
This distinction matters because people often talk about a certificate as if it were the secret. It is not. A certificate normally contains public information, including the public key, issuer, subject, validity dates and permitted uses. The private key is the sensitive asset.
If an attacker obtains a server's private key, they may be able to impersonate that server in circumstances where the certificate is still trusted. Reissuing the certificate without dealing with the exposed key is not enough. The compromised certificate must be revoked where the system supports revocation, a fresh key pair should be created and every dependent installation should be reviewed.
04
The parts of a working PKI
The terminology can make PKI feel more complicated than it is. Each component answers a practical trust question.
| Component | Practical job | Business question it answers |
|---|---|---|
| Public and private key pair | Supports signing, verification and secure key establishment | Which secret proves this identity controls the certificate? |
| Digital certificate | Binds an identity to a public key for a defined period and purpose | Which key belongs to this website, service, user or device? |
| Certificate authority | Validates a request and signs the issued certificate | Who is trusted to make that binding? |
| Registration and validation | Checks the applicant or their control of a name or resource | What evidence was required before issue? |
| Root and intermediate certificates | Form a chain from the end certificate to a trusted anchor | Can the recipient trace this certificate to an accepted issuer? |
| Revocation service | Publishes that a certificate should no longer be accepted | How is trust withdrawn before the expiry date? |
| Policies and procedures | Define permitted uses, checks, ownership and handling | What rules make the system consistent and auditable? |
| Inventory and monitoring | Records certificates, locations, owners and dates | What exists and what needs attention next? |
The certificate authority, or CA, is central. A public CA issues certificates intended to be trusted by browsers and operating systems. A private CA issues certificates for an organisation's own systems, devices or users where the organisation controls the trust stores.
Many PKIs use a hierarchy. A highly protected root CA sits at the top. One or more intermediate CAs issue certificates beneath it. Browsers and systems validate a path from the certificate they receive, through any intermediates, to a root they trust.
The root should not be used casually for day to day issuing. Separating the root from issuing intermediates limits the amount of exposure and gives the operator a way to withdraw trust from a compromised intermediate without replacing the entire trust anchor.
05
How a certificate is issued and trusted
Return to the customer portal. It needs a certificate for portal.example.com. The server or certificate management service creates a key pair and a certificate signing request. The request contains the public key and the names the certificate should cover, and it is signed to prove possession of the matching private key.
The CA validates that the requester controls the domain. For an automated public certificate, this may involve placing a specific DNS record or serving a temporary file at a known web address. Once validation succeeds, the CA signs and returns the certificate.
When a browser connects to the portal, the server presents its certificate and usually the intermediate certificates needed to build the chain. The browser checks the requested hostname, validity period, signature chain, intended key usage and other policy requirements. If those checks pass and the chain reaches a trusted root, the browser can continue establishing the secure session.
RFC 5280 defines the Internet profile for X.509 certificates, certificate revocation lists and certification path validation. Nobody running an ordinary business application needs to memorise its encoding rules. They do need to understand that trust is the result of several checks, not a green tick stored permanently inside a certificate.
The relying system also has a role. It decides which roots to trust, how strictly to enforce policy and what to do when revocation information cannot be reached. PKI does not remove trust decisions. It makes those decisions consistent and verifiable.
06
TLS is only one use of PKI
Most people first encounter certificates through HTTPS, but business software uses PKI in several other places.
Mutual TLS, usually called mTLS, allows both sides of a connection to present certificates. An API can verify the client as well as the client verifying the server. This can be valuable for service to service traffic, partner integrations and controlled machine identities.
Code signing lets a publisher sign software, scripts or packages. A recipient can verify who signed the artefact and whether it changed after signing. The signature does not prove the software is bug free. It protects the link between the publisher and the exact content that was signed.
Device certificates can identify managed laptops, industrial equipment and connected products. User certificates can support access to VPNs, WiFi and internal systems. S/MIME certificates can sign or encrypt email. Document signing can provide evidence that a document has not changed since it was signed.
The business value is not that certificates can be used everywhere. It is that different systems can rely on a shared, controlled way to issue and withdraw digital identities.
07
The certificate lifecycle is the real operational work
Every certificate has a beginning and an end. A reliable PKI covers discovery, key generation, validation, issue, deployment, monitoring, renewal, revocation and retirement.
The expiry date is deliberate. A time limit stops an old credential remaining valid forever and gives the issuer another opportunity to validate control. Shorter certificate lifetimes reduce the period in which an old certificate can be relied upon, but they also make manual handling less realistic.
This is why automation matters. Let's Encrypt describes how the ACME protocol lets a server prove control of a domain and automatically request, renew and revoke certificates. The same principle applies more widely: routine lifecycle work should be repeatable, monitored and owned, not left to calendar reminders and one person's memory.
Automation must still fail safely. A renewal job can run successfully while the new certificate is deployed to the wrong server. Monitoring should test the certificate actually presented by the live endpoint, not merely record that an automation task finished.
08
Public PKI and private PKI solve different trust problems
A public CA is appropriate when a service must be trusted by ordinary browsers, customer devices or external partners without installing a new root certificate. The CA follows public trust requirements and validates control before issuing the certificate.
A private PKI is useful when the organisation controls both the identities and the systems that must trust them. Internal services, managed devices, employee access and private mTLS connections are common examples. The organisation can define certificate profiles and automate issue around its own operational needs.
Running a private CA does not make an internal system automatically safer. It creates a sensitive trust service that needs strong key protection, access control, backup, monitoring, documented policies and a recovery plan. A private root installed widely across devices has substantial power. If it is misused or compromised, the effect can spread across everything that trusts it.
Some businesses should operate their own private PKI. Others are better served by managed platforms or cloud services. The decision depends on scale, assurance, integration requirements, available expertise and the consequences of failure. The right answer is rarely to create a self signed certificate on every server and teach every application to ignore warnings.
09
Common PKI mistakes look ordinary until something breaks
The most dangerous PKI failures are often mundane rather than mathematically interesting.
A spreadsheet inventory goes out of date. A certificate is renewed but not installed on one load balancer. The only person who knows the private CA password leaves. A wildcard private key is copied across many servers. A development certificate enters production. A private key is committed to a source code repository. Monitoring checks the website but not the API used by customers.
Another common mistake is confusing authentication with authorisation. A valid certificate can establish an identity. The application must still decide what that identity is allowed to do. A supplier's integration certificate should not grant access to every customer's records merely because the TLS handshake succeeded.
Revocation also needs a real plan. If a private key is exposed, who can request revocation? Which systems consume the revocation information? How quickly can a new certificate be deployed? What happens to devices that are offline? A policy that cannot be carried out under pressure is only paperwork.
Finally, certificate errors should not be hidden. Disabling validation or accepting any certificate may make an integration start working, but it removes the identity check PKI was there to provide. The proper repair is to fix the trust chain, hostname, time, certificate profile or deployment.
10
A sensible starting point for a growing business
Do not begin with a grand PKI transformation. Begin with visibility.
Inventory public websites, portals, APIs, VPNs, load balancers, cloud services, code signing processes and managed devices. Record the certificate issuer, names, purpose, environment, location, expiry date, renewal method and accountable owner. Include private keys and trust stores in the review without copying secrets into the inventory.
Then identify the highest consequence failures. A marketing microsite and the certificate used by a payment integration do not carry the same operational risk. Prioritise customer facing services, security controls, critical APIs and certificates whose renewal depends on manual work.
Choose one lifecycle to automate properly. That might be public TLS certificates for production web services. Make issuance repeatable, deploy through the normal release route, test the certificate presented by each live endpoint and alert the named owner well before expiry.
Once that works, extend the approach to internal services, mTLS, devices or signing where there is a clear need. Keep public and private trust boundaries understandable. Document the recovery path and practise replacing a certificate before the first real incident forces the test.
PKI works best when it becomes boring infrastructure. Identities are issued under known rules, keys are protected, certificates renew before anybody notices and compromised trust can be withdrawn without improvisation.
DanJMills helps businesses understand the application, hosting, integrations and access they are taking responsibility for. If certificates, domains and keys are scattered across an inherited system, an application takeover review can map what exists, identify immediate continuity risks and put sensible ownership around the services that must keep working.
Useful questions
Before relying on a PKI, confirm:
- Which websites, APIs, devices, users and signing processes depend on certificates?
- Is there a current inventory with purpose, location, issuer, expiry and owner?
- Where are private keys generated, stored and backed up?
- Which public and private certificate authorities are trusted, and why?
- Can each certificate be renewed and deployed without one person remembering?
- Does monitoring inspect the certificate presented by every live endpoint?
- How are expired, compromised and unused certificates revoked or retired?
- Are authentication and application authorisation treated as separate controls?
- Can a critical certificate be replaced safely during an incident?
- Who reviews certificate policy, lifecycle failures and new use cases?
