Generate RSA, ECDSA, or Ed25519 private and public key pairs
Private Key
Public Key
Key Information
Type
Size
Fingerprint
About Key Generator
An SSL key generator creates the private key half of a certificate. Our free Key Generator creates RSA (2048-8192 bit), ECDSA (P-256, P-384, P-521), and Ed25519 key pairs. Generate secure private keys for SSL certificates, code signing, or any cryptographic purpose. All keys are generated server-side using cryptographically secure random number generators.
How to Use
1Select your key type (RSA, ECDSA, or Ed25519).
2Choose the key size or curve.
3Click "Generate Key" and copy or download the private key.
Use Cases
•Generate RSA keys for traditional SSL certificates
A key pair is two halves of the same secret. What you keep is the private half; what you hand out is the public half, which cannot be used to sign anything on its own.
1Generate the private key of the type and size you chose: RSA at the bit size requested, ECDSA on P-256, P-384 or P-521, or Ed25519.
2Encrypt it if you supplied a passphrase, so the PEM on screen is useless without it. Leave the field empty and the key is written unencrypted.
3Write the private key as PEM in the traditional format for RSA and in PKCS#8 for ECDSA and Ed25519. Both load identically in OpenSSL, Apache and Nginx.
4Derive the public key from it and write that as a SubjectPublicKeyInfo PEM, which is the form a certificate needs to reference.
5Print a SHA-256 fingerprint of the public key in its encoded form. This identifies the key without revealing anything about the private half, so it is safe to record in an inventory or an audit.
Both keys are shown once and are not retained. Save them before you close the page — the private half cannot be recovered, only replaced.
Tips & Best Practices
•ECDSA keys are 2-3x faster than RSA and recommended for modern deployments
•Never share your private key — it should remain secret
•Back up your private key securely — losing it means you can't renew your certificate
Frequently Asked Questions
ECDSA for anything modern. Its keys are roughly a third the size of RSA at comparable strength and the handshake is faster, which matters most on mobile connections. RSA is the choice when any client is old or managed by a corporate policy that has not been updated, because it is universally supported. Ed25519 is excellent but still needs a recent client stack and a certificate authority willing to sign it, so it suits controlled environments rather than the public web.
Yes, and it remains the practical default rather than a compromise. The security margin is still ample for the lifetime of any certificate currently being issued, and 2048 is what nearly every authority hands out. Moving to 3072 buys headroom for a longer-lived certificate at a modest cost in handshake size and generation time. Going below 2048 is where the trouble starts: the margin thins quickly and several browsers and certification programmes have begun rejecting smaller keys outright.
Technically yes, and plenty of deployments do it, but it concentrates risk in a way that is rarely worth the convenience. One key means one compromise affects every certificate ever issued with it, and it makes rotation a single event rather than something you can stage. It also removes the ability to attribute a leak to a specific host or service. Generate a key per certificate, or at minimum per environment, so that replacing one is routine and the blast radius of a mistake stays small.
Only in your browser, for as long as the page is open. Nothing is written to disk, kept in an account, or sent anywhere to be stored. That also means it cannot be retrieved later: if you lose it, you generate a new one and reissue the certificate, because the authority signs the public half and the private half is what must match it. Copy the private key into your own protected location before you close the tab, then close it.
For identification without handling the secret. The SHA-256 fingerprint is computed over the encoded public key, so anyone can read it from a certificate or a config file and compare it with yours. That is what lets you confirm which key a server is actually using, detect that a key was rotated unexpectedly, or record what you deployed without writing key material into your documentation. Two keys that match on fingerprint are the same key.
Because RSA keys are written in the traditional OpenSSL format, which begins BEGIN RSA PRIVATE KEY, while ECDSA and Ed25519 keys are written in PKCS#8, beginning BEGIN PRIVATE KEY. This reflects how the formats were standardised at different times, not a difference in behaviour. OpenSSL, Apache and Nginx read both, and the PKCS#8 form is the more general of the two if you need to pass the key between tools.
Yes — with no passphrase supplied, the PEM on screen is the private key in plain text and anyone who can read it can impersonate your server. Supplying one encrypts the file so it cannot be used without it, which means a leaked backup or an accidental commit stops being a full compromise. The trade-off is that your server needs the passphrase at startup, and an automated renewal pipeline must be able to supply it too. If that is awkward, protect the file's permissions instead rather than leaving it unencrypted and world-readable.
Yes, and that is the normal path. A Certificate Authority needs a Certificate Signing Request, and you build one from this private key plus the names you want covered. Use the CSR Generator, paste this key in, and it produces the request and the matching public key together. Alternatively load the key into OpenSSL with genrsa or genpkey and take it from there. Keep the key you just generated as your serving key.
