What is public key cryptography? Key pairs in TLS

9 min readUpdated Oct 2026

Public key cryptography, also called asymmetric cryptography, uses a pair of keys, one public and one private, and a different key of the pair for each of two counterpart operations: encryption and decryption, or creating a signature and verifying it ^[1]. In SSL and TLS the certificate publishes the public key, and in TLS 1.3 the server uses the private key to sign, not to decrypt ^[2]. It is part of the SSL and TLS glossary.

Also called: asymmetric cryptography, the term RFC 4949 defines ^[1]
Key pair: a private key known only to its owner and a public key that can be shared ^[1]
Used for: encryption, digital signatures and key agreement ^[1]
Certificate key in TLS 1.3: signs the handshake in the CertificateVerify message ^[2]
Public TLS certificates: RSA with a modulus of at least 2048 bits, or ECDSA on P-256, P-384 or P-521 ^[8]

A key pair: one key kept, one given away

A key pair is two keys generated together. The private key does not have to be known by anyone but its owner, and the public key can be handed to anybody who uses the algorithm, with no need to keep it secret ^[1]. In a test with OpenSSL 3.0.13 one command made the pair and a second wrote out the public half:

$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa.key
$ openssl pkey -in rsa.key -pubout -out rsa.pub
$ head -1 rsa.key; head -1 rsa.pub
-----BEGIN PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----

The private key file is the one to protect. The public key is what goes into a certificate: the Subject Public Key Info field carries the key and names the algorithm it is used with ^[4]. The private key is never part of the certificate. Both files above are PEM text, which has its own entry in this glossary, and the certificate fields around the key are covered under X.509.

Signing and verifying

A signature is made with the private key and checked with the public key. Digital signatures detect unauthorized changes to data and authenticate the identity of the signatory ^[7], and anyone who has the public key can run the check. In the test, an RSA signature over a short message verified:

$ openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sign rsa.key -out msg.rsa.sig msg.txt
$ openssl dgst -sha256 -sigopt rsa_padding_mode:pss -verify rsa.pub -signature msg.rsa.sig msg.txt
Verified OK

Changing "Pay 100" to "Pay 900" in the message gave Verification failure. So did checking the original message against the public key of a second, unrelated pair.

Signing is not the private key "encrypting" the message. RFC 8017 defines RSA signature schemes (RSASSA-PSS, RSASSA-PKCS1-v1_5) apart from its encryption schemes (RSAES-OAEP, RSAES-PKCS1-v1_5), and calls it good practice to use one RSA key pair in only one scheme ^[5]. ECDSA and EdDSA are signature algorithms ^[2]^[6]. With a P-256 key and with an Ed25519 key, openssl pkeyutl -encrypt stopped at Error initializing context.

Encryption and key exchange

In an encryption scheme, anyone encrypts with the recipient's public key and only the matching private key decrypts ^[1]; RFC 8017 names delivering key material to another party as a typical use ^[5]. In the test, a short secret encrypted to rsa.pub with OAEP came back intact from rsa.key. The private key of the second pair returned Public Key operation error.

TLS 1.2 could work that way. With RSA key exchange the client generates a premaster secret, encrypts it with the public key from the server's certificate and sends the result (RFC 5246 §7.4.7.1) ^[3]. In TLS 1.3, defined in RFC 8446, static RSA and Diffie-Hellman cipher suites have been removed. Its key exchange is (EC)DHE, a pre-shared key, or both, and every public-key based exchange in it provides forward secrecy ^[2].

(EC)DHE is key agreement rather than encryption. Each side sends a key share, then uses its own private key and the other side's public key to compute the same secret ^[1]^[2]. Nothing is encrypted to the certificate's key. The message order is on the TLS handshake page, and what the change protects is on the forward secrecy page.

What each key does in a TLS 1.3 connection

The keys in a TLS 1.3 connection fall into two groups: the keys tied to certificates, where private keys sign and the public keys from certificates check those signatures, and the rest, which establish and protect the traffic.

What each key does in a TLS 1.3 connection
Key	Held by	Job
Server certificate's private key	the server	signs CertificateVerify, explicit proof that the server possesses the private key matching its certificate ^[2]
Server certificate's public key	the certificate, sent to every client	lets the client check that signature ^[2]
Issuing authority's private key	the certificate authority	signed the certificate, certifying the binding between the public key and the subject ^[4]
Issuing authority's public key	the issuer's certificate	lets the client check the certificate's signature ^[4]
Key shares	client and server, sent in ClientHello and ServerHello	establish shared keying material ^[2]
Traffic keys	client and server	protect application data once the handshake is complete ^[2]

