X Certificate and Key Management
XCA is a graphical application for creating and managing X.509 certificates, certificate requests, private keys, and certificate revocation lists. It wraps the same OpenSSL operations covered in the certificates section of this series in a GUI that makes the CA workflow considerably more navigable, particularly for operations that are done infrequently enough that the command line syntax is not committed to memory.
XCA is not a replacement for the command line CA setup covered in the CA section of this series. It is a companion tool: useful for certificate inspection, CSR review, template-based certificate issuance, and maintaining a visual overview of the certificate hierarchy. For automated or scripted operations, the command line remains the right approach.
Installation
XCA is available in the standard Ubuntu repositories:
sudo apt install xca
Verify the version:
xca --version
The current version on Kubuntu 24.04 is XCA 2.x. The interface has been stable for several versions.
The XCA database
XCA stores all certificates, keys, requests, and templates in a single encrypted database file. This database is the most important thing to understand about XCA’s architecture: it is not just a viewer for certificate files on disk, it is a self-contained encrypted store.
For this setup, the XCA database lives on the encrypted USB safe storage rather than in the home directory. This keeps all certificate and key material together in one physically secured location.
Create the database on the encrypted storage:
Open XCA. Go to File > New Database. Navigate to /media/$USER/SafeStorage/Certificates/ and create the database there:
/media/username/SafeStorage/Certificates/xca-database.xdb
Set a strong database password when prompted. Use a six-word Diceware passphrase and store it in KeePassXC. This password protects the database file itself in addition to the LUKS encryption of the USB drive. Two layers of encryption for the most sensitive material.
On subsequent sessions, open the database from the safe storage:
File > Open Database > /media/username/SafeStorage/Certificates/xca-database.xdb
Initial configuration
Open File > Options before doing anything else.
Subject options
Remove all mandatory subject entries except commonName. The mandatory fields list forces you to fill in certain Distinguished Name components on every certificate. For a self-hosted CA where you control the templates, enforcing these at the UI level is unnecessary friction. The templates handle sensible defaults.
If your organisation has a consistent DN structure you want to enforce, leave the relevant fields. For a personal setup, commonName only is the right default.
Default algorithms
Set the default hash algorithm to SHA 512. The source material recommends SHA 256, which remains acceptable, but SHA 512 is the stronger choice and has no meaningful performance cost on modern hardware.
Set the allowed string type to PKIX UTF8. This ensures certificate subject fields are encoded correctly for modern certificate consumers.
Key defaults
Set the default key type to EC with curve prime256v1 (NIST P-256) or secp384r1 (NIST P-384). EC keys are smaller, faster, and considered stronger than RSA at equivalent security levels. The source material references RSA as the default, which is now dated guidance.
If you need RSA keys for compatibility with specific legacy systems, set the default size to 4096.
Importing existing certificates and keys
If you have already generated certificates and keys using the command line (as covered in the CA and certificates sections), import them into XCA to maintain a complete picture of your CA hierarchy.
Importing the CA certificates
Go to the Certificates tab. Click Import and select the CA certificate files:
- Root CA certificate
- Intermediate CA certificate(s)
XCA will recognise the CA hierarchy and display the certificates in a tree showing the chain of trust.
Importing the CA private keys
Go to the Private Keys tab. Click Import and select the CA private key files. XCA will associate the keys with the corresponding certificates automatically.
For the root CA private key, import it only during active CA sessions under Tails with networking disabled. Do not leave the root CA private key imported in a database that lives on a drive connected to a networked machine. Import it when needed and remove it when the session ends.
Importing CSRs
Certificate signing requests can be imported for review and signing. Go to the Certificate Signing Requests tab and click Import.
Templates
Templates are the main time-saving feature in XCA. A template defines the default values and extensions for a certificate type, so you do not have to configure them from scratch each time.
Create templates for each certificate type in regular use. These templates should match the OpenSSL configuration used in the CA section.
Opening the template editor
Go to the Templates tab and click New Template. Each template has an extensions tab where the certificate purpose is defined. The settings here map directly to the X.509 extensions set in OpenSSL configurations.
TLS server certificate template
Name: TLS Server
Source tab:
- Subject: set countryName, stateOrProvinceName, localityName, organisationName to your defaults. Leave commonName blank (filled per certificate).
- Hash algorithm: SHA 512
- Key algorithm: EC, prime256v1
Extensions tab:
| Extension | Value |
|---|---|
| Basic Constraints | CA: FALSE |
| Key Usage | Digital Signature, Key Encipherment |
| Extended Key Usage | TLS Web Server Authentication |
| Subject Key Identifier | hash |
| Authority Key Identifier | keyid, issuer |
| Subject Alternative Name | DNS: (leave blank, fill per certificate) |
Set the validity period to 825 days (the maximum accepted by modern browsers for publicly trusted certificates, and a sensible limit for internal ones).
TLS client certificate template
Name: TLS Client
Extensions tab:
| Extension | Value |
|---|---|
| Basic Constraints | CA: FALSE |
| Key Usage | Digital Signature |
| Extended Key Usage | TLS Web Client Authentication, Email Protection |
| Subject Key Identifier | hash |
| Authority Key Identifier | keyid, issuer |
Validity: 2 years (730 days).
Email certificate template
Name: S/MIME
Extensions tab:
| Extension | Value |
|---|---|
| Basic Constraints | CA: FALSE |
| Key Usage | Digital Signature, Key Encipherment |
| Extended Key Usage | Email Protection |
| Subject Key Identifier | hash |
| Authority Key Identifier | keyid, issuer |
Include the email address in the Subject Alternative Name as email: followed by the address.
Intermediate CA template
Name: Intermediate CA
Extensions tab:
| Extension | Value |
|---|---|
| Basic Constraints | CA: TRUE, pathlen: 0 |
| Key Usage | Certificate Sign, CRL Sign |
| Subject Key Identifier | hash |
| Authority Key Identifier | keyid, issuer |
The pathlen: 0 constraint means this intermediate CA can sign end-entity certificates but cannot create further sub-CAs.
Signing a certificate from a CSR
When a server or service generates a CSR (as covered in the certificates section), review and sign it in XCA:
- Import the CSR via the Certificate Signing Requests tab
- Right-click the CSR and select Sign
- Select the appropriate template
- Select the issuing CA certificate
- Review all subject and extension values
- Confirm the validity period
- Click OK to sign
XCA generates the signed certificate. Export it via right-click > Export > PEM for use on the server.
Reviewing certificates
XCA is particularly useful for certificate inspection. Select any certificate and the detail view shows the full decoded content: subject, issuer, validity, extensions, fingerprints, and the complete chain of trust back to the root CA.
To check whether a certificate chain is valid before deploying it:
- Import all relevant certificates (root CA, intermediate CA, end-entity)
- Select the end-entity certificate
- XCA shows the chain in the certificate tree and highlights any validation issues
Exporting certificates
XCA can export certificates in several formats:
PEM (Base64): The standard format for Linux services. Use this for web servers, mail servers, and most other applications.
DER (Binary): Required by some applications. Less common.
PKCS#12 (.p12): Bundles the certificate and private key together. Useful for importing into browsers or mail clients. Always set a strong password when exporting PKCS#12 files.
Certificate chain: Exports the full chain from end-entity to root. Some services require this format for the certificate file.
To export, right-click a certificate in the Certificates tab and select Export.
CRL management
XCA manages Certificate Revocation Lists alongside certificates. When a certificate needs to be revoked:
- Right-click the certificate in the Certificates tab
- Select Revoke
- Choose the reason for revocation
- Generate an updated CRL from the issuing CA: right-click the CA certificate and select Generate CRL
- Export the CRL and deploy it to where it is referenced in your certificates (the CRL Distribution Point extension)
Backup
The XCA database on the encrypted USB drive is backed up as part of the overall offline key material backup. The database file should also be copied to a second encrypted USB drive (your backup Yubikey-equivalent for key material: a second physical copy in a separate location).
To export a backup copy of the database that can be opened on any machine with XCA installed:
File > Save as > /path/to/backup/xca-database.xdb
The database is already encrypted with the XCA database password, so copying it is safe as long as the password is strong and stored separately.
XCA’s database encryption is independent of the LUKS encryption on the USB drive. Even if someone obtains the USB drive and bypasses the LUKS encryption, the XCA database has its own passphrase. Both layers must be compromised for the contents to be accessible. Do not use the same passphrase for both.