3.5.5 CA Management

February 25th, 2026

There are two types of CA: Root CAs, and Intermediate CAs.

The Root CA is the master CA of which all other Intermediate CAs or end-entity Certificates stem from. In the majority of cases, an organization will have between one and two Root CAs.

Using a single Root CA is perfectly acceptable and for simplicity may be recommended. However, an organization may choose to segregate their public facing PKI infrastructure and internal facing infrastructure. There is no security related reason why this would be advisable, but segregation of duties may simply make a single Root CA impossible to manage.

AC X509 Authority allows you to create as many Root CAs as desired and manage them together.

An Intermediate CA is similar to a Root CA insofar as it manages other Intermediate CAs or end-entity Certificates. The main difference is that the Root CA has authority over everything and an Intermediate CA has more limited scope of authority such as for a specific department or type of application.

There is no technical requirement to have Intermediate CAs but doing so aids in:

• Segregation of duties
• Delegation of workload (both system and security officer)

Therefore, it is not unusual for a small organisation to have only a Root CA, but for a large organization to have a Root CA and many Intermediate CAs.

This article covers the following topics:

• Data Layout
• Before You Begin

• The CA Validity Period
• Issued Certificate Validity Period
• The CRL
• Password Locked CA
• Using Password Locked Keys

• Reasonable Defaults

• Low Security
• Medium Security
• High Security

• Root CA Creation Steps
• Intermediate CA Creation Steps

3.5.5.1 Data Layout

The data layout of a CA in AC X509 Authority is extremely simple. Withing the datastore path (/var/CA by default), the following resources exist:

Resource	Type	Contents
<CA>	directory	One directory per CA
<CA>/ca.key	file	The CA's own private key
<CA>/ca.crt	file	The CA's own public certificate
<CA>/root.crt	file	Optional combined Intermediate CA public certificate with full keychain back to the Root CA
<CA>/crl/ca.crl	file	The CA's CRL file
<CA>/keys	directory	Contains all the issued private keys in PEM encoded format with the naming convention <name>.key.
<CA>/certs	directory	Contains all the issued public certificates in PEM encoded format with the naming convention <name>.crt.
<CA>/requests	directory	Contains all the issued CSRs in PEM encoded format with the naming convention <name>.csr. Most of these are ephemeral and exist only until a certificate is successfully created.

The contents of the data layout should not be manually manipulated.

3.5.5.2 Before You Begin

Before creating a CA, you should plan ahead. Certain configuration properties cannot be changed. Immutable characteristics are:

• CA expiration date
• CA Distinguished Name
• Purpose (the types of certificates managed)
• CRL Path1

Making changes that require recreating a CA after certificates are already deployed to applications or end users can have major impact, incurring time consuming procedures.

The CA Validity Period

The validity period of a CA should be significantly longer than the certificates is manages. Once the CA certificate has expired, it cannot be used to verify the chain of trust. Eventually all root certificates need to be renewed. Their lifetime is generally not less than 5 years and not more than 20 years. 10 years is a reasonable starting point.

If the CA is valid for 10 years and all certificates it issues are valid for 2 years, then after 8 years, the CA should be renewed (but not deleted) and only the new CA certificate used for issuing certificates from that point onward. This way, no certificate issued by the CA will have an expiration date later than the expiration date of the CA.

CA renewal plan

Therefore, the usable lifetime a CA can be used is defined as:

(CA Validity Days) - (Issued Certificate Validity Days) = CA Lifetime

The period after the lifetime until the end of the validity period should be considered as a reference period only for authenticating certificates already in use.

Issued Certificate Validity Period

The validity period of issued certificates should be less than the validity period of the CA. The length of time is based on risk mitigation and convenience. A compromised certificate may be usable by malicious actors, which is why a validity period exists as a measure of last resort. However, deploying new certificates may be an onerous task for administrators and users.

Setting a validity period for End-Entity certificates of 1 to 2 years is generally deemed as reasonable, with longer periods if a Root CA manages certificates for an Intermediate CA.

The CRL

Because the Certificate Revocation List is the first line of defence against compromised certificates, it should be published to a web server at a location accessible to the entire scope of the users. If a Root CA manages End-Entity certificates for both internal and external users, that means making the CRL available directly on the World Wide Web without requiring login or any other barrier to access.

AC X509 Authority provide several parameters for managing the CRL and integrating it into your security infrastructure.

Password Locked CA

A CA that is password locked will require the administrator to enter a password for every operation such as editing the profile or simply for creating or sighing new certificates. As a general guideline, please consider the following:

• A password locked CA is recommended when a human user interacts with AC X509 Authority directly. It provides an additional layer of security to prevent unauthorised certificate management even if the system account is compromised.
• A password locked CA is not recommended when AC X509 Authority is used in an automated environment embedded in another application.