Explanations of HTTPS in which the browser encrypts a session key with the server's public key describe RSA key exchange in TLS 1.2 ^[3]. In TLS 1.3 the certificate's key only signs ^[2].

Which keys a public certificate can carry

A publicly trusted TLS certificate can carry only an RSA key whose modulus is at least 2048 bits and divisible by 8, or an ECDSA key on NIST P-256, P-384 or P-521. The CA/Browser Forum Baseline Requirements §6.1.5 permit no other algorithms or key sizes ^[8].

Signature, encryption and public certificate support by key algorithm
Algorithm	Signature	Encryption	Public TLS certificates (BR §6.1.5)	Test, OpenSSL 3.0.13
RSA	RSASSA-PSS, RSASSA-PKCS1-v1_5 ^[5]	RSAES-OAEP, RSAES-PKCS1-v1_5 ^[5]	modulus at least 2048 bits, divisible by 8	256-byte signature with a 2048-bit key; OAEP round trip
ECDSA	yes ^[2]	none: a signature algorithm ^[2]	P-256, P-384, P-521	verified; encryption refused
Ed25519	yes, 64-octet signatures ^[6]	none: a signature scheme ^[6]	not permitted	64-byte signature; encryption refused

TLS 1.3 lists ed25519 and ed448 among its signature algorithms ^[2], so the protocol can use them while public certificates cannot carry them under §6.1.5. An RSA key signs the TLS 1.3 handshake with RSASSA-PSS: the RSASSA-PKCS1-v1_5 values refer solely to signatures in certificates and are not defined for signed handshake messages ^[2].

Certificates tie a key to a name

A certificate tells a client which public key belongs to which name. By signing it, the authority certifies the binding between the public key and the subject ^[4]. Apps that want a narrower check can carry the expected key themselves, which is pinning a certificate or its public key. Any trusted authority can sign such a binding, and transparency logs for issued certificates are where an unexpected one for your name becomes visible.

If the private key leaks, whoever holds it can produce the CertificateVerify signature and pass as the server ^[2]. The Baseline Requirements list key compromise as a reason to revoke the certificate (keyCompromise), and an authority must reject a new request for a key it has been told is compromised ^[8]. Recorded TLS 1.3 traffic stays protected: a signature key compromised after the handshake does not compromise the session key, as long as the session key itself has been erased ^[2].

Where the keys live on Bridge CDN

On Bridge CDN the key pair behind the certificate belongs to the platform. Bridge SSL is the certificate layer of Bridge CDN, and it issues its own certificates because it owns the key. TLS is terminated at the edge, so there is no certificate file on your machine, and Bridge SSL has no certificate upload. Generating a private key and a signing request are steps of a traditional installation; here the one step is adding the domain. The certificate is presented by the layer that terminates TLS, so Bridge SSL cannot hold the key for a site served elsewhere.

FAQ

What is public key cryptography?

Public key cryptography is cryptography with a key pair: a private key that its owner keeps and a public key anyone may have, each used for one side of an operation such as signing and verifying. TLS uses it to prove the server's identity and to agree on keys. ^[1]^[2]

Is asymmetric cryptography the same as public key cryptography?

Yes. RFC 4949 defines asymmetric cryptography and gives "public-key cryptography" as its popular name. ^[1]

Does the server's public key encrypt my data in HTTPS?

Not in TLS 1.3. The certificate's key signs the handshake, and traffic is protected with keys both sides derive from the key exchange. Encrypting a secret to the server's public key was RSA key exchange in TLS 1.2, which TLS 1.3 removed. ^[2]^[3]

What key size does an SSL certificate need?

A publicly trusted certificate needs an RSA key with a modulus of at least 2048 bits, or an ECDSA key on P-256, P-384 or P-521. ^[8]

Sources

RFC 4949, Internet Security Glossary, Version 2: §4, "asymmetric cryptography".
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: §1.2, §2, §4.2.3, §4.4.3, Appendix E.1.
RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2: §7.4.7.1.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: §4.1.1.3, §4.1.2.7.
RFC 8017, PKCS #1: RSA Cryptography Specifications Version 2.2: §6, §7, §8.
RFC 8032, Edwards-Curve Digital Signature Algorithm (EdDSA): Abstract, §7.
NIST FIPS 186-5, Digital Signature Standard (DSS), Abstract.
CA/Browser Forum Baseline Requirements for TLS server certificates: §4.9.1.1, §6.1.1.3, §6.1.5.