SelfSignedCert
Zero server storage. Everything happens in this tab.

Free self-signed SSL & CSR generator.

Create a localhost HTTPS certificate, Root CA, host cert, mTLS client certificate, or CSR in your browser. Private keys never upload. An OpenSSL alternative that stays on your device.

Or browse the free SSL tools.

Private keys never upload

Generation uses Web Workers inside the browser. The network is not in the path.

Nothing we can leak

History stores metadata you choose. Certificates and keys are gone when you leave.

Self-signed TLSThis tab only

Subject

localhost

Algorithm
RSA 2048
Valid
365 days
SHA-256 fingerprint
A4:F1:C8:E2:9B:0D:77:E1:C6:A9:B3:D4

Private key is in memory

Download now. Refresh the page and it is gone forever — by design.

.crt.key.pem.pfx

SSL checker

Check a live site's certificate.

Paste a URL. SelfSignedCert opens HTTPS to that host and reads the public certificate — issuer, validity, SANs, and days left. We do not store the lookup. Private keys are never involved.

Prefer a standalone page? Open the SSL checker.

Why SelfSignedCert

A certificate tool that cannot betray you.

Most “online certificate generators” ask you to trust a stranger with a private key. SelfSignedCert is designed so that trust is unnecessary.

Generated in the browser

RSA keypairs, X.509 certificates, CSRs, and PKCS#12 files are assembled on-device. Close the tab and the secrets disappear.

We store nothing sensitive

No certificates, no private keys, no CSRs on our servers. Logged-in history is metadata only — names, dates, fingerprints.

Private PKI, mTLS, and CSRs

Forge a Root CA, issue host certificates from it, or mint a one-off self-signed leaf, a client cert, or a CSR.

Readable details

Serial, subject, SANs, validity window, and SHA-1 / SHA-256 fingerprints — shown before you download anything.

The formats you actually need

Download .crt, .key, .pem, .csr, or a password-protected .pfx. Copy any value, or take the whole bundle as a zip.

Built to be inspected

No opaque backend in the issuance path. If you can read JavaScript, you can see exactly what runs on your machine.

How it works

Three steps. Zero uploads.

01

Describe the identity

Common name, SANs, organization, validity, and key size. Smart defaults get you a usable localhost certificate in seconds.

02

Forge it here

Your browser generates the keypair and signs the certificate. Nothing is posted to SelfSignedCert. There is no issuance API.

03

Take the files. Leave nothing.

Download or copy. We can remember a fingerprint if you want a paper trail — never the key. Refresh, and memory is empty.

Certificate guide

Root CA and host certs, plus the rest.

A certificate binds a public key to a name. In a private PKI you forge a Root CA once, trust it on your machines, then issue a host certificate for each server. SelfSignedCert does that pairing in this browser. Nothing is uploaded.

01

Forge a Root CA

Long-lived. Keep the CA key offline.

02

Trust the CA once

Install ca.crt in the OS or browser store.

03

Issue host certs

Each server gets a leaf signed by that CA.

Step 1 · Authority

Root CA certificate

A certificate authority you own. It does not sit on a website. You install it in a trust store once. After that, any host certificate it signs is trusted by machines that trust this CA.

Use when

  • You run several internal hosts and do not want to trust each one by hand
  • A homelab, staging cluster, or company lab
  • You want one trust decision, then many host certs

Use where

  • macOS Keychain, Windows Trusted Root, Linux ca-certificates
  • Browser or OS trust stores on developer machines
  • A secrets vault — the CA private key never belongs on a web server

You download ca.crt to trust, ca.key to keep offline

Do not put the CA private key on nginx, a laptop desktop, or git. Anyone with that key can impersonate every host you issue.

Step 2 · Server

Host certificate

A leaf certificate for one hostname or service, signed by your Root CA. The issuer is the CA, not the host. Browsers that trust the CA will accept this host without a warning.

Use when

  • api.dev.local, *.apps.internal, a NAS, or a k8s ingress
  • You already have a Root CA (forged here or elsewhere)
  • You will rotate this cert more often than the CA

Use where

  • nginx, Caddy, Traefik, IIS, Apache
  • Node, Go, Java, .NET HTTPS servers
  • Docker Compose and Kubernetes ingress

You download host.crt + host.key, plus the CA or a chain.pem

A host cert is not a CA. Do not install it in the Trusted Root store. Install the CA there, and this file on the server.

One-off server

Self-signed TLS

A server certificate that signed itself. Fast when you have a single box and no desire to run a CA.

Use when

  • A single localhost or one internal service
  • You will trust this one cert by hand

You download .crt + .key

Poor fit once you have many hosts — you will click through warnings forever. Use a Root CA + host certs instead.

Caller identity

Client certificate

Proves who is calling an API or gateway (mTLS). Not a website certificate.

Use when

  • API gateways, bots, devices, admin tools

You download .pfx or .crt + .key

Installing this on a server will not give visitors HTTPS.

Request

CSR

A request you send to a public or company CA. Not a certificate until they sign it.

Use when

  • A public site that must show a lock with no warning

You download .csr to the CA, .key stays with you

Never send the private key with the CSR. The .csr is enough.

If you are not sure, start here

Pick the situation that is closest. Then generate that type.

