ClassifyIt

ClassifyIt.eu X.509 Certificate Creator

User Manual

Version 1.2

Powered by OpenSSL 3.x and Delphi

Download: CertCreator/setup-CertCreator(v1.2).exe

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

Changes from Version 1.1 to 1.2

Fixed certificate validity calculation so Valid Till is based on the current signing time, not the Unix epoch.
Added a separate Generate CSR workflow that creates a private key and certificate signing request.
Added CSR inspection and CSR signing from the Certificate Store.
Added loading certificate attributes from selected CSR and certificate files in the Certificate Store.
Added SAN normalization and validation for certificate generation, CSR generation, CSR signing, and imported CSR/CRT attributes.
Added overwrite warnings before generated output files are replaced.
Added guided CA certificate/key selection when signing a CSR.
Added immediate password testing for encrypted CA private keys and store key testing.
Changed .key export to the common standard: private key only.
Added password visibility toggles for CA key, private key export, and PFX passwords.
Updated ECC/RSA Key Usage defaults.

X.509 Introduction

X.509 certificates are digital certificates used to verify the identity of entities on a network, such as websites, servers, services, users, or certificate authorities. They are a central part of public key infrastructure (PKI): a certificate binds a public key to an identity and is signed by an issuer so that other systems can verify the binding.

Each certificate belongs to a key pair. The public key is included in the certificate and can be shared. The private key must remain secret and is used to create digital signatures or decrypt data, depending on the certificate purpose. If the private key is compromised, the certificate can no longer be trusted.

Certificates contain attributes such as subject, issuer, serial number, validity period, public key, and X.509 extensions. They are used by TLS/HTTPS, mutual TLS, S/MIME email protection, code signing, OCSP, and other security protocols.

1. Introduction

The ClassifyIt.eu X.509 Certificate Creator is a Windows desktop application for creating, signing, exporting, and inspecting X.509 certificates. It supports RSA and Elliptic Curve Cryptography (ECC), self-signed certificates, CA-signed certificates, root CA certificates, intermediate CA certificates, and end-entity certificates.

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

Key Features

RSA certificates with selectable key sizes: 2048, 3072, 4096, and 8192 bit.
ECC certificates using NIST curves P-256, P-384, and P-521.
Automatic key generation during certificate creation.
Self-signed certificates for root CAs or standalone test certificates.
CA-signed certificates using a CA certificate and CA private key from the certificate store.
Combined CA key PEM support: if the CA private key file also contains the CA certificate, the separate CA certificate field is filled automatically.
CA validation: the application checks that the selected issuer certificate is actually a CA certificate.
X.509v3 extensions: Basic Constraints, Key Usage, Extended Key Usage, Subject Alternative Names, Subject Key Identifier, and Authority Key Identifier.
Export as PEM certificate, PEM private-key bundle, and optional PKCS#12/PFX.
Generate a certificate signing request (CSR) and matching private key for external CA signing.
Sign a stored CSR with a CA certificate and CA private key from the certificate store.
Load subject and extension attributes from a stored CSR or certificate into the Certificate tab.
Normalize and validate SAN input before creating certificates or CSRs.
Private-key PEM files follow the common convention and contain only the private key, encrypted or clear text.
Certificate Store with a persistent, user-selectable directory.
Certificate and key inspection, including subject, issuer, validity, key type, signature algorithm, CA flag, and private-key presence.
About dialog shows the version number from the executable version resource.

System Requirements

Windows 10 or Windows 11.
64-bit runtime recommended.
libcrypto-3-x64.dll and libssl-3-x64.dll in the application folder or available on the system PATH.
Write access to the configured certificate store directory.

2. Application Layout

The application uses three main tabs and a bottom action bar.

Tab 1: Certificate

This is the main certificate creation tab. It contains:

Key Settings: choose RSA or ECC and the key size or curve.
Certificate Attributes: enter subject fields such as CN, O, OU, C, ST, L, and email.
Validity: enter the certificate lifetime in days.
Basic Constraints: choose whether the certificate is a CA certificate and set the path length.
Key Usage and Extended Key Usage: define how the certificate may be used.
Subject Alternative Names: enter DNS names, IP addresses, and email SANs.
CA Certificate and Key: choose self-signed or CA-signed mode.

