Generate self-signed X.509 certificates with custom subject, validity period, and key algorithm for development use.
This tool builds a self-signed X.509 certificate in your browser: you pick the subject name (common name, organization, country, and so on), the validity period, and the key algorithm, and you get the certificate and its private key as downloadable PEM files. 'Self-signed' means the certificate is signed by the key it carries, so subject and issuer are the same name. The thing most people get wrong: nothing trusts this certificate until you install it in a device's trust store, and even then the hostname you visit must appear in its subjectAltName.
A concrete input and expected output from the current implementation.
Input
Common name: localhost; organization: Local Development; validity: 365 days; key: RSA 2048
Expected output
A PEM certificate (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) and its matching private key. The certificate decodes to: Subject CN = localhost, O = Local Development; Issuer CN = localhost, O = Local Development (identical, so self-signed); valid 2026-08-16 to 2027-08-16; public key RSA 2048.
Self-signed means the certificate is signed by the key it carries, so subject and issuer are necessarily the same. 365 days after 2026-08-16 falls on 2027-08-16 because the interval contains no February 29.
The tool creates a key pair in the algorithm you choose, then builds the certificate around it: the subject fields you entered, an issuer set to the same name, the validity window you picked, and a serial number. Signing with the certificate's own private key is what makes it self-signed, and both files come back in PEM form.
Modern browsers and TLS clients match the address in the URL against the subjectAltName extension (DNS names and IP addresses) and do not consult the CN field for hostname validation. A certificate for localhost with no SAN entry, or a SAN covering a different host, is rejected with a warning even when the certificate is well formed and present in the trust store.
Almost always one of two things: the name you typed does not match the certificate's subjectAltName (localhost and 127.0.0.1 are different names), or the certificate landed in a store the browser does not read, such as the Login keychain on macOS instead of System, or without being marked trusted. Check the SAN covers the exact host, then reinstall with trust enabled.
Not in the usual sense. Browsers and most TLS clients reject a self-signed certificate in production because it does not chain to a publicly trusted root, and no setting changes that. For public traffic you need a certificate from a public CA. For internal services, the working alternative is installing this certificate into each client's trust store.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.