A complete guide to generating self-signed X.509 certificates with RSA or ECDSA, why PKCS#12 export is RSA-only, and real-world use cases for self-signed certificates.
Launch the SSL Self-Signed Certificate Tool →The SSL Self-Signed Certificate Tool generates a complete X.509 v3 self-signed digital certificate, along with its matching private key, entirely within your browser. You fill in standard certificate subject fields (Common Name, Organization, Organizational Unit, Locality, State, Country, Email, and optional Subject Alternative Names), choose a cryptographic algorithm and key size, select a signature hash algorithm, and set a validity period, then generate downloadable PEM-format files and, for RSA keys specifically, a password-protected PKCS#12 (.p12) bundle.
This is a genuinely complex cryptographic operation happening entirely client-side, not a simulation or a simplified approximation — the certificates produced are real, standards-compliant X.509 certificates that can be installed and used by actual servers, browsers, and operating systems for development, testing, and internal infrastructure purposes.
Every SSL/TLS certificate is "signed" by some authority, cryptographically vouching for the binding between a public key and an identity (like a domain name or organization). For a publicly trusted website, that signature comes from a Certificate Authority (CA) like Let's Encrypt or DigiCert, whose own signing key is pre-installed and trusted by every major browser and operating system by default.
A self-signed certificate is instead signed by its own private key — the certificate vouches for itself, rather than relying on any third-party CA. This makes self-signed certificates completely unsuitable for a public-facing website that needs ordinary visitors' browsers to trust it automatically, since no browser trusts a certificate's self-signature by default. But for internal development servers, testing environments, home lab infrastructure, internal corporate tools not exposed to the public internet, or any situation where you yourself control the systems that will connect to the server and can manually install the certificate as trusted, self-signed certificates provide the exact same encryption strength as a CA-signed certificate, just without the automatic, built-in trust relationship.
This tool supports two fundamentally different public-key cryptography algorithms: RSA (with selectable 2048, 3072, or 4096-bit key sizes) and ECDSA (Elliptic Curve Digital Signature Algorithm, with selectable P-256, P-384, or P-521 curves). Both are legitimate, widely used, cryptographically sound choices for modern certificates, but they have different practical trade-offs.
RSA remains the most universally compatible choice, supported by essentially every system, server, and client that has ever handled SSL/TLS certificates, including some genuinely old or embedded systems that may not support newer elliptic curve cryptography at all. Its main drawback is that RSA keys need to be considerably larger (2048 bits minimum for any modern security margin) to achieve a given level of cryptographic strength compared to elliptic curve alternatives.
ECDSA achieves equivalent or stronger cryptographic security with dramatically smaller key sizes — a 256-bit ECDSA key provides roughly comparable security to a 3072-bit RSA key — which translates to faster certificate operations, smaller certificate file sizes, and reduced computational overhead, particularly valuable at scale. Its main drawback is that ECDSA support, while now extremely widespread in all modern browsers and servers, is somewhat newer and can occasionally be missing from legacy or specialized systems that RSA would still support without issue.
This tool is directly transparent about a genuine technical gap rather than hiding it: the password-protected PKCS#12 (.p12) bundle export option is only available when using RSA keys, and is deliberately disabled with an on-page explanation when ECDSA is selected. This isn't an arbitrary restriction; it reflects a real, confirmed limitation in the available browser-compatible cryptography libraries.
Generating a real X.509 certificate and PKCS#12 container from scratch requires substantial, carefully-implemented cryptographic library support, which this tool gets from two separate, purpose-built libraries: node-forge (despite its name, a pure JavaScript library that runs fine in browsers) handles RSA key generation and PKCS#12 packaging, while @peculiar/x509, built on top of the browser's native Web Crypto API, handles ECDSA key generation and certificate signing. Research specifically into node-forge's own documented capabilities confirmed that its PKCS#12 export function only accepts RSA private keys as input — there is no reliably working, well-maintained JavaScript library available that can package an ECDSA key into a correct PKCS#12 container directly in a browser environment.
Rather than silently producing a broken or corrupted .p12 file for ECDSA keys, or quietly limiting the entire tool to RSA only and losing the genuine benefits of offering ECDSA, the honest solution was to support both algorithms fully for certificate generation and PEM export, while being explicit that PKCS#12 packaging specifically remains an RSA-only feature until a reliable browser-compatible library for ECDSA PKCS#12 packaging becomes available.
During development, this tool initially failed to load at all, producing browser console errors like "disallowed MIME type" and CORS-related failures when attempting to load the ECDSA library. Investigating the actual browser console error (rather than guessing) revealed two separate mistakes: the specific file path requested from the CDN didn't actually exist in the published package version being referenced, and the loading method used (<script type="module"> with an ES module import statement) didn't match how that particular library was actually designed to be loaded, which expects a plain, old-fashioned global <script> tag instead.
The fix involved correcting the exact published version number and file path based on the library's own official documentation, and switching from an ES module import to a plain script tag that attaches the library to a global variable, which is a cleaner, dependency-order-respecting approach anyway, since a normal script tag blocks execution of subsequent scripts until it finishes loading, avoiding any race condition between the library loading and the page's own code trying to use it.
This episode is worth including here specifically because it illustrates something genuinely important about any tool combining multiple third-party libraries: library loading mistakes are common, often produce confusing error messages, and are best diagnosed by reading the actual browser console error text rather than guessing at the cause.
Self-signed certificates serve several genuinely common and legitimate purposes in real IT and development work, despite not being suitable for public websites:
In every one of these cases, the key distinguishing factor is that whoever will be connecting to the certificate-protected service is either the same person generating the certificate, or someone within an organization that can coordinate manually trusting it — the self-signed trust model works precisely because the normal "automatic trust by strangers" problem simply doesn't apply.
All key generation, certificate signing, and file packaging happen entirely within your browser using the Web Crypto API and the node-forge/@peculiar/x509 libraries loaded from a public CDN. Your private key, certificate details, and PKCS#12 password are never transmitted anywhere, logged, or stored — the only network activity involved is the one-time loading of the cryptography libraries themselves at the moment the page loads, which is a library file fetch, not a data submission of any kind.
Because the private key generated here never leaves your browser, there is no possibility of it being intercepted in transit or stored anywhere outside your own device, which is a meaningful security property for a tool whose entire purpose is generating sensitive cryptographic material.
No. Self-signed certificates are never automatically trusted by browsers or operating systems, regardless of how they were generated. You would need to manually install and trust the certificate on each system that needs to connect without a security warning, which is appropriate for development, testing, or controlled internal environments, not public-facing websites.
This is a confirmed limitation in available browser-compatible cryptography libraries, not an arbitrary restriction. The PKCS#12 packaging library this tool uses only supports RSA keys. Full detail is in the PKCS#12 limitation section above.
RSA offers the broadest possible compatibility, including with older or unusual systems. ECDSA offers equivalent security with smaller, faster keys and is well-supported by all modern systems. If you need a .p12 bundle, RSA is currently your only option with this tool.
No. Production, public-facing websites need a certificate signed by a trusted Certificate Authority (such as the free Let's Encrypt service) so that ordinary visitors' browsers trust it automatically without security warnings. Self-signed certificates are appropriate for development, testing, and controlled internal use only.