The private key is generated automatically when you click Generate Certificate. Manual key generation is still available as a quick test/action, but the final certificate generation always creates a fresh key that matches the current RSA/ECC settings.

Tab 2: Output

The Output tab contains file names and export options:

Certificate file name, for example server.crt.
Private-key file name, for example server.key.
Optional private-key password.
Optional PKCS#12/PFX file name, for example server.pfx.
Optional PFX password and friendly name.
CSR file name, for example server.csr.

When you manually enter or change the email address on the Certificate tab, the certificate, key, PFX, CSR, and friendly-name fields on the Output tab are updated from that email address. Loading attributes from an existing CSR or certificate does not change the output file names.

All generated files are saved into the configured Certificate Store directory. Enter file names only, not full paths. If a selected output file already exists, the application warns before overwriting it.

Tab 3: Certificate Store

The Certificate Store tab manages the folder used by the application:

Shows the full certificate store path.
Lets you browse for a different store folder.
Opens the folder in Windows Explorer.
Lists certificates, keys, PEM files, and PFX/P12 bundles in the store.
Shows readable certificate attributes and file metadata for the selected file.
Shows the PEM text of a selected PEM certificate or key.
Tests selected .key files, prompting for the password when required.
Loads attributes from selected .csr, .crt, .cer, or PEM certificate files into the Certificate tab.
Signs selected .csr files using the configured CA certificate and CA private key.
Deletes selected files after confirmation.

The store directory is persisted in the Windows registry and restored when the application starts.

3. Creating a Certificate

Step 1: Select the Key Type

Choose RSA or ECC in the Key Settings group.

RSA is widely compatible and useful for legacy systems. RSA 2048 is acceptable for many end-entity certificates. RSA 4096 is common for CA certificates or longer-lived internal use.

ECC produces smaller keys and signatures with strong security. P-256 is a good default for TLS server certificates. P-384 is suitable for higher-security CA certificates. P-521 is available when a larger security margin is required.

You do not need to generate a key manually before creating a certificate. The application generates a fresh key automatically during certificate creation.

Step 2: Enter Certificate Attributes

Fill in the subject fields:

CN: Common Name. For TLS, usually the server host name. For a CA, a descriptive CA name.
O: Organization.
OU: Organizational Unit.
C: two-letter country code, for example DE, US, or GB.
ST: State or province.
L: Locality or city.
Email: email address. When entered manually, this also updates the default output file names on the Output tab.

At least one identity field such as CN, SAN, or email must be provided.

Step 3: Set Validity

Enter the number of days the certificate should be valid. The application checks that the validity is at least one day and does not exceed the supported maximum.

Typical values:

TLS server certificate: 365 days. Public browsers have stricter limits for publicly trusted TLS certificates.
Intermediate CA: about 1825 days, depending on your policy.
Root CA: 3650 days or more for private/internal PKI, depending on your policy.

The application prevents creating a certificate where Valid Till would be before Valid From.

Step 4: Configure Basic Constraints

Leave This is a CA certificate unchecked for normal end-entity certificates.

Check it when creating a root CA or intermediate CA. The application automatically ensures CA certificates include the key usages required for certificate signing.

Path Length controls whether this CA may issue further CA certificates:

0: this CA may issue end-entity certificates but no further sub-CAs.
1: this CA may issue one further CA level.
-1: no explicit path length limit is added.

Step 5: Configure Key Usage

Common combinations:

TLS server: Digital Signature and Key Encipherment.
TLS client: Digital Signature, often with TLS Client Authentication EKU.
CA certificate: Key Cert Sign and CRL Sign.
Code signing: Digital Signature.

The application applies conservative defaults where appropriate, but you should still select usages according to the purpose of the certificate.

Step 6: Configure Extended Key Usage

Extended Key Usage refines the certificate purpose:

