Status Services → Expedited WAF → Expedited SSL → IP Investigator → Real Email Resources → Knowledge Base → AWS In Plain English → Blog → Heroku Security Resources Use Cases → DDoS Protection → Bot & Malicious Traffic Blocking → Fraud Detection & Prevention → Credential Stuffing Protection → Compliance → OWASP Top 10 Compliance → AI Scraping Prevention → Geographic Request Blocking → Virtual Patching About Contact

So you're making an RSA key for an HTTPS certificate. What key size do you use?

Or: why you probably don't want a 4096 bit RSA cert

January 13, 2026
So you're making an RSA key for an HTTPS certificate. What key size do you use?

So you're about to make an RSA key for an SSL certificate. What key size should you use?

Since Expedited Security only do EV certificates, we use a 2048 bit key in the bash & powershell we generate during our application process.

But why not go further? What experts have to say about 4096 bit keys varies greatly:

Check any website's key size

Modern browsers no longer display certificate key sizes in their UI. The easiest way to check any website's key size is via the command line:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -text -noout | grep -A1 "Public Key"

Replace example.com with the domain you want to check. For example, checking microsoft.com:

Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)

Note: Some major sites like GitHub have moved to elliptic curve (EC) keys instead of RSA. If you see id-ecPublicKey with a 256-bit key, that's ECC - a 256-bit EC key provides roughly 128-bit equivalent security, comparable to a 3072-bit RSA key.

What key sizes do major sites use?

Here's a snapshot of RSA key sizes used by well-known websites (January 2026):

SiteRSA Key Size
microsoft.com2048-bit
amazon.com2048-bit
linkedin.com2048-bit
paypal.com2048-bit
ebay.com2048-bit
target.com2048-bit
homedepot.com2048-bit
nordstrom.com4096-bit
etsy.com2048-bit
godaddy.com2048-bit

Of these 10 sites, only Nordstrom uses a 4096-bit key. The rest all use 2048-bit RSA, which remains the industry standard.

You're probably already aware that with a 4096 bit key:

  • There's an increase in encryption strength.
  • The SSL handshake at the start of each connection will be slower.
  • There's an increase in CPU usage during handshakes.

But you may not be sure of the extent of each of these these effects. So: let's measure all these things.

Measuring encryption strength

Unlike traditional symmetric algos, asymettric algos like RSA (unfortunately) don't double in strength when you add a single bit.

So RSA key sizes are evaluated by National Institute of Standards and Technology by converting them to equivalent symmetric cipher values (see Table 2: 'Comparable security strengths'). NIST tells us a 2048 bit RSA key is equivalent to a 112 bit symmetric cipher.

NIST says a 2048 bit RSA key has a strength of 112 bits: i.e., there are theoretically 2112 possibilities to crack the private key.

Calculating RSA strength yourself

The NIST says they're using 'currently known methods' to build their data, but some clever folk on Crypto Stack Exchange worked out that the NIST data appears to use an algorthm to calculate the complexity of using a factoring attack called the 'number field sieve' by Dutch cryptographer Arjen K. Lenstra. This is handy, since the NIST recommendation doesn't include every key size. If you felt like firing up Mathematica, we could get results for, eg, a 2048 bit RSA key with:

> N[Log2[Exp[(64/9*Log[2^2048])^(1/3)*(Log[Log[2^2048]])^(2/3)]]]
116.884

The Mathematica code above was ported from Reid Wiggins' code on Crypto Stack Exchange - cheers Reid!

Since not everyone has Mathematica, here's an interactive calculator that implements the same GNFS complexity formula:

RSA Key Strength Calculator

The calculator implements the General Number Field Sieve (GNFS) complexity formula. The results show a 2048 bit RSA key is equivalent to around 116 'bits' of a symmetric algo. Actually, 116.884, but since you can't have .884 of a bit, we round down.

Note that NIST also round the GNFS complexity's result down to 112 bits, a common symmetric cipher size, to allow people to apply the same policies they would if they were considering symmetric algorithms. Our JS and the Mathemetica code above give the raw GNFS complexity.

an image

Strength for common key sizes using GNFS complexity, logarithmic scale.

