Public-Key Crypto and Certificates — Security Fundamentals: Identity and Crypto

The internet works because machines that have never met can still decide, in a fraction of a second, whether they are talking to the right party and whether anyone else can read or alter the conversation. Public-key cryptography is the trick that makes that possible. Certificates are the paperwork that makes the trick useful at scale.

The basic problem: secrets between strangers

Encryption is a way to turn readable information, called plaintext, into unreadable information, called ciphertext. A key is the extra piece of information needed to perform that transformation and undo it.

The oldest practical pattern is symmetric encryption. In symmetric encryption, the same secret key locks and unlocks the data. It is fast and strong, but it creates a hard question: how do two parties get the same secret key without an eavesdropper seeing it?

That question is especially hard on open networks. Your browser may need to talk safely to a bank, a hospital, or a software update service it has never contacted before. There is no safe envelope to put the first secret in.

Public and private keys

Public-key cryptography solves the first-contact problem by using a pair of mathematically related keys. The public key can be copied, posted, and sent to anyone. The private key must be kept secret by its owner.

The two keys are related in a one-way way. A message prepared with one key can be checked or processed with the other, but knowing the public key does not give a practical path to the private key. Practical here means that, with known mathematics and available computing power, the attack would take too long to be useful.

This idea supports two different jobs. One job is secrecy: someone can use your public key so that only your private key can read the result. The other job is proof: you can use your private key to create evidence that a message came from you and was not changed.

📌

Not magic. Public-key systems depend on carefully studied hard math problems, good implementations, and private keys that really stay private.

A key pair has a shareable public key and a secret private key linked one way.

Encryption, signatures, and what each proves

It is easy to blur encryption and signing because both use public and private keys. They answer different questions.

Encryption asks: who can read this? If Alice encrypts something for Ben using Ben's public key, only Ben's private key should be able to decrypt it.

A digital signature asks: who approved this exact data? If Ben signs a message with his private key, anyone with Ben's public key can verify that the signature matches the message and the key pair. If the message changes by even one bit, the signature check fails.

In modern secure connections, public-key cryptography is often used to authenticate the server and safely agree on temporary symmetric keys. The actual data then travels under symmetric encryption because it is much faster.

Encryption provides confidentiality: the data is hidden from parties without the right key.
Digital signatures provide authenticity and integrity: the signer is tied to the exact data.
Symmetric encryption provides efficient protection for large amounts of traffic once a shared secret exists.

Encryption controls who can read data, while a signature proves who approved it.

The missing piece: whose public key is it?

A public key by itself is just a number with structure. It does not tell you whether it belongs to your bank, a criminal, a test server, or a forgotten system in a closet.

That is the central trust problem. If an attacker can trick you into accepting their public key as if it belonged to your bank, the mathematics may still work perfectly while the security outcome fails completely.

A certificate connects a public key to an identity. It says, in effect: this public key belongs to this named subject, for these uses, during this time period, and this statement was signed by an issuer that other systems may trust.

A public key is trusted only when its certificate chains back to a trusted root.

Certificate authorities and chains of trust

A certificate authority, often shortened to CA, is an organization or system that signs certificates. By signing, the certificate authority says it has followed some process to check the subject and approve the binding between identity and public key.

Operating systems, browsers, and many devices come with a built-in list of trusted root certificate authorities. A root certificate authority can sign another certificate authority, which can sign another, which can sign a website or service certificate. This creates a chain of trust.

When your browser visits a site over Transport Layer Security, or TLS, it does not simply trust the site's certificate because the site presents it. The browser checks whether the certificate chains back to a trusted root, whether the names match, whether the dates are valid, whether the certificate is allowed for that use, and whether known revocation signals indicate it should no longer be trusted.

This whole system is called public key infrastructure, or PKI. It includes software, policies, keys, certificate authorities, logs, audits, renewal processes, and emergency procedures.

⚠️

Trust is delegated. If a trusted certificate authority or its process is compromised, it can issue certificates that other systems may initially accept.

A root authority signs an intermediate, which signs the site certificate.

What happens in a secure web connection

When a browser connects to a site using Hypertext Transfer Protocol Secure, or HTTPS, it uses TLS to protect the connection. The visible lock icon, when present, does not mean the site is honest; it means the connection to the named site was authenticated and encrypted according to the browser's checks.

A simplified TLS handshake works like this. The browser contacts the server and states what cryptographic methods it supports. The server sends its certificate and proof that it controls the matching private key. The browser validates the certificate chain and the site name. The two sides then agree on fresh session keys. After that, ordinary traffic is protected with fast symmetric encryption.

Good TLS design also provides forward secrecy. Forward secrecy means that if a server's long-term private key is stolen later, old recorded sessions should still remain unreadable because they used temporary session secrets that were not recoverable from the long-term key alone.

Decisions that matter in practice

For leaders and practitioners, certificates are not just a cryptography topic. They are an operations, governance, and risk topic. Outages often come from expired certificates, missing intermediate certificates, mismatched names, forgotten private keys, or automated systems that cannot renew cleanly.

The first decision is scope. Public certificates from public certificate authorities are appropriate for public websites and services. Private public key infrastructure is often appropriate for internal services, devices, workloads, or organizations that need tighter control over identity rules.

The second decision is key custody. A private key that signs important certificates or identifies a critical service should be generated, stored, rotated, and retired under controls that match its importance. Hardware security modules, which are tamper-resistant devices for protecting keys, are common for high-value signing keys.

The third decision is automation. Shorter certificate lifetimes reduce the damage from some mistakes and compromises, but only if renewal is reliable. Manual renewal does not scale well in environments with many services, containers, devices, and development teams.

Maintain an inventory of certificates, owners, names, issuers, expiry dates, and renewal paths.
Separate root certificate authority keys from day-to-day issuing keys, and protect roots especially strongly.
Automate renewal and deployment where possible, then test the automation before it is needed in an emergency.
Plan revocation and replacement procedures for lost private keys, misissued certificates, and changed service names.

⚠️

Expiry is an outage. An expired certificate can stop a healthy service from being trusted, which can look exactly like downtime to users.

Key takeaways

Symmetric encryption is fast, but it requires both sides to already share a secret.
Public-key cryptography uses a public key and a private key to solve first-contact trust and proof problems.
Digital signatures prove that specific data matches a private key; encryption hides data from parties without the right key.
A certificate binds a public key to an identity, and a certificate authority signs that binding.
Transport Layer Security validates certificates, authenticates a server, and then protects traffic with efficient session keys.
Certificate management is an operational discipline involving inventory, renewal, key protection, and emergency response.

Glossary

Symmetric encryption: An encryption method where the same secret key is used to encrypt and decrypt data.
Public key: The shareable half of a key pair, used by others to encrypt to the owner or verify the owner's signatures.
Private key: The secret half of a key pair, used to decrypt data or create digital signatures.
Digital signature: Cryptographic evidence that a specific private key approved specific data and that the data has not changed.
Certificate: A signed data structure that binds a public key to an identity, validity period, issuer, and allowed uses.
Certificate authority: An organization or system trusted to issue and sign certificates after following defined validation rules.
Chain of trust: A sequence of certificate signatures that connects a service certificate back to a trusted root certificate authority.
Public key infrastructure: The people, policies, systems, keys, and processes used to issue, manage, trust, and revoke certificates.
Transport Layer Security: The protocol commonly used to authenticate endpoints and encrypt network traffic, including most secure web connections.