TLS Server Authentication: HTTPS/TLS server certificates.
TLS Client Authentication: client certificates for mutual TLS.
Code Signing: signing software packages or executables.
Email Protection: S/MIME email signing or encryption.
Time Stamping: timestamp services.
OCSP Signing: OCSP responder certificates.

Step 7: Configure Subject Alternative Names

For TLS certificates, Subject Alternative Names are required. Enter values as lists separated by commas, semicolons, spaces, or line breaks. Each field is normalized to a comma-separated list before generation, and each entry is validated for its SAN type:

DNS names: example.com, www.example.com
IP addresses: 192.168.1.10, 10.0.0.1
Email addresses: admin@example.com, support@example.com

You may paste OpenSSL-style entries such as DNS:example.com, DNS:www.example.com or IP Address:192.168.1.10; the prefixes are stripped in the UI and added again correctly when the certificate or CSR is built.

Invalid entries are rejected before a certificate or CSR is generated. For example, a DNS value containing characters outside the supported DNS name syntax is not accepted.

Modern TLS clients normally ignore the Common Name for host matching and require DNS or IP SAN entries.

Step 8: Choose Signing Mode

Select Self-Signed to create a certificate signed by its own private key. Use this for root CA certificates or simple test certificates.

Select Signed by CA to create a certificate signed by an existing CA. The CA certificate and CA private key must be stored in the configured Certificate Store folder.

When selecting CA files:

The edit boxes show only the file name.
The application resolves the file name inside the configured Certificate Store folder.
Files outside the Certificate Store are not silently used for signing.
The selected CA certificate is checked to ensure it is actually a CA certificate.
The selected CA certificate and CA private key must match.

If the CA private key file is a combined PEM bundle containing both the CA certificate and the CA private key, the application uses the embedded certificate automatically and disables the separate CA certificate field.

Step 9: Set Output Options

On the Output tab, choose the generated file names.

Certificate file:

PEM-encoded X.509 certificate.
Usually saved as .crt, .cer, or .pem.
This file can be shared.

Private-key file:

PEM private-key file.
Newly generated key files contain only the private key, encrypted or clear text.
Use the certificate file or PFX/P12 bundle when certificate metadata must travel with the key.
Protect this file carefully.
Use a password for CA private keys.

PKCS#12/PFX:

Optional bundle containing certificate and private key.
Commonly used by Windows, IIS, browsers, and Java tooling.
Protected by the PFX password.

CSR:

Created with the Generate CSR button together with the matching private key.
Contains the subject and public key, but not the private key.
Use this when another CA or another CertCreator instance should sign the certificate.

Step 10: Generate

Click Generate Certificate.

The application will:

Generate a fresh key pair using the currently selected RSA/ECC settings.
Normalize and validate SAN entries.
Build the certificate subject, validity, and extensions.
Sign the certificate as self-signed or with the selected CA.
Save the selected output files into the Certificate Store.
Refresh the Certificate Store list.
Release the generated private key from the builder object after export.

Generate a CSR Instead

Click Generate CSR when you want to create a certificate signing request instead of an issued certificate.

The application will:

Generate a fresh key pair using the currently selected RSA/ECC settings.
Normalize and validate SAN entries.
Build a CSR from the subject fields on the Certificate tab.
Save the private key to the configured key file name.
Save the CSR to the configured CSR file name.
Refresh the Certificate Store list.
Release the generated private key from the builder object after export.

The CSR contains the subject and public key. CertCreator-generated CSRs also include requested extensions for SAN, Basic Constraints, Key Usage, and Extended Key Usage from the Certificate tab. The CSR does not contain the private key or validity period. The signing CA still decides which requested extensions are accepted into the final certificate.

4. Certificate Store

The Certificate Store is a managed directory for generated and reusable certificate files. The configured path is saved in:

HKEY_CURRENT_USER\Software\ClassifyIt\CertCreator

Default location:

Certificates folder next to the application executable.

Changing the Store Directory

Use Browse to select a different directory. The full folder path is shown in the store path edit box. The choice is saved and restored the next time the application starts.

The Certificate Store is also used as a safety boundary for signing. CA certificate and CA private-key file names are resolved inside this folder.

Inspecting Files

Select a file in the store list to show:

