Softonic

SSL Certificate Generator

Step 1 / 3

Identity

Self-signed certificates are untrusted by browsers by default: use only for local development, testing, or private networks.

Generate a self-signed certificate for local development or internal testing, right in your browser. You pick the RSA key size (2048, 3072 or 4096 bits), the Common Name, the Subject Alternative Names, the validity window and basic organisation details. The certificate and its private key are created in your browser and never sent to our server, and you download both as PEM files ready for Nginx or Apache.

How certificate generation works

  1. 1

    Pick the RSA key size

    2048 bits is fine for most testing; 3072 or 4096 give a larger key at the cost of speed.

  2. 2

    Enter subject and SANs

    Common Name plus every hostname or IP the certificate should cover (modern browsers ignore CN in favour of SANs).

  3. 3

    Generate in the browser

    A self-signed certificate is created and signed with the matching private key, all locally in your browser.

  4. 4

    Download the output

    A PEM-encoded certificate (`cert.pem`) and the PEM private key (`key.pem`), ready to install.

Everything happens in your browser

This generator runs entirely in your browser. The RSA key pair is created locally with a JavaScript crypto library, the certificate is signed on your device, and neither the private key nor the certificate is ever uploaded to our server. Even so, treat the private key as a secret: anyone who has it can impersonate the certificate.

What self-signed means

You are both the issuer and the subject: the certificate is signed with its own private key, so no public Certificate Authority vouches for it. That is why browsers show a warning. It is valid for testing, local development (localhost, dev.local) and internal servers where you can distribute the certificate to the clients that need to trust it.

If you need a certificate the public internet will trust, this tool is not the right step: you need a CA-signed certificate (for example from Let’s Encrypt or a paid CA), which requires a Certificate Signing Request and domain validation that this browser tool does not perform.

What goes in the certificate

Field Notes
Subject (CN, O, C) Common Name, Organisation, Country
Subject Alternative Names Every domain or IP covered (critical!)
Public key RSA, derived from the generated private key
Issuer Same as subject, because it is self-signed
Validity Not Before / Not After (your validity days)
Key Usage digitalSignature, keyEncipherment
Extended Key Usage serverAuth, clientAuth
Basic Constraints CA:FALSE (a leaf certificate, not a CA)

Output files

  • key.pem, the private key (protect this, mode 0600)
  • cert.pem, the self-signed certificate (public, distributable)

For Nginx

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/certs/cert.pem;
    ssl_certificate_key /etc/ssl/private/key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

For Apache 2.4+

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/cert.pem
    SSLCertificateKeyFile /etc/ssl/private/key.pem
</VirtualHost>

Trusting the certificate on your own machines

To silence the browser warning on a machine you control, import cert.pem into that system’s or browser’s trust store. Do this only for certificates you generated yourself, on devices you own. Tools like mkcert automate a local CA for multiple services; this generator produces a single self-signed certificate at a time.

What self-signed is not good for

  • Public websites. Users see a warning, and many leave.
  • Third-party API integrations. Most clients reject unknown issuers.
  • Production. Full stop. Use Let’s Encrypt (free) or a paid CA for anything on the open internet.

Frequently Asked Questions

No. The key pair and the certificate are generated in your browser and stay on your device; nothing is uploaded. Still, keep the downloaded key.pem private, because anyone who holds it can impersonate the certificate.

No, if third parties will connect. Browsers show a loud warning. Use a free CA-signed certificate (Let’s Encrypt, ZeroSSL) or a paid one. Self-signed is fine for machine-to-machine within an internal network where you control both endpoints.

Historically CN held the primary domain. Modern browsers ignore CN for hostname validation and use only the SANs. Always list every hostname in the SANs; set CN to the primary one just for human-readable identification.

Yes, put *.example.com in the SANs. It covers one level of subdomains. For multiple levels, add multiple wildcards (*.example.com and *.dev.example.com).

Related Tools

A1Z26 Cipher Encoder

Encode text using the A1Z26 cipher (A=1, B=2, ... Z=26) or decode a number sequence back to letters, with customizable separator.

AES Encrypt / Decrypt

Encrypt and decrypt low-risk text with AES OpenSSL ciphers. The passphrase is hashed with SHA-256 and the Base64 output is IV plus ciphertext.

Base32 Encoder and Decoder

Encode and decode Base32 strings using the RFC 4648 alphabet. Useful for TOTP secrets, case-insensitive tokens and human-typed identifiers.

Atbash Cipher Encoder

Encode or decode text with the Atbash cipher, a Hebrew substitution that maps A-Z to Z-A. Same operation encrypts and decrypts.

Caesar Cipher Encoder

Encrypt and decrypt text using the Caesar cipher. Any shift 1-25, supports ROT13 as a special case, preserves punctuation and case.

Base64 File Encoder

Encode any file (PDF, ZIP, image, executable) to Base64 text for embedding in JSON, email, YAML or data URIs. Runs locally, no upload.