X.509 - Introduction

X.509 certificates are digital certificates used to verify the identity of entities on a network, such as websites, servers, or individuals. They play a central role in public key infrastructure (PKI) by binding a public key to a verified identity, enabling secure communication through encryption and authentication. When you connect to a secure website (HTTPS), an X.509 certificate ensures that the server is legitimate and that the data exchanged is protected.

Each certificate is part of a key pair consisting of a public key (included in the certificate) and a private key, which is kept secret by the owner. While the public key is shared to enable encryption and signature verification, the private key is used to decrypt data and create digital signatures, proving ownership and authenticity. Protecting the private key is critical, as its compromise would undermine the security of the certificate.

These certificates are issued by trusted certificate authorities (CAs) and include important information such as the subject’s identity, public key, issuer, and validity period. They are widely used in protocols like TLS/SSL, email encryption, and code signing.

 

Certificate Creator Tool

To support modern cryptographic needs, I provide a tool that allows you to create X.509 certificates using either ECC (Elliptic Curve Cryptography) or RSA algorithms, giving flexibility between performance and compatibility depending on your use case.

Download: Setup for Certificate Creator

 

 

 

 

Manual

ClassifyIt.eu

X.509 Certificate Creator

User Manual

Version 1.0

Powered by OpenSSL 3.x  ·  Delphi

 

1. Introduction

The ClassifyIt.eu X.509 Certificate Creator is a Windows desktop application for generating, signing and managing X.509 digital certificates. It supports both RSA and Elliptic Curve cryptography and can produce self-signed root CA certificates, intermediate sub-CA certificates and end-entity certificates signed by any CA you own.

All cryptographic operations are performed by OpenSSL 3.x. No internet connection is required.

Key features

• RSA key generation from 1024 to 8192 bits
• ECC key generation on NIST curves P-256, P-384 and P-521
• Self-signed certificates (Root CA or standalone)
• CA-signed and Sub-CA certificates
• Full X.509v3 extension support: Key Usage, Extended Key Usage, Subject Alternative Names, Basic Constraints, SKI, AKI
• Export as PEM certificate, PEM private key, and/or PKCS#12 bundle (.pfx)
• Certificate Store: a managed directory for all your certificates, persisted across sessions

System requirements

Operating system	Windows 10 / 11 (64-bit recommended)
Runtime	libcrypto-3-x64.dll (OpenSSL 3.x) in the application folder or system PATH
Disk space	Approximately 5 MB for the application
Permissions	Write access to the certificate store directory

 

2. Application Layout

The application window is divided into three areas:

• Top panel: application title and branding
• Tab panel (7 tabs): all configuration and management functions
• Preview panel: shows the PEM text of the last generated certificate
• Action bar: Generate Certificate, Clear/Reset and About buttons

Tab overview

Tab	Name	Purpose
1	Key	Choose RSA or ECC, generate the key pair
2	Subject DN	Enter the certificate subject (CN, O, OU, C, ...)
3	Validity	Set the certificate lifetime in days
4	Extensions	Configure v3 extensions: CA flag, Key Usage, EKU, SAN
5	Signing	Choose self-signed or CA-signed; load CA cert and key
6	Output	Set the file names for cert, key and PFX
7	Certificate Store	Browse, inspect and reuse all certificates in your store

 

3. Creating a Certificate — Step by Step

Step 1: Generate a key pair (Tab 1)

Select the key algorithm and parameters, then click Generate Key Pair.

RSA	Traditional algorithm. Choose 2048 bits for standard use, 4096 for high-security or CA keys.
ECC P-256	Modern, compact. Equivalent security to RSA-3072 with much smaller keys. Recommended for TLS.
ECC P-384	Higher security margin. Used in government and financial environments.
ECC P-521	Maximum security. Keys and signatures are larger; use for long-lived CA keys.

Note: You must generate a key pair before the Generate Certificate button becomes active.

Step 2: Fill in the Subject DN (Tab 2)

The Subject Distinguished Name identifies the certificate owner.

