Introduction
Development environments need keys and certificates for local HTTPS, mutual TLS prototypes, signing tests and format interoperability. Waiting for a production certificate authority is unnecessary for these isolated scenarios.
A self-signed certificate uses its own private key to sign its public identity statement. The utily.tools X.509 Key & Certificate Generator creates RSA material in the browser and exports common certificate, key and container formats.
Key generation followed by certificate signing
RSA key generation chooses two large random primes, constructs a modulus and derives public and private exponents. The public key can be distributed; the private factors and exponent must remain secret. A certificate embeds the public key and descriptive fields.
For a self-signed certificate, subject and issuer are normally the same and the new private key signs the certificate. This proves internal consistency, not external trust. Clients trust it only after explicit installation or pinning.
Technical foundations and behavior
Generation defines a positive serial number, validity period, subject attributes and extensions before signing with a suitable hash such as SHA-256. The private operation can be CPU-intensive, especially for larger RSA moduli.
Key sizes and entropy
RSA 2048 remains a common interoperability baseline; larger keys increase computation and file size. Cryptographically secure randomness is mandatory because weak primes compromise every operation performed by the key.
Extensions and purpose
A development server certificate should include its DNS names or IP addresses in SAN and use constraints appropriate to an end entity. Marking every self-signed certificate as a CA with keyCertSign can grant more authority than intended.
Export formats
PEM wraps DER as Base64. PKCS#8 is a general private-key container. PFX/P12 can bundle private keys and certificates under password-based protection. JWK represents key parameters as Base64url fields for web protocols.
Real-world applications
Local HTTPS
A developer creates a short-lived certificate for localhost and trusts it only on the development machine.
Format compatibility testing
A QA workflow exports the same key as PEM, PKCS#8, JWK and PFX to verify import behavior across libraries.
Mutual TLS prototype
A private test CA and separate leaf certificates model client and server authentication before production PKI integration.
Standards and deeper technical reference
Key pair, CSR, issued certificate and self-signing
A private key is the secret signing or decryption material; SubjectPublicKeyInfo is its public counterpart. A PKCS #10 certification request defined by RFC 2986 contains a subject name, public key and optional attributes, signed by the requester to prove possession. A CA validates the request and chooses the certificate serial, validity, issuer, extensions and signature.
A self-signed certificate uses the same entity as subject and issuer and signs with its own private key. It can be a deliberately distributed trust anchor or merely a development certificate. Self-signing does not create trust: clients must authenticate and install the trust anchor through a separate secure process.
Algorithms, key sizes and extensions
RSA 2048 remains a common minimum interoperability choice; larger RSA keys increase signature and generation cost. ECDSA P-256 provides roughly 128-bit classical security with smaller keys and signatures when the ecosystem supports it. The certificate signature hash should be SHA-256 or stronger and compatible with the selected key algorithm.
A leaf TLS certificate normally sets CA=false, excludes keyCertSign, contains the intended DNS or IP identities in subjectAltName, and includes suitable key usage and extended key usage. A CA certificate requires basicConstraints CA=true and keyCertSign. Copying one extension template across both roles is dangerous.
| Artifact | Contains | Typical encoding |
|---|---|---|
| Private key | Secret key material | PKCS #8 PEM/DER; optionally encrypted |
| Public key | SubjectPublicKeyInfo | PUBLIC KEY PEM/DER |
| CSR | Subject, public key, attributes and proof signature | PKCS #10 PEM/DER |
| Certificate | Issuer assertion binding identity to public key | X.509 DER or CERTIFICATE PEM |
| PKCS #12 | Keys and certificate bags | Binary PFX/P12 protected by password-based mechanisms |
Serial numbers, validity and private-key protection
RFC 5280 requires a positive serial number no longer than 20 octets and unique for each certificate issued by a CA. Generate serials with a CSPRNG or a collision-safe issuer process. Validity should be as short as operationally reasonable, with UTC handling and clock skew considered.
Generate private keys locally where possible, encrypt exported keys with a strong passphrase and modern protection, restrict file permissions and never log them. PKCS #12 interoperability can force legacy algorithms; treat the container password as transport protection rather than a substitute for secure key storage.
Primary specifications and references
- RFC 5280: Internet X.509 PKI ProfileIETF / RFC Editor
- RFC 2986: PKCS #10 Certification Request SyntaxIETF / RFC Editor
- NIST SP 800-57 Part 1 Rev. 5NIST
Conclusion
Certificate generation joins secure key creation, explicit identity fields, extensions and a digital signature. Self-signing is convenient for controlled testing but does not create public trust.
My recommendation is short-lived, narrowly scoped development certificates and carefully protected private keys. Use the utily.tools generator for test material, then inspect and match the results with the viewer and validator covered in the related articles.