Public key infrastructure, known as PKI, is the system of digital certificates, trusted authorities, and cryptographic keys that makes secure communication possible across the internet. Every time your browser shows a padlock icon, a PKI system is running behind it. Every time a business signs a contract digitally, PKI is the mechanism that makes the signature verifiable. It isn't glamorous technology, but almost every secure digital interaction in Australia depends on it.
What PKI actually does
PKI solves a fundamental problem: how do you prove, over a network where you can't see anyone, that the person or server you're talking to is really who they claim to be? The answer involves two related cryptographic keys: a public key and a private key. They're generated together as a mathematically linked pair. Anything encrypted with the public key can only be decrypted with the private key, and vice versa.
Here's what that means in practice. When you connect to your bank's website, the bank's server sends you its public key wrapped inside a digital certificate. Your browser uses that key to encrypt a shared session secret. Only the bank's server, holding the matching private key, can decrypt it. From that point, your connection is private. No one sitting between you and the bank can read the traffic.
The private key is the crown jewel of the whole system. Lose it, and an attacker can impersonate you. Share it, and security collapses. PKI is largely the discipline of managing private keys carefully across organisations, devices, and time.
What a digital certificate is
A digital certificate is a small file that ties a public key to an identity. It contains the owner's name (or domain name), the public key itself, an expiry date, and a digital signature from the certificate authority that issued it. Think of it as a government-issued ID for a server or a person: the certificate authority is the passport office, and its signature is the stamp.
Certificates follow a format called X.509, a standard maintained by the International Telecommunication Union. That standard is what lets a certificate issued in Germany be verified by a browser in Brisbane without any prior relationship between the two.
Certificates expire. This is intentional. An expiry date limits the damage if a private key is compromised, because the certificate eventually becomes invalid on its own. Most HTTPS certificates issued today are valid for either 90 days or one year. The push toward 90-day certificates, championed by Let's Encrypt, forces organisations to automate renewal, which reduces the risk of certificates being forgotten and left to run well past their security-safe life.
What certificate authorities do
A certificate authority (CA) is the organisation that vouches for the identity in a certificate. When you visit a website using HTTPS, your browser checks whether the certificate was signed by a CA it already trusts. Browsers and operating systems ship with a pre-loaded list of trusted root CAs: roughly 150 of them as of mid-2026. If a certificate chains back to one of those roots, the connection is trusted. If not, you see a warning.
Root CAs don't typically issue certificates directly to websites. The chain usually runs: root CA issues a certificate to an intermediate CA, and the intermediate CA issues certificates to individual websites. This structure keeps the root CA's private key locked away and rarely used. If an intermediate CA is compromised, the root CA can revoke its trust without compromising the entire hierarchy.
The three largest certificate authorities by market share are DigiCert, Sectigo, and Let's Encrypt. Let's Encrypt is notable because it's a non-profit that issues certificates at no cost and with near-full automation, which is why the majority of websites now run HTTPS when only a decade ago many didn't bother.
How certificate revocation works
Certificates can be revoked before they expire. This happens when a private key is stolen, a CA is compromised, or the certificate was issued in error. There are two main revocation mechanisms.
The first is the Certificate Revocation List (CRL): a regularly updated file published by the CA listing revoked certificates by serial number. Browsers can download this list and check against it. The second is the Online Certificate Status Protocol (OCSP): a real-time query your browser can send to the CA asking whether a specific certificate is still valid. OCSP is faster but puts more load on CA infrastructure.
In practice, revocation checking has been unreliable. Many browsers moved to a "soft fail" model where, if the revocation check times out, the connection proceeds anyway. Chrome has largely replaced real-time OCSP with a periodically updated blocklist called CRLSets. It's a pragmatic compromise between security and usability, and it works well for the certificates that pose the highest risk.
Where PKI appears in everyday life
HTTPS is the most visible application of PKI, but it's far from the only one. Email encryption standards like S/MIME use PKI to sign and encrypt messages. Code signing certificates let your operating system verify that software comes from a known developer before installing it. Document signing tools use PKI certificates to attach a verifiable identity to PDFs and contracts. VPNs use PKI to authenticate both the server and, in some configurations, the connecting client.
PKI also underpins the authentication systems that protect corporate networks. When an employee logs into a workplace system using a smart card or a hardware token, there's often a certificate on that device tying it to a trusted internal CA. This is sometimes called enterprise PKI or private PKI, because the company runs its own CA rather than using a public one.
Understanding how authentication layers stack up is useful context: if you've read about two-factor authentication and how it works, PKI operates at the layer below that, verifying the identity of servers and clients before any login screen appears.
What can go wrong with PKI
PKI failures are relatively rare but severe when they happen. In 2011, Dutch CA DigiNotar was compromised, and attackers issued fraudulent certificates for Google, CIA, Mossad, and other high-value domains. The Dutch government used DigiNotar certificates for citizen services. The fallout was swift: browsers revoked trust in DigiNotar within days, and the company filed for bankruptcy shortly after.
Misissued certificates are another persistent problem. A CA might incorrectly verify an applicant's identity and issue a certificate to someone who doesn't legitimately control the domain. Certificate Transparency (CT), a system now required for all publicly trusted certificates, addresses this by requiring CAs to log every certificate they issue to public, append-only logs. Anyone can audit those logs. Browsers check that a certificate appears in a CT log before trusting it. This doesn't stop misissued certificates, but it makes them far easier to detect and report.
The other risk is the protection of private keys. A server's private key stolen in a data breach means an attacker can decrypt past traffic if it was recorded, and impersonate the server going forward until the certificate is revoked and reissued. This is part of why organisations increasingly deploy hardware security modules (HSMs) to generate and store private keys in tamper-resistant hardware rather than on general-purpose servers.
PKI connects closely to the broader discipline of keeping systems secure. It's worth understanding alongside topics like encryption and how it keeps your data safe, since the two are deeply intertwined: PKI is largely the infrastructure that manages who holds the keys used for encryption.
Why PKI is worth understanding
Most Australians will never configure a CA or manage a certificate chain. But knowing that PKI exists, and what it does, matters for two reasons. First, it helps you make sense of security warnings: if a browser tells you a certificate has expired or isn't trusted, you now know what that actually means and why dismissing the warning is a genuine risk. Second, organisations that handle sensitive data need to make real decisions about certificate lifetimes, CA selection, and private key management. Those decisions sit inside a PKI framework whether the people making them know the term or not.
PKI is one of those foundational systems that works best when it's invisible. The fact that most people have never heard of it is, in a sense, a sign that it's doing its job.