CN (Common Name)	For TLS: the fully qualified domain name (e.g. example.com). For a CA: a descriptive name.
O (Organization)	Your company or organisation name.
OU (Org. Unit)	Optional department or team name.
C (Country)	Two-letter ISO country code, e.g. DE, US, GB.
ST (State/Province)	Optional. Full name of the state or province.
L (Locality)	Optional. City or town name.
Email	Optional. When filled in, the output file names auto-populate on Tab 6.

Step 3: Set validity (Tab 3)

Enter the number of days the certificate should remain valid.

• End-entity certificates: 365 days (1 year) is standard. Browsers cap TLS certificates at 398 days.
• Intermediate CA certificates: 1825 days (5 years) is typical.
• Root CA certificates: 3650 days (10 years) or more.

Step 4: Configure extensions (Tab 4)

Basic Constraints

• Leave "This is a CA certificate" unchecked for end-entity (leaf) certificates.
• Check it to create a CA or Sub-CA. Set Path Length to 0 if this CA should not be allowed to sign further sub-CAs, or -1 for unlimited.

Key Usage

Tick the purposes for which the key may be used. Common selections:

• TLS server certificate: Digital Signature + Key Encipherment
• CA certificate: Key Cert Sign + CRL Sign
• Code signing certificate: Digital Signature only

Extended Key Usage

Refines the purpose further. Leave empty to omit the extension. Common selections:

• TLS server: TLS Server Authentication
• TLS mutual auth: TLS Server Authentication + TLS Client Authentication
• Code signing: Code Signing

Subject Alternative Names (SAN)

Required for TLS certificates. Enter values as comma-separated lists in each field.

• DNS Names: example.com, *.example.com
• IP Addresses: 192.168.1.10, 10.0.0.1
• Emails: This email address is being protected from spambots. You need JavaScript enabled to view it.

Note: Modern browsers require at least one DNS SAN entry for TLS certificates. The Common Name alone is no longer accepted.

Step 5: Choose signing mode (Tab 5)

Self-signed

The certificate is signed with its own private key. Use this for root CA certificates or for testing.

Signed by CA

The certificate is signed by an existing CA. You need to provide:

• CA Certificate: the PEM file of the signing CA (e.g. root_ca.crt)
• CA Private Key: the PEM private key of the CA (e.g. root_ca.key)
• Key Password: if the CA key was saved with a password, enter it here

Tip: use the Certificate Store tab to select CA files directly from your store using the "Use as CA Certificate" and "Use as CA Key" buttons.

Step 6: Set output file names (Tab 6)

All files are saved into the Certificate Store directory. Enter file names only, not full paths.

Certificate (.crt)	The PEM-encoded X.509 certificate. Share this file with others.
Private Key (.key)	The PEM-encoded private key. Keep this secret. Optionally protect it with an AES-256 password.
PKCS#12 / PFX	A bundle containing the certificate and private key in one encrypted file. Used by Windows, IIS, Java keystores.

Note: If you filled in the Email field on Tab 2, file names are pre-populated automatically.

Step 7: Generate

Click Generate Certificate in the action bar at the bottom. The application will:

1. Build the certificate structure with the configured subject, validity and extensions
2. Sign it with the selected signing mode
3. Save the output files to the Certificate Store directory
4. Refresh the Certificate Store list so the new files appear immediately
5. Display the PEM certificate in the preview panel

 

4. Certificate Store (Tab 7)

The Certificate Store is a managed directory that holds all your certificates and keys in one place. The directory path is stored in the Windows registry and restored each time the application starts.

Setting the store directory

• The default location is a Certificates sub-folder next to the application executable.
• Click Browse to choose any folder on your system.
• Click Open to view the folder in Windows Explorer.
• Type a path directly into the directory field — the list refreshes automatically.

Working with the certificate list

Select a file	Click any row to see file details and cryptographic information in the Info panel on the right.
Double-click a file	Opens the file in the default Windows application (e.g. the Certificate Viewer for .crt files).
Refresh	Re-scans the directory. Useful if you have added files externally.
Use as CA Certificate	Copies the selected certificate path to the CA Certificate field on Tab 5 and switches to the Signing tab.
Use as CA Key	Copies the selected key path to the CA Key field on Tab 5.
Delete File	Permanently deletes the selected file after confirmation.