File name and full path.
File size and last modified date.
Subject and issuer.
Valid From and Valid Till.
Whether the certificate is a CA certificate.
Key type and key size or curve.
Signature algorithm.
Whether the file contains a private key.
Additional OpenSSL certificate details where available.

Use Show PEM to display the PEM text of a selected text PEM file. PFX/P12 files are binary bundles and are not shown as PEM.

Use Test Key on a selected .key file to verify that it can be opened. If the key is encrypted, the application prompts for the password and reports whether it is correct.

Use Load Attrs on a selected .csr, .crt, .cer, or PEM certificate file to copy the subject fields, SAN values, CA flag, Key Usage, and Extended Key Usage into the Certificate tab. The imported SAN fields are normalized immediately. Loading attributes does not change the output file names on the Output tab.

Use Sign CSR on a selected .csr file to issue a certificate. Before signing, the application shows a confirmation explaining that the CSR provides the subject, public key, and may include requested extensions. The issued certificate uses the current Certificate tab settings for validity, CA flag, Key Usage, Extended Key Usage, and SAN values.

If the CA certificate or CA private key is not already selected, the application prompts you to select them from the Certificate Store. If the CA key is encrypted, the password is requested and tested immediately.

The generated certificate is saved to the certificate output file name on the Output tab.

If the output certificate file already exists, the application asks before overwriting it.

Opening and Deleting Files

Double-click a file to open it in the default Windows application.

Use Delete to remove the selected file. This permanently deletes the file after confirmation.

5. Common Workflows

Create a Self-Signed Root CA

On the Certificate tab, select ECC P-384 or RSA 4096.
Enter a CA subject, for example CN My Root CA, plus organization and country.
Set validity, for example 3650 days.
Check This is a CA certificate.
Set Path Length to -1 for no explicit limit, or a smaller value according to your policy.
Ensure Key Cert Sign and CRL Sign are selected.
Select Self-Signed.
On the Output tab, set names such as root_ca.crt and root_ca.key.
Enter a strong private-key password.
Click Generate Certificate.

Create an Intermediate CA

Select ECC P-384 or RSA 4096.
Enter the intermediate CA subject.
Check This is a CA certificate.
Set Path Length to 0 if this intermediate should not issue further sub-CAs.
Select Signed by CA.
Select the root CA private-key bundle. If it contains the root CA certificate, the CA certificate field is filled automatically.
Enter the root CA key password if required.
Set output names such as intermediate_ca.crt and intermediate_ca.key.
Click Generate Certificate.

Create a TLS Server Certificate Signed by Your CA

Select ECC P-256 or RSA 2048/3072.
Enter CN as the server host name, for example api.example.com.
Add DNS SAN api.example.com.
Set validity, for example 365 days.
Leave This is a CA certificate unchecked.
Select Key Usage: Digital Signature and Key Encipherment.
Select Extended Key Usage: TLS Server Authentication.
Select Signed by CA.
Choose the CA private-key bundle or select the CA certificate and CA key separately.
Enter the CA key password if required.
Set output names such as api.example.com.crt, api.example.com.key, and optionally api.example.com.pfx.
Click Generate Certificate.

Create an S/MIME Email Certificate

Select ECC P-256 or RSA 2048/3072.
Enter the user's email address.
Add the same address under SAN Emails.
Select Extended Key Usage: Email Protection.
Select a CA for signing or choose Self-Signed for testing.
Set output names and generate the certificate.

Create a Certificate Signing Request

On the Certificate tab, select the key type and parameters, for example ECC P-256 or RSA 2048.
Enter the subject fields, for example CN, organization, country, and email.
Fill SAN, Key Usage, Extended Key Usage, and CA settings if they should be requested in the CSR.
On the Output tab, set the private-key file name, for example server.key.
Set the CSR file name, for example server.csr.
Enter a private-key password if the key should be encrypted.
Click Generate CSR.

The application normalizes and validates SAN entries, creates a fresh key pair, saves the private key to the .key file, and saves the certificate signing request to the .csr file. The CSR contains the subject and public key, plus requested extensions for SAN, Basic Constraints, Key Usage, and Extended Key Usage. It does not contain the private key or validity period.

