X509 certificate generator

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from X509 certificate generator

The X509 certificate generator creates a self-signed certificate and a matching RSA key pair for inspection and controlled testing. Supply a common name, validity duration in days, organization and location information, contact email, and any subject alternative names. The RSA bits and private-key passphrase controls govern the key generation and exported private-key protection. Refresh Certificate produces separate certificate, fingerprint, public-key, and private-key outputs. Self-signing means the certificate is signed by its own key; it does not establish public trust or prove control of the names supplied. Inspect the generated extensions and test the exact receiving application before using the result in a certificate workflow.

Guide updated October 13, 2026

How to use this tool

1. Enter a demonstration common name, the validity duration in days, and the subject details relevant to your test.
2. Enter subject alternative names one per line, using plain names such as example.com or an IP address rather than DNS: prefixes.
3. Choose an RSA key size compatible with the receiving application and set an optional passphrase for the private-key export.
4. Press Refresh Certificate. Review the certificate, fingerprint, public key, and private key as separate outputs, then test the certificate and matching private key in the intended environment.

SEE IT IN PRACTICE

A worked example

Common name example.com; SAN example.com; duration 30 days; RSA bits 2048

A self-signed PEM certificate, its fingerprint, and a matching public/private RSA key pair.

The serial number, keys, fingerprint, and validity timestamps vary with generation. Verify the requested name and actual validity dates in the resulting certificate rather than expecting one fixed PEM string.

Inspect the actual certificate profile

This implementation sets both issuer and subject from the supplied subject fields, sets the start of validity at generation, and calculates the end from the chosen day count. Its fixed extensions include basicConstraints with CA=true and several key-usage permissions. That is not the same profile as a narrowly configured end-entity TLS certificate. Inspect those extensions and the signature algorithm with the receiving parser; selecting a key size or supplying a hostname does not change the entire certificate policy.

Names, trust, and the matching key answer different questions

Alternative names identify the names or addresses a certificate is intended to cover. A trust decision concerns which signer a client accepts. The private key proves possession of the key corresponding to the certificate. All three must fit the intended connection, and none is established by copying a PEM file alone. Keep the matching certificate and key together in your records, retain private material securely, and verify the certificate actually presented by a test service after import. Generating a replacement creates new material and does not modify an already-running service.

When this tool is useful

• Create a local TLS test certificate
• Inspect X.509 fields
• Test certificate-import behavior

Tips for a better result

• Self-signing does not make a certificate publicly trusted or prove ownership of the names it contains.
• Protect the private key and any passphrase separately from files intended for public distribution.
• The displayed fingerprint is a SHA-1 digest of the certificate, not a public-key fingerprint. Compare the same digest and the same object when checking a value elsewhere.

Frequently asked questions