SituationForge this
Several internal hosts, trust them all onceRoot CA, then a host cert per server
One hostname on nginx / Caddy / k8sHost certificate (signed by your CA)
A single localhost and no CA to manageSelf-signed TLS
A public site on the internetCSR → send to a public CA
An API that should only accept known callersClient certificate
Your company PKI / IT team issues the certsCSR
Open the generator

Best practices

How to handle what you just forged.

SelfSignedCert can mint the files. It cannot keep you from leaking them afterwards. These are the habits that actually matter.

01

Download before you leave

The private key exists only in this tab. Refresh, close, or crash and it is gone. Save the files first, then verify them.

02

Never send the private key

Do not email, Slack, or commit a .key or an unlocked .pfx. A CSR is what you send to a CA. The key stays with you.

03

Name it the way you will connect

Browsers and TLS clients check SANs, not just the common name. If you will open https://api.dev.local, that name must be on the certificate.

04

Trust the CA, not every host

Install the Root CA in the OS or browser store once. Put host certificates on servers only. Never install a host cert as a trusted root, and never put the CA private key on the web server.

05

Let the CA outlive the hosts

A lab CA can last five to ten years. Host certs should be much shorter. If a host would expire after the CA, SelfSignedCert will refuse to issue it.

06

Keep lab certs short-lived

90 days is plenty for localhost and staging. Long-lived keys get copied, forgotten, and reused. Prefer re-issuing over a ten-year cert.

07

One identity per service

Do not reuse a single key across prod, staging, and a laptop. Compromise of one environment should not impersonate the others.

08

Password the PFX

If you need PKCS#12 for Windows or a phone, set a password you will remember. An unlocked .pfx is a private key in a different costume.

09

2048 is the default on purpose

RSA 2048 is the right size for internal TLS. Use 4096 only when a policy demands it — it is slower to generate and rarely buys you anything here.

10

Self-signed is not public trust

A self-signed cert will warn in every browser until you trust it locally. For a public site, generate a CSR and let a real CA sign it.

11

Park the key after download

Move the private key into the OS store, a secrets manager, or the server config — then delete the download from your desktop.

Compared

The privacy of OpenSSL. The manners of a product.

SelfSignedCertOpenSSL CLICloud generators
Private key locationThis browserYour terminalTheir servers
Needs an account to issueNoNoUsually
Readable UIYesNoSometimes
Can the vendor leak your key?NoNoYes
PFX / CSR / mTLSYesIf you know howVaries

Pricing

Pay for a higher cap. Never for custody of your keys.

Full comparison

Free

$0

Full local generation. No account required.

  • 3 certificates
  • Root CA, host, self-signed, client, CSR
  • RSA 2048 & 4096
  • Downloads in every format
Start generating

Plus

$5/ mo

For regular lab and staging work.

  • 25 certificates
  • Everything in Free
  • Saved subject profiles
  • Passworded PFX helpers
See Plus

Studio

$12/ mo

For people who mint certificates every week.

  • 50 certificates
  • Everything in Plus
  • Priority email
  • Highest local cap
See Studio

Questions

Straight answers.

Do you store my certificate or private key?+

No. Generation happens in your browser. SelfSignedCert’s servers never receive certificates, private keys, CSRs, or PFX files. If you sign in, we can keep a local metadata history on this device — names, dates, fingerprints — not the secrets.

How many certificates can I generate?+

Free includes 3 certificates. Plus is $5/month for 25. Studio is $12/month for 50. Signed-in usage is stored in Supabase as metadata only. Checkout is Dodo Payments. Private keys are still never uploaded.

Can I use this without an account?+

Yes. Guest mode is first-class. An account is only for remembering metadata and settings on this device.

Which certificate type should I generate?+

For several internal hosts, forge a Root CA, trust it once, then issue a host certificate per server. Self-signed TLS is the one-off shortcut when you have a single box and no CA. A client certificate is for mTLS — proving who is calling. A CSR is not a certificate yet: send it to a public or company CA for a site on the internet.

What is the difference between a Root CA and a host certificate?+

The Root CA is the authority. You install its public certificate in a trust store. The host certificate is the leaf you put on a server; it is signed by that CA. Trust the CA, not every host cert. Keep the CA private key offline — it can sign anything.

Are self-signed certificates trusted by browsers?+

Not automatically. Browsers will warn until you trust the certificate locally. That is expected. SelfSignedCert is for lab, staging, internal services, and CSRs you send to a real CA.

What happens if I refresh after generating?+

The private key is gone. That is the product. Download before you leave the success screen.

Is this a certificate authority?+

No. SelfSignedCert does not operate a public CA and does not issue publicly trusted certificates. It helps you create keys and certificates on your own machine.

Can I check a live website’s SSL certificate?+

Yes. Paste a URL on the homepage or the SSL checker. SelfSignedCert opens a TLS connection to that host and reads the public certificate — issuer, dates, SANs, and days left. We do not store the lookup. Private keys are never involved.

How do I generate a self-signed SSL certificate for localhost?+

Use the generator, keep the common name as localhost, and include localhost plus 127.0.0.1 in the SANs. Download the .crt and .key. Browsers will warn until you trust the certificate or a local Root CA.

Is this a replacement for OpenSSL?+

For interactive work, yes — SelfSignedCert produces the same kinds of PEM, CSR, and PFX files. For scripts and CI you may still want the OpenSSL CLI. We publish the equivalent commands on the OpenSSL tools page.

Ready when you are

Make a certificate nobody else will ever hold.