File Info panel

When a certificate file (.crt, .pem, .cer) is selected, the application reads it and shows:

• Full file path, size and last-modified date
• Key type (RSA or ECC) and bit length or curve name
• Signature algorithm (RS256, ES384, etc.)
• Whether the file contains a private key

For encrypted key files (.key), the panel notes that a password is required. For PFX files (.pfx, .p12), use the Load buttons with the appropriate password.

 

5. Common Workflows

Create a self-signed root CA

1. Tab 1: select ECC P-384 (or RSA 4096 for legacy compatibility). Click Generate Key Pair.
2. Tab 2: fill in CN (e.g. "My Root CA"), O, C. Leave Email blank.
3. Tab 3: set 3650 days (10 years).
4. Tab 4: check "This is a CA certificate", set Path Length to -1. Key Usage: Key Cert Sign + CRL Sign.
5. Tab 5: select Self-Signed.
6. Tab 6: set names e.g. root_ca.crt and root_ca.key. Enter a strong key password.
7. Click Generate Certificate.

Create a TLS server certificate signed by your CA

1. Tab 1: select ECC P-256. Click Generate Key Pair.
2. Tab 2: CN = your server hostname (e.g. api.example.com). Fill O and C.
3. Tab 3: set 365 days.
4. Tab 4: uncheck "This is a CA certificate". Key Usage: Digital Signature + Key Encipherment. EKU: TLS Server Authentication. SAN DNS: api.example.com
5. Tab 5: select "Signed by CA". Go to Tab 7, select root_ca.crt and click "Use as CA Certificate", then select root_ca.key and click "Use as CA Key". Return to Tab 5 and enter the CA key password.
6. Tab 6: set names e.g. api.example.com.crt and api.example.com.key.
7. Click Generate Certificate.

Create an intermediate sub-CA

Same as a root CA but on Tab 5 select "Signed by CA" and load your root CA. On Tab 4 check "This is a CA certificate" and set Path Length to 0 (no further sub-CAs allowed).

 

6. Tips and Notes

• Private key passwords: always protect CA private keys with a strong password. End-entity keys can be left unencrypted if the deployment environment manages secrets separately.
• PKCS#12 export: the PFX password is separate from the key password. The PFX bundles the certificate and key in one file and protects both with the PFX password.
• Backup: copy the entire certificate store directory to a safe location. Losing a CA private key means you cannot sign new certificates with that CA.
• Serial numbers: each generated certificate receives a 160-bit random serial number compliant with RFC 5280.
• Signature algorithm: the digest algorithm is chosen automatically based on the key type and size (SHA-256 for P-256/RSA-2048, SHA-384 for P-384/RSA-3072, SHA-512 for P-521/RSA-4096+).
• OpenSSL DLL: ensure libcrypto-3-x64.dll (64-bit) or libcrypto-3.dll (32-bit) is present in the application folder or on the system PATH. The application will not start without it.

 

7. Extension Quick Reference

Key Usage values

Digital Signature	Signing data; required for TLS, code signing, email signing
Content Commitment	Non-repudiation; for legally binding signatures
Key Encipherment	Encrypting key material; required for RSA key exchange in TLS
Data Encipherment	Directly encrypting user data (rare)
Key Agreement	ECDH and DH key exchange
Key Cert Sign	Signing certificates; required for all CA certificates
CRL Sign	Signing certificate revocation lists; required for CA certificates
Encipher Only	Used only with Key Agreement
Decipher Only	Used only with Key Agreement

Extended Key Usage values

TLS Server Authentication	OID 1.3.6.1.5.5.7.3.1 — HTTPS servers
TLS Client Authentication	OID 1.3.6.1.5.5.7.3.2 — Client certificates for mutual TLS
Code Signing	OID 1.3.6.1.5.5.7.3.3 — Signing executables and packages
Email Protection	OID 1.3.6.1.5.5.7.3.4 — S/MIME email signing and encryption
Time Stamping	OID 1.3.6.1.5.5.7.3.8 — Trusted timestamp tokens
OCSP Signing	OID 1.3.6.1.5.5.7.3.9 — Signing OCSP revocation responses