Sign a CSR to Create a CRT

On the Certificate tab, set the certificate attributes that the CA should apply: validity, CA flag, path length, Key Usage, Extended Key Usage, and SAN values.
Select Signed by CA.
Select the CA private key. If the key contains the CA certificate, the CA certificate field is filled automatically.
If needed, select the CA certificate separately.
Enter the CA key password when prompted.
On the Output tab, set the certificate output file name, for example server.crt.
Open the Certificate Store tab.
Select the .csr file.
Review the CSR details and the effective signing settings shown in the memo.
Optionally click Load Attrs first to copy the CSR subject and requested extensions into the Certificate tab.
Click Sign CSR.
Confirm that the current Certificate tab settings should be used.

The application normalizes and validates the current SAN fields, verifies the CSR signature, checks the CA certificate and private key, signs the CSR, and writes the issued certificate to the .crt output file. It does not create a .key or .pfx from a CSR because the CSR does not contain the requester's private key.

6. Security Notes

Protect CA private keys with a strong password.
Store CA private keys in a protected folder with restricted Windows permissions.
Back up the Certificate Store securely. Losing a CA private key means you cannot issue new certificates from that CA.
If a CA private key is compromised, certificates issued by that CA should be considered untrusted.
Private-key PEM files generated by this application contain only the private key. This is the common .key convention; protect these files carefully.
After generation and export, the application releases the generated private key from the builder object. This reduces how long private key material remains in process memory.
Delphi managed strings and OpenSSL internal allocations cannot provide an absolute guarantee that every previous byte is immediately overwritten in memory.
For high-security CA operations, consider generating and storing CA private keys on dedicated secure hardware or in an HSM.
Publicly trusted TLS certificates should be issued by a public CA, not by a private self-signed CA.

7. Extension Quick Reference

Key Usage

Digital Signature: signing data; commonly required for TLS, code signing, and email signing.
Content Commitment: non-repudiation use cases.
Key Encipherment: encrypting key material; common with RSA TLS certificates.
Data Encipherment: direct encryption of user data; rarely used.
Key Agreement: ECDH/DH key agreement.
Key Cert Sign: signing certificates; required for CA certificates.
CRL Sign: signing certificate revocation lists; required for CA certificates that issue CRLs.
Encipher Only: modifier for Key Agreement.
Decipher Only: modifier for Key Agreement.

Extended Key Usage

TLS Server Authentication: 1.3.6.1.5.5.7.3.1
TLS Client Authentication: 1.3.6.1.5.5.7.3.2
Code Signing: 1.3.6.1.5.5.7.3.3
Email Protection: 1.3.6.1.5.5.7.3.4
Time Stamping: 1.3.6.1.5.5.7.3.8
OCSP Signing: 1.3.6.1.5.5.7.3.9

8. Troubleshooting

The application does not start

Check that the required OpenSSL 3.x DLLs, libcrypto-3-x64.dll and libssl-3-x64.dll, are present in the application folder or on the system PATH.

The CA certificate field is disabled

The selected CA private-key file contains an embedded CA certificate. The application can use that certificate directly.

The selected certificate is rejected as CA

The certificate does not contain CA basic constraints or is not accepted by OpenSSL as a CA certificate. Select a real CA certificate.

The CA key does not match the CA certificate

Select the private key that belongs to the selected CA certificate. A CA certificate and private key must be a matching pair.

A TLS certificate is rejected by a browser or client

Check that the certificate has a DNS or IP Subject Alternative Name matching the server name. The Common Name alone is usually not enough.

SAN input is rejected

Check the DNS, IP, and email SAN fields for malformed values. The fields accept comma, semicolon, space, tab, and line-break separators, but every resulting entry must be valid for that SAN type.

A file does not show certificate attributes

The file may be encrypted, binary, malformed, or may not contain a certificate block. Use Show PEM for text PEM files or inspect PFX/P12 bundles with external certificate tools.

56075 Koblenz, Germany

This email address is being protected from spambots. You need JavaScript enabled to view it.