PKI (Public Key Infrastructure)

Public key infrastructure, or PKI, is what makes digital certificates worth trusting. It covers how keys are made, how certificates are issued, how they get checked, and how they are cancelled when something goes wrong. The maths behind it is old and well understood. PKI is the dull, vital part around the maths: the rules, the roles and the record keeping that let two parties who have not met before swap data safely.

Payments run on it all the time, mostly out of sight. The padlock on a checkout page is a certificate being checked, a terminal proving it is a real terminal is a certificate being checked, and a bank and an acquirer swapping files safely are doing the same thing. The internet standard for all this is RFC 5280, which profiles X.509 certificates and cancel lists for internet use. Almost everything in the chain traces back to it.

The Two Keys

Each party holds a pair of keys: one public, which can be handed to anyone, and one private, which must not leave its owner. Data locked with the public key opens only with the private one, and a signature made with the private key can be checked by anyone holding the public one. That lopsided design is the whole trick, and it lets the arrangement work with no shared secret set up in advance.

Where A Certificate Comes In

A public key on its own proves nothing about who owns it. A certificate is the answer: it ties a key to an identity and is signed by an authority that both sides trust. Checking one means following a chain from it, through any middle links, back to a root already trusted, and breaking any link makes the check fail. That chain is the gap between scrambling data and trusting it.

Revocation Is The Hard Part

Keys get lost, stolen or retired before their certificate runs out, so there has to be a way to say a certificate is no longer good. Cancel lists and live status checks both do that job, and both carry a cost: the checker has to reach them, and a check that cannot be made has to fail safely. Plenty of real incidents come down to that check not being made. Very few come down to broken maths.

PKI In Card Payments

A card terminal carries a terminal certificate that proves it is a known device. Chip cards carry their own keys, which is how the EMV chip rules stop a copied message being replayed. Files moving between banks are signed, so the receiver knows they were not altered on the way. A message authentication code does a related job on single messages.

Where The Private Keys Live

Not on a normal server, if the design is any good. Keys that matter sit inside a hardware security module, which does the work without letting the key out in a form anyone can use. Card schemes set rules on key handling, and so does the PCI Security Standards Council. Those rules are revised over time, so the current version is the one to work from.

PKI, Encryption And Hashing

These three get swapped around and do different jobs. Data encryption hides content, so only a key holder can read it, and secure hashing makes a fixed fingerprint of data that cannot be undone. PKI is the trust layer that says whose key is whose. A system can scramble data perfectly and still be worthless, because if it cannot tell who it is talking to, the rest does not help.

Who Runs The Authority

Many businesses do not run their own. Public web certificates come from commercial authorities that browsers already trust, and the process is largely automatic. Card schemes run their own for terminals and cards. Some large firms run an internal authority for staff and servers, which gives control and adds a real duty of care. Running one badly is worse than not running one, since every system that trusts it inherits the weakness.

What Goes Wrong In Practice

Expiry causes most of it. A certificate lapses on a Saturday and a payment route stops. Chains break because a middle link was not installed, clocks drift so a good certificate looks out of date, and keys sit in a code store where they should not have been. None of these are failures of the maths. They are failures of process, which is why a list of certificates, and a warning before each expiry, matter as much as the keys themselves.

Keeping Track Of What Expires

Start with an inventory, because most teams do not have one. Keep a list of every certificate, where it lives and when it runs out. Then raise a warning well before the date arrives. Renew without human effort where the platform allows it, and keep private keys in hardware for anything that matters. Check the cancel status, and decide up front what happens when that check cannot be made. Rotate keys on a schedule rather than after a scare. This look at tokenisation and encryption is a useful companion. A payment gateway is designed to help handle much of this on a merchant's behalf.

‍