Note: as mentioned in the tool's README:

The GNFS complexity measurement is a heuristic: it's a tool to help you measure the relative strengths of different RSA key sizes but it is not exact. Implementation details, future vulnerabilities in RSA, and other factors can affect the strength of an RSA key. The attack that breaks RSA 2048 could also break RSA 4096.

Notwithstanding these limitations, GNFS complexity is the best way to measure the raw strength of asymmetric encryption algorithms like RSA.

Measuring the increased load on the server

Bigger RSA key sizes may slow down handshaking from the users point of view. On a Mac or Linux machine you can get some time taken to sign a 2048 bit RSA vs 4096 bit RSA with the openssl speed rsa command:

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000210s 0.000014s   4772.1  69667.5
rsa 1024 bits 0.000727s 0.000035s   1375.3  28508.9
rsa 2048 bits 0.003778s 0.000092s    264.7  10899.5
rsa 4096 bits 0.022637s 0.000305s     44.2   3275.4

an image

Looking at the results, it's pretty clear:

4096 bit handshakes are indeed significantly slower in terms of CPU usage than 2048 bit handshakes.

Keep in mind handshakes are brief: after key exchange with RSA, the browser and server have agreed on session key, and a fast symmetric encryption algo like AES is used.

Measuring browser handshakes

We can also do a more practical test by reconfiguring a webserver with 2048 and 4096 bits keys and then measuring the SSL handshake time in Chrome:

an image

Running 5 test each on both key sizes, with the browser process restarted in between, returned:

  • An average handshake of 50ms with a 2048 bit RSA key
  • An average handshake of 76ms with a 4096 bit RSA key

an image

The added latency of the 4096 bit key was definitely noticeable, but handshaking was still quite fast.

Google want most pages to load within 100ms, Amazon find that every additional 100ms causes a drop in sales. Handshakes block everything - if your site is set up correctly, everything will be loaded by HTTPS and not a single resource will start loading until the handshake is complete.

But whether 25ms - 25/1000ths of a second is an issue depends on your site. Many websites - including ours - have a lot of optimisation to do before handshake latency becomes an issue.

We will run this test on a less powerful mobile device in future.

4096 bit compatibility concerns

Update: Amazon CloudFront now supports 4096-bit RSA keys. Some older network equipment may still have limitations - check your specific hardware documentation.

Looking ahead: NIST 2030 recommendations

NIST SP 800-57 recommends that 2048-bit RSA keys should be considered acceptable through 2030, but deprecated for new applications after that date. For systems that need to remain secure beyond 2030, NIST recommends moving to either 3072-bit RSA (128-bit equivalent security) or elliptic curve cryptography (ECC). Microsoft has announced they will not trust 2048-bit RSA root certificates after 2030.

Note that code signing certificates have already moved to 3072-bit RSA minimum as of June 2021.

Summary

So... what do we think:

Per the introduction, you should definitely pick at least a 2048 bit key: the makers of openssl, Microsoft, and every web browser are pushing you to use a 2048 bit key at minimum.

Should you use 4096 bit keys? Let's consider our results:

  • A 4096 bit key does provide a reasonable increase in strength over a 2048 bit key, and according to the GNFS complexity, encryption strength doesn't drop off after 2048 bits.
  • There's a significant increase in CPU usage for the brief time of handshaking as a result of a 4096 bit key
  • There's a small increase in browser response for the brief time of handshaking as a result of a 4096 bit key

You can replicate the results of the above tests easily and should do so.

There's no hard answer here but some points:

Is 4096-bit RSA horrible and slow? No. Looking at the results, the server CPU use and additional latency (~26ms) could be reasonable for sites that desire the gain in strength. A 2048-bit key provides a good speed/security tradeoff for most use cases through 2030. If you need security beyond 2030, consider 3072-bit RSA or switching to ECC (ECDSA P-256 or P-384).

Note: a previous version of the article mentioned 'there are theoretically 2^112 possibilities to brute force the private key' - this was incorrect. There are theoretically 2^112 possibilities to crack the private key using techniques other than brute force. Thanks to dchest on Hacker News for pointing out the error.

View All Blog Posts