Using Password Locked Keys

This parameter controls whether private keys are locked with a password. Serious consideration should be given before setting this. Making key passwords mandatory could have implications for certificates used in disparate systems which may or may not support password access to keys. This is probably best controlled at the Intermediate CA level.

3.5.5.3 Reasonable Defaults

If in doubt, the table below provides some reasonable defaults for key length, validity periods, password policies, and DN restrictions.

The realistic use cases for high security is rare, even in environments deemed as security sensitive such as finance.

If in doubt, opt for the medium security model.

Low Security

	Root CA	Intermediate CA	Server/Client Certificate	User Certificate
Length	2048	2048	1024	1024
Password Locked	Y	N	N	N
Validity Period	7300 days (20 yrs)	3650 days (10 yrs)	1825 days (5 yrs)	1825 days (5 yrs)

Low Security does not mean weak security. 1024 bit RSA keys are comparatively shorter when compared to current best practices of 2048 bits or higher. That doesn't mean they are easy or even likely to be cracked. Though some applications are increasingly mandating 2048 bit keys as the functional minimum. Longer keys are computationally more expensive (more processing power required) and a shorter key length may be desirable for internal systems where maximum throughput is desired. In this context 512 bit keys may even be desirable.

Medium Security

	Root CA	Intermediate CA	Server/Client Certificate	User Certificate
Length	2048	2048	2048	2048
Password Locked	Y	Y	N	Y
Validity Period	3650 days (10 yrs)	1825 days (5 yrs)	730 days (2 yrs)	730 days (2 yrs)

High Security

	Root CA	Intermediate CA	Server/Client Certificate	User Certificate
Length	4096	4096	4096	4096
Password Locked	Y	Y	Y	Y
Validity Period	3650 days (10 yrs)	1825 days (5 yrs)	365 days (1 yr)	365 days (1 yr)

3.5.5.4 Root CA Creation Steps

Creating the Root CA is a menu driven process with a single command entry point. The example below shows the end-to-end process of creating the CA. Note that a Root CA is by definition always a self-signed certificate. This must be selected for a Root CA.

• The mandatory field for creating a Root CA are highlighted.
• Hitting enter with no input will use the default option presented between brackets [ ].

# ac_x509_authority new Creating new Certificate Authority Certificate Authority name [auth1]: BigCorpRootCA Is this CA for managing [S]erver (issued to FQDNs) [C]lient (issued to email addresses) [I]ntermediate certificates Intent? [S/C/I]: i Are you creating a [S]elf-signed CA or an [I]ntermediate CA? [S/I]: s CA key bit length [2048]: CA validity period (days) [3652]: CA domain name [bear-builder]: rootca.bigcorp.asiacomtek.com

The following 6 fields are all optional and can be left blank if desired.

CA organisation: Big Corp Inc. CA division/department: IT CA department: Security CA city: Sapporo CA state or region: Hokkaido CA country: JP

The following fields define restrictions on the issued certificates.

CA administrator email address: security-team@bigcorp.asiacomtek.com Require additional password for CA operations? [Y/N]: n Issued keys bit length [2048]: 1024 Issued certificates validity period (days) [730]: Restrict issued certificates by Organisation (must match 'Big Corp Inc.'? [Y/N]: y Restrict issued certificates by 1st Department (must match 'IT')? [Y/N]: n Restrict issued certificates by City (must match 'Sapporo')? [Y/N]: n Restrict issued certificates by State or Region (must match 'Hokkaido')? [Y/N]: n Restrict issued certificates by Country (must match 'JP')? [Y/N]: n Protect issued keys with a password [no]? [Y/N]: n Publish a URL for the Certificate Revocation List (CRL)? [Y/N]: y CRL URL path: http://ca.bigcorp.asiacomtek.com/BigCorpRootCA.crl Add another CRL URL? [Y/N]: y CRL URL path: http://ca.alt.bigcorp.asiacomtek.com/BigCorpRootCA.crl Add another CRL URL? [Y/N]: n CRL valid days: 1 CRL auto update every 0 days? [Y/N]: y Copy CRL to alternate file path on update? [Y/N]: y CRL file path: /var/www/BigCorpRootCA.crl

Finally confirmation is requested. If you do not confirm the program will exit.

Certificate Authority summary for 'BigCorpRootCA' (fields marked * will enforce matching in issued certificates) Type: self-signed Authority Intent: intermediate CA key length: 2048 CA validity period: 3652 CA is password locked: no CA Common Name (CN): rootca.bigcorp.asiacomtek.com CA Organisation (O): Big Corp Inc. * CA Department/s (OU): IT CA City (L): Sapporo CA State or Region (ST): Hokkaido CA Country (C): JP CA administrator email: security-team@bigcorp.asiacomtek.com CRL path(s): http://ca.bigcorp.asiacomtek.com/BigCorpRootCA.crl http://ca.alt.bigcorp.asiacomtek.com/BigCorpRootCA.crl CRL validity period: 1 days CRL auto update: yes CRL export path: /var/www/BigCorpRootCA.crl Password locked keys: no Issued validity periods: 730 Issued key lengths: 1024 Use these settings? [Y/N]: y CRL update complete. New Certificate Authority created.

3.5.5.5 Intermediate CA Creation Steps

Creating an Intermediate CA is a menu driven process with a single command entry point. The example below shows the end-to-end process of creating the CA. You cannot create an Intermediate CA unless you already have access to another Intermediate or Root CA to act as the issuing parent CA. Therefore, if you have not already done so, follow the procedure for Root CA Creation Steps above.

The Intermediate CA Certificate key-pair does not need to be issued by AC X509 Authority. Any valid PEM encoded key file, public certificate, and chain can be used provided they were issued for the purpose of acting as a CA.

In this walkthrough, we assume that Root CA for the Intermediate CA is also AC X509 Authority though it isn't a requirement.

• The mandatory field for creating an Intermediate CA are highlighted.
• Hitting enter with no input will use the default option presented between brackets [ ].

1. Have the Root or parent Intermediate CA issue a certificate for use in the new Intermediate CA. In AC X509 Authority, this is done as follows:

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

The use of the password will depend on the policy defined for the CA and the desired use (or not) for a password of the new Intermediate CA. Here's how that looks assuming we are using the Root CA shown in the example from the previous section:

# ac_x509_authority BigCorpRootCA create BigCorpStaffCA Creating new certificate for CA 'BigCorpRootCA' (intent: intermediate) : 'BigCorpStaffCA'. Certificate creation complete.

2. [optional] Copy the root certificate chain, private key, and public certificate for the Intermediate CA to the system where it will be created. You should also include the <CA>/ca.crt file which is the public certificate of the Root. In a scenario where the parent of the new Intermediate CA is another Intermediate CA, that file will be root.crt which will have both the parent Intermediate CA certificate and the Root CA certificate.
3. Create the intermediate CA using the available certificate created by the Root. In this example, we will create the Intermediate CA assuming everything is on the same host as the Root CA.

# ac_x509_authority new Creating new Certificate Authority Certificate Authority name [auth1]: BigCorpStaffCA Is this CA for managing [S]erver (issued to FQDNs) [C]lient (issued to email addresses) [I]ntermediate certificates Intent? [S/C/I]: c Are you creating a [S]elf-signed CA or an [I]ntermediate CA? [S/I]: i CA key file: /var/CA/BigCorpRootCA/keys/BigCorpStaffCA.key Password for keyfile ([ENTER] for none): CA certificate file: /var/CA/BigCorpRootCA/certs/BigCorpStaffCA.crt Import a root certificate chain? [Y/N]: y Root certificate chain file: /var/CA/BigCorpRootCA/ca.crt Issued keys bit length [2048]: 1024 Issued certificates validity period (days) [730]: 365 Restrict issued certificates by Organisation (must match 'Big Corp Inc.'? [Y/N]: y Restrict issued certificates by 1st Department (must match 'IT')? [Y/N]: n Restrict issued certificates by City (must match 'Sapporo')? [Y/N]: n Restrict issued certificates by State or Region (must match 'Hokkaido')? [Y/N]: n Restrict issued certificates by Country (must match 'JP')? [Y/N]: n Protect issued keys with a password [no]? [Y/N]: n Publish a URL for the Certificate Revocation List (CRL)? [Y/N]: y CRL URL path: http://ca.bigcorp.asiacomtek.com/BigCorpStaffCA.crl Add another CRL URL? [Y/N]: n CRL valid days: 2 CRL auto update every 1 days? [Y/N]: y Copy CRL to alternate file path on update? [Y/N]: n Certificate Authority summary for 'BigCorpStaffCA' (fields marked will enforce matching in issued certificates) Type: intermediate Authority Intent: client CA key length: 1024 CA validity period: Feb 25 05:08:19 2028 GMT CA is password locked: no CA Common Name (CN): BigCorpStaffCA CA Organisation (O): Big Corp Inc. CA Department/s (OU): IT CA City (L): Sapporo CA State or Region (ST): Hokkaido CA Country (C): JP CA administrator email: security-team@bigcorp.asiacomtek.com CRL path(s): http://ca.bigcorp.asiacomtek.com/BigCorpStaffCA.crl CRL validity period: 2 days CRL auto update: yes CRL export path: Password locked keys: no Issued validity periods: 365 Issued key lengths: 1024 Use these settings? [Y/N]: y CRL update complete. New Certificate Authority created.