Every digital certificate, every TLS handshake, every digital signature depends on a pair of mathematically linked keys. Understanding how public and private keys work is essential to understanding how trust is built online.
Imagine a special mailbox on your front porch. It has a slot that anyone on the street can drop a letter into. That slot is always open, always visible, and everyone knows where it is. But the mailbox itself is locked, and only you have the key to open it and read what's inside. No matter how many people drop letters in, only you can retrieve them.
This is the basic idea behind public and private keys. The mail slot is your public key, freely shared, openly available, used by anyone who wants to send you encrypted data. The key to open the mailbox is your private key, kept secret, never shared, and the only thing that can decrypt what was encrypted with the public key.
This concept, called asymmetric cryptography, was first proposed publicly in 1976 by Whitfield Diffie and Martin Hellman. It solved one of cryptography's oldest problems, how to exchange secrets securely without needing a pre-shared key, and it remains the foundation of everything from HTTPS to email encryption to digital certificates.
A key pair consists of two mathematically related keys generated together. Their relationship is governed by a one-way mathematical function: the public key is derived from the private key, but computing the private key from the public key is computationally infeasible.
When someone wants to send you confidential data, they encrypt it with your public key. The resulting ciphertext can only be decrypted by your private key. Even the sender cannot reverse the encryption. Only the holder of the private key can.
The relationship works in reverse for signatures. You sign data with your private key, and anyone with your public key can verify that the signature is authentic. This proves both your identity and that the data hasn't been tampered with.
In protocols like TLS, key pairs are used to negotiate a shared session key. The asymmetric keys handle the initial, secure exchange; then a faster symmetric algorithm takes over for the bulk data encryption. This hybrid approach gives you the best of both worlds.
The crucial rule is simple: the private key must never be shared. The entire security model depends on this. If an attacker obtains your private key, they can impersonate you, decrypt messages intended for you, and forge your digital signatures. The public key, by contrast, is designed to be distributed as widely as possible. It is embedded in digital certificates and shared with anyone who needs to communicate with you securely.
The strength of a key pair depends on how it is generated and, critically, on its key length, the number of bits that make up the key. Longer keys are harder to break, but they also require more computation.
RSA keys of 2048 bits are the current industry minimum. Many organizations now default to 4096 bits for root and intermediate CA keys, providing a larger security margin as computational power increases.
Elliptic Curve keys achieve equivalent security with much shorter lengths. A 256-bit ECC key (P-256 curve) offers security comparable to a 3072-bit RSA key. A 384-bit ECC key matches roughly 7680-bit RSA.
Key generation requires a source of high-quality randomness (entropy). Poor randomness (from flawed hardware, buggy software, or predictable seeds) can produce keys that appear strong but are actually guessable. This is one of the most common silent vulnerabilities in cryptographic systems.
Both RSA and ECC are vulnerable to future quantum computers running Shor's algorithm. Post-quantum algorithms use different mathematical structures (lattices, hash-based schemes) and will require different key sizes entirely.
When a key pair is generated for a certificate, the private key is created first, and the public key is mathematically derived from it. The public key is then included in a Certificate Signing Request (CSR) and ultimately embedded in the issued certificate. The private key stays with the certificate owner and should never leave its secure storage.
Public and private keys are not abstract concepts. They are active participants in the security mechanisms you rely on daily. Here are the most important use cases:
When your browser connects to a website over HTTPS, the server presents its certificate containing its public key. The browser uses this public key to verify the server's identity and to establish an encrypted session. The server's private key is used on the server side to complete the handshake. This happens billions of times per day across the internet.
Software developers sign code with their private key so users can verify authenticity. CAs sign certificates with their private key so browsers can verify trust. Email senders sign messages with their private key so recipients can confirm the sender's identity. In every case, the corresponding public key is used for verification.
S/MIME uses the recipient's public key (from their certificate) to encrypt an email. Only the recipient's private key can decrypt it. This ensures that even if the email is intercepted in transit or accessed on a compromised mail server, the content remains confidential.
In zero-trust architectures and service mesh environments, both the client and the server present certificates and prove ownership of their private keys. This mutual TLS ensures that each side of the connection is authenticated, which is critical for microservice-to-microservice communication.
Generating a strong key pair is only half the battle. If the private key is not stored and protected properly, it might as well not exist. Here are the main storage options, from basic to hardened:
The simplest approach: the private key is stored as a file on disk, often in PEM or PKCS#12 format, optionally protected by a passphrase. This is common in development environments, but it leaves the key exposed to anyone with access to the file system. Not recommended for production CA keys or high-value certificates.
Cloud providers offer key management services (AWS KMS, Azure Key Vault, Google Cloud KMS) that store keys in software-backed or hardware-backed vaults. Access is controlled through IAM policies and audit logs. This is a significant step up from file-based storage, particularly in cloud-native environments.
An HSM is a dedicated, tamper-resistant hardware device designed to generate, store, and use cryptographic keys. The private key never leaves the HSM. All cryptographic operations happen inside it. HSMs are the gold standard for protecting CA private keys, and they are required by most compliance frameworks (eIDAS, WebTrust, ETSI) for issuing publicly trusted certificates.
Key management is one of the areas where mistakes are most costly and most common. Here are the pitfalls that organizations encounter repeatedly:
If a private key is stolen (through a server breach, an exposed backup, or a misconfigured repository), the attacker can impersonate the key owner, decrypt intercepted traffic, and forge digital signatures. The only remedy is to revoke the certificate immediately and generate a new key pair. Every minute of delay is a window of exposure.
RSA keys shorter than 2048 bits are considered breakable with modern hardware. Legacy systems sometimes still use 1024-bit RSA keys, which have been deprecated for over a decade. Similarly, keys generated with poor randomness (such as the Debian OpenSSL bug of 2008, which affected thousands of servers) can be cracked trivially regardless of their nominal length.
Private keys stored in plaintext on web servers, committed to Git repositories, or shared across multiple systems dramatically increase the blast radius of a compromise. Similarly, reusing the same key pair across many certificates means that a single key compromise invalidates all of them. Best practice is to generate a unique key pair for each certificate and store private keys in the most secure storage available for the use case.
These pitfalls underscore why key management is not just a technical concern. It is an organizational one. Clear policies on key generation, storage, rotation, and incident response are essential. Without them, even the strongest cryptographic algorithms cannot protect you.
Inventory every key: Evertrust CLM discovers all certificates and maps the associated key algorithms, lengths, and storage locations. You get a complete picture of your cryptographic posture, including keys that fall below your security standards.
Enforce key policies: Define minimum key lengths, approved algorithms, and mandatory HSM usage for specific certificate types. Evertrust PKI enforces these policies at enrollment time, preventing weak keys from ever being issued.
Automate key rotation: When certificates are renewed or re-keyed, Evertrust automates the generation of new key pairs and the deployment of updated certificates, reducing the risk of key reuse and human error.
Respond to compromise fast: If a key is suspected compromised, Evertrust enables immediate revocation and automated re-issuance across all affected systems, minimizing the window of exposure.
