CSR, PKI, and private key security — in plain English

A CSR is a block of encoded text generated alongside a private key. It contains the details you want on your certificate — domain name, organization information, and your public key — and is submitted to a Certificate Authority (CA) so it can issue a signed certificate.

No. A CSR contains your public key, your identifying details, and a signature proving you hold the matching private key. The private key itself never leaves the system where it was generated and should never be shared with anyone, including your CA.

You can, but it's best practice to generate a new key pair and CSR at renewal time. Reusing the same key indefinitely increases the impact if that key is ever compromised.

The CSR and any certificate issued from it become useless without the matching private key. You'll need to generate a new key pair, a new CSR, and request a new certificate.

A CA copies the public key from your CSR into the certificate it signs. If the keys don't match, the certificate wasn't produced from that request — which is exactly what the Certificate & CSR Validator checks.

Be very cautious. Generating a CSR always means generating a private key first, and that key must never leave the machine that created it. A website that "generates a CSR" for you typically generates the private key too — on its own server, or in your browser where you can't fully verify what happens to it — which means a key you should be the only one to hold may have been retained somewhere else. Prefer generating CSRs locally with a trusted tool such as OpenSSL; see the CSR Generator page for a command you can run on your own server instead.

Public Key Infrastructure (PKI) is the set of roles, policies, and technology that lets people trust digital certificates. A CA vouches for a certificate by signing it, and your browser or device trusts that CA — directly or through a chain — to decide whether to trust the certificate.

A root CA certificate is self-signed and trusted directly by operating systems and browsers. Root CAs sign intermediate certificates, which in turn sign the "leaf" certificate — the one installed on a website or server. This chain lets CAs keep root keys offline and tightly protected.

Expiration limits how long a compromised or outdated certificate can be trusted, and it forces periodic re-verification of the certificate holder's identity and key material.

PEM is a Base64 text encoding wrapped in "-----BEGIN/END-----" headers, commonly used on Linux, Apache, and nginx. DER is the underlying raw binary encoding, more common on Windows and Java platforms. The Format Converter converts between the two.

A SAN is an extension listing every hostname (or IP address) a certificate is valid for. Modern browsers require the hostname you're visiting to appear in the SAN list — the older "Common Name" field alone is no longer sufficient.

Keep it on the system that needs it, restrict file permissions so only the relevant service account can read it, and avoid emailing, uploading, or copying it anywhere it doesn't need to be. For high-value keys, use a hardware security module (HSM) or a managed key vault.

Treat any tool that asks for a private key with suspicion — including this one. The PKI Toolkit never asks for a private key anywhere. Certificates and CSRs are safe to paste because they contain only public information; private keys should never leave the machine that generated them.

Revoke the certificate associated with that key immediately, generate a new key pair and CSR, and request a replacement certificate. Review how the exposure happened so it isn't repeated.

Yes. RSA keys should be at least 2048 bits — 3072 or higher for longer-lived trust — and ECDSA keys on P-256 or a stronger curve are an efficient modern alternative. Avoid algorithms or key sizes your CA or compliance policy has deprecated.