Public-key (asymmetric) cryptography is the foundation SSL/TLS is built on, and it solves a problem that plain shared-password encryption can't: how do two parties who've never met agree on a shared secret over a network that might be actively monitored?
The core idea
A key pair — one public key, one private key — is generated together, mathematically linked in a way that makes them a matched set: data encrypted with the public key can only be decrypted with the corresponding private key, and a signature created with the private key can be verified by anyone using the public key, without needing the private key itself.
Why this solves the "never met before" problem
With symmetric encryption (one shared key for both encrypting and decrypting), you'd need to somehow securely exchange that key first — which is a chicken-and-egg problem if the only channel you have is the same insecure network you're trying to protect. Asymmetric cryptography sidesteps this entirely: the public key can be broadcast openly, even to an attacker, without it giving them any way to decrypt data sent using it.
Where each key actually gets used in TLS
- The public key, embedded in your certificate, is what the browser uses during the handshake — both to encrypt certain key exchange data, and, more importantly, as part of verifying the certificate's authenticity via the CA's own signature chain.
- The private key, which never leaves your server, is used to prove the server genuinely owns the certificate being presented — by performing a cryptographic operation only the true key holder could perform correctly.
- In modern TLS (using ECDHE key exchange), the actual bulk-data encryption key is derived fresh each session through Diffie-Hellman key exchange, rather than being the private key itself — which is what enables Perfect Forward Secrecy.
Why losing your private key is catastrophic
If your private key leaks, an attacker can impersonate your server convincingly to anyone — they can present your real certificate (which is public anyway) and prove ownership of it, because they now hold the one secret piece that only the legitimate server was supposed to have. This is exactly why private keys should never be emailed, committed to a public code repository, or stored anywhere outside the server (or a secrets manager) that needs them — and why a leaked private key means immediate revocation and reissuance, not just a routine renewal.
RSA vs elliptic curve key pairs
The mathematical relationship between public and private keys can be built on different underlying problems — RSA relies on the difficulty of factoring very large numbers, while ECC (Elliptic Curve Cryptography) relies on the discrete logarithm problem over elliptic curves. Both are asymmetric key pairs conceptually; they just use different math, which is why ECC keys can be much smaller than RSA keys while offering comparable security.
Where key generation actually happens
The key pair is generated locally, on your own server or workstation, at the moment you create a CSR — never by the certificate authority. This is a deliberate and important property of the whole system: the CA never sees, handles, or needs your private key at any point in the issuance process, which means there's no step where a CA could leak it even if their systems were compromised. Some hosting control panels and cloud load balancers generate and store the key pair on your behalf as a convenience, which is fine operationally, but it does mean that platform now holds your private key — worth knowing exactly which systems hold a copy of any given key, especially for high-value domains.
Common ways private keys end up exposed by accident
- Committed to a public or shared code repository alongside application code — a surprisingly common and entirely avoidable mistake, since automated scanners actively search public repositories for exactly this pattern
- Included in a server backup that's stored somewhere less protected than the live server itself
- Emailed or shared over chat during a migration, rather than transferred through a secrets manager or encrypted channel
- Left with overly permissive file permissions on a shared server, readable by other accounts or processes that shouldn't have access
Any of these should be treated the same way as a confirmed compromise: revoke the certificate, generate a fresh key pair, and reissue — rotating just the certificate while reusing a potentially exposed key doesn't actually close the gap, since the private key itself is what an attacker needs.
Signing versus encrypting: the same key pair, two different operations
It's worth separating two operations that both use the key pair but work in opposite directions. Encryption (used during key exchange) uses the recipient's public key to scramble data that only their private key can unscramble. Signing (used when a CA signs your certificate, or when your server proves it holds the private key during the handshake) works the other way: the private key holder signs something, and anyone with the public key can verify that signature came from the true key holder, without needing the private key themselves. Certificates rely on both operations at different points — the CA's signature over your certificate uses the CA's own key pair for signing; the key exchange during your visitors' TLS handshakes uses your certificate's key pair (or a fresh ephemeral one, with modern forward-secret key exchange).
A simple analogy that actually holds up under scrutiny
A useful, reasonably accurate analogy: the public key is like a padlock you hand out freely to anyone who wants to send you something secure — they lock a box with it, and only your private key can open that specific lock. Unlike many security analogies, this one holds up reasonably well under closer technical scrutiny, which is part of why it's so commonly used when first introducing asymmetric cryptography to newcomers.
Where key generation actually happens and who ever sees it
The key pair is generated locally, on your own server, at the moment you create a CSR — the certificate authority never sees, handles, or needs your private key at any point in the issuance process. This is a deliberate and important property: there's no step in the entire chain where a CA could leak a private key it never possessed in the first place, which is part of why the private key is the one component you're solely responsible for protecting.
Signing versus encrypting — the same key pair, opposite directions
It's worth separating two operations that both use a key pair but work in opposite directions. Encryption uses the recipient's public key to scramble data that only their private key can unscramble. Signing works the other way: the private key holder signs something, and anyone with the public key can verify that signature came from the true key holder — this is exactly what a CA does when it signs your certificate, using the CA's own key pair.
Why losing your private key is worse than losing the certificate itself
The certificate itself is public information anyway — it's transmitted to every visitor's browser as part of every connection. The private key is the one piece that's supposed to never leave your server, and if it does, an attacker can convincingly impersonate your site to anyone, since they can present your real, valid certificate and prove ownership of it using the stolen key.
This asymmetry, public keys freely shareable, private keys never transmitted, is the single mathematical property that makes secure communication between strangers over an open network possible at all, and everything else in this Basics category builds on it in one way or another.
A quick closing checklist for key pair hygiene
Confirm your private key file has restrictive permissions, is never committed to version control, and is backed up securely and separately from your public certificate — three habits that prevent the most common, avoidable key-related incidents.