Server, Client, and User Certificate Management

February 25th, 2026

AC X509 Authority provides a framework for end-entity certificates restricted by the configuration of the CA that be issuing them. This section assumes that you have already set up a Root or Intermediate CA in a way that is suitable for the end-entity certificates it will issue.

With the exception of creating a CSR (not the expected use case), all operations are simple single command executions.

• Creating a Certificate

• Creating a Full Certificate Keypair
• Creating a CSR
• Signing a CSR
• Renewing a Certificate

• Revoking a Certificate
• Deleting a Certificate
• Exporting a Certificate

• Manual Export
• PKCS#12 Keystore File Export

--

Creating a Certificate

There are two fundamental workflows for certificate creation. Which one is used is highly dependent on the organization. Although a few organizations may use a mixture of the two, it is more common that security officers have mandated one approach or the other. They are:

• Application/User generated private keys
  In this model, the CA does not create keys. Private keys never leave the system they are used on, They are effectively born on those systems and eventually die on them. Instead, the users provide Certificate signing Requests (CSRs) to the CA to sign and convert those into valid public certificates.
• Centralized end-to-end creation of certificate keypairs
  Everything is managed centrally and certificates and private keys are then disseminated to applications or users that require them.

Both models have advantages and disadvantages and a security officer will usually express a strong preference for one over the other. AC X509 Authority supports both.

Creating a Full Certificate Keypair

This is the most common usage and the expected use case. Fields are automatically populated for the DN and there is no need to manually create a separate CSR and then sign it. The outcome of this procedure is a fully usable keypair.

Usage

# ac_x509_authority <CA> create <common_name> [<CA_password> <password> <SANs>]

Example

# ac_x509_authority BigCorpStaffCA create john-doe@bigcorp.local Creating new certificate for CA 'BigCorpStaffCA' (intent: client) : 'john-doe@bigcorp.local'. Certificate creation complete.

A note about SANs

Subject Alternative Names (SANs) are alternative hostnames or addresses that a certificate is made valid for. By default, AC X509 Authority always creates at least one SAN which is a duplicate of the certificate name. However, additional entries can be supplied. This is useful in scenarios where a single certificate is used for a cluster. For example, a website might have several servers that serve the same content. The create command with SANs looks like this.

# ac_x509_authority BigCorpWebCA create www.bigcorp.local \ node1.bigcorp.local,node2.bigcorp.local

Or for a scenario where users have email address aliases...

ac_x509_authority BigCorpStaffCA create john-doe@bigcorp.local \ jdoe@bigcorp.local,johnnyd@bigcorp.local

Creating a CSR

This is a less common method and results in a private key and a CSR file. The CSR can be signed by another CA or by AC X509 Authority to convert it into a usable public certificate and form a valid keypair.

Usage

# ac_x509_authority <CA> create-csr <common_name> [<CA_password> <password> <SANs>]

Example

# ac_x509_authority BigCorpStaffCA create-csr sally-jones@bigcorp.local Creating new Certificate Signing Request for CA 'BigCorpStaffCA' (intent: client) : 'sally-jones@bigcorp.local'. Organisation: Some Contracted Vendor Inc. Division/department: Consulting Department: City: New York State or region: New York Country: US Certificate Signing Request creation complete. CSR file: '/var/CA/BigCorpStaffCA/requests/sally-jones@bigcorp.local.csr'

Signing a CSR

Many applications generate their own private key and CSR and do not provide functionality for importing a complete keypair at all. AC X509 Authority can sign those CSR to make them into public certificates and manage them just as effectively.

Usage

# ac_x509_authority <CA> sign <CSR_path> [<CA_password>]

Example

# ac_x509_authority BigCorpStaffCA sign \ /var/CA/BigCorpStaffCA/requests/wolfgang.mozart@bigcorp.local.csr Certificate signing complete.

Renewing a Certificate

Renewing a certificate regenerates it and overwrites the existing one with a new serial number. For this reason, you may want to archive certificates before recreating them.

Real-time applications like TLS have no need for any keypair history. However, applications such as encrypted email may require historical certificates to remain available after they have expired for the purpose of opening and reauthenticating old messages that were received while the certificate was still valid.

Renewing a certificate is the same command as creating a new certificate.

Revoking a Certificate

A certificate should be revoked when:

• There is a chance that the certificate has been compromised.
• When the application using it has been decommissioned.
• When the user has left the organization.

Revoking a certificate only works if applications are checking an up-to-date CRL regularly. If you do not maintain a CRL, then revoking has no functional meaning.

Usage

# ac_x509_authority <CA> revoke <common_name> [<CA_password>: # ac_x509_authority <CA> update-crl [<CA_password>]

Example

# ac_x509_authority BigCorpStaffCA revoke wolfgang.mozart@bigcorp.local Certificate for 'wolfgang.mozart@bigcorp.local' has been revoked. # ac_x509_authority BigCorpStaffCA revoke sally.jones@bigcorp.local Certificate for 'sally.jones@bigcorp.local' has been revoked. # ac_x509_authority BigCorpStaffCA update-crl CRL update complete.

The revoke and update CRL commands are separate for a reason. Revocation is of performed as a batch such as when employees leave at the end of the month or an entire data center is taken offline.

Deleting a Certificate

Removes a certificate but doesn't revoke it. Because it is removed from AC X509 Authority does not affect it's usage at all. Therefore, if a CRL is managed, a certificate should first be Revoked and then Deleted.

Usage

# ac_x509_authority <CA> delete <common_name>]

Example

# ac_x509_authority BigCorpStaffCA delete wolfgang.mozart@bigcorp.local Certificate 'wolfgang.mozart@bigcorp.local' has been deleted.

Exporting a Certificate

Exporting a certificate can be done manually at the file level or via automated generation of a PKCS#12 keystore file. The method used will depend on the system the certificate will be used in and its specific requirements.

Manual Export

Manual export is simple and is probably the most commonly used method. You will generally need 3 files to export a full keypair plus certificate chain:

1. /var/CA/<CA>/ca.crt (if the parent is the Root CA)
   /var/CA/<CA>/root.crt (if the parent is an Intermediate CA)
2. /var/CA/<CA>/keys/<common_name>.key
3. /var/CA/<CA>/certs/<common_name>.crt

PKCS#12 Keystore File Export

PKCS#12 keystore files are also fairly common and widely support by most applications including all popular desktop operating systems.

Usage

# ac_x509_authority <CA> get-pkcs12 <common_name> <alias> [<password> <keystore_password>]

Example

# ac_x509_authority BigCorpStaffCA get-pkcs12 john-doe@bigcorp.local usercert somepassword PKCS#12 keystore exported to '/home/developer/john-doe@bigcorp.local.p12'.

You can only export a PKCS#12 keystore if the entire keypair was created in AC X509 Authority with the create command or a combination of create-csr with sign commands.