.png){kind=logo}
Certificate Authority Overview
A Certificate Authority (CA) instance is the fundamental component of a Public Key Infrastructure (PKI) installation. Its primary function is to issue and revoke certificates, and to support certificate request validation, publishing, and certificate management workflows.
In its simplest form, a CA could consist of little more than a key pair and a signing script. EJBCA, however, provides a full-featured CA implementation with built-in security controls, automation, and lifecycle management.
This Certificate Authority Overview provides conceptual information about Certificate Authorities.
For information on how to create, edit, and manage CAs, see Certificate Authority Operations.
Certificate Authority Type
When creating a CA, the first consideration is the CA type. EJBCA currently supports the following types:
X509: The most common CA type for secure email, login, web authentication, VPN and so on as defined in RFC 5280.
CVC: A CA issuing CV certificates, which are special certificates for EU EAC ePassports. For more information on CVC CAs, see CVC CA.
C-ITS ECA: C-ITS certificates are an EU-defined certificate format for Vehicle2X certificates. EJBCA supports the issuance of C-ITS factory certificates as an Enrollment CA. See C-ITS ECA.
SSH: SSH can use certificates instead of keys, which are defined in a specific format. EJBCA can act as a CA and issue these certificates. See SSH CA.
Signing Elements
This section provides an overview of the main elements in the CA configuration. For a complete reference to all configuration values, see the CA Fields.
Crypto Token
The basis of a CA will always be centered around one or more key pairs. From a CA's point of view, these are stored in a crypto token and need to be signed before they can be of any use. For information on types of crypto tokens available and where the private keys are stored, see Crypto Tokens Overview.
Crypto tokens in CA contexts have historically been called CA Tokens. While this term is purely historical, it may still appear in older documentation and configuration files. The two terms can be considered equivalent.
Key Pairs
A CA uses several key pairs that are mapped to specific purposes. In the following example, the purpose mapping appears on the left and the key pair alias on the right. The same alias can be used for multiple mappings.
defaultKey: The key to use if no specific key is selected.
certSignKey: The key to use for certificate issuance. Must comply with the signing algorithm chosen (see below).
alternativeCertSignKey: The key to use for hybrid certificate issuance. This key can only be used if a corresponding Alternative Signing Algorithm has been set (see below).
crlSignKey: The key to use for CRL signing. Even though it could theoretically be separate from the certSignKey according to the RFCs, client support is rare and the certSignKey will always be used.
keyEncryptKey: Key to use for key recovery (if enabled) and decrypts escrowed keys. It must be set, if you are planning to use key recovery or key archival operations.
hardTokenEncrypt: Deprecated functionality, do not use.
testKey: Key used by health-check to verify that the crypto token is usable. Usually a short key for speedy connection checks.
For encryption (keyEncryptKey), only the RSA algorithm is currently supported.
Signing Algorithm
The signing algorithm to use for issuing certificates, signing CRLs etc. The choice of algorithm must correspond to the key pair types available in the crypto token. Thus SHA256WithRSA can only be used in conjunction with RSA keys.
Alternative Signing Algorithm
The signing algorithm to use for issuing hybrid certificates, signing CRLs etc. The choice of algorithm must correspond to the key pair types available in the crypto token. For example DILITHIUM5 can only be used in conjunction with DILITHIUM5 keys.
CA Certificate
The keys associated with a CA are of no use unless they've been signed, and the result of this signature is the CA Certificate. The certificate can be self-signed (a Root CA), signed by another local CA (making it a Sub CA or Intermediate CA), or signed externally (requiring the generation and signature of a CSR before the CA can be made active). Choosing a certificate profile for the CA will not affect the certificates issued by this CA, but rather the certificates for this CA.
Approvals and Workflows
Some CA operations can be set up to require additional approvals, to allow lower level administrators to request that certain operations be performed and to require several individuals to sanction an action. The following actions can be configured for approval:
Adding and editing End Entities
Performing Key Recovery operations
Revoking certificates
Activating CA Services
Approvals are configured using Approval Profiles, which act as general approval workflow templates.
For more information on Approvals and workflows, see Approvals Overview.
Publishers
Signing and storing certificates is often not enough, they need to be published to various locations as well.
For more information on existing publishers and how to configure them, see Publishers Overview.
Common Publishing Operations
Publishers can come in various shapes and sizes, but common applications for publishers are:
Publishing certificates and CRLs from the CA to a VA.
Publishing certificates into an LDAP structure.
Publishing certificates into a Windows Active Directory structure.
Various Custom Publishers.
Publishing Queue
Certificate Authorities can be set to either direct publishing (which is instant, and which may cause the complete certificate issuance to fail if it fails in turn) or queued publishing, which is asynchronous but far more robust. Queued publishing is selected by marking a publisher to use the queue, and then setting up a Service Worker to process that queue.
Validators
A common requirement among Certificate Authorities is the ability to validate certificates or their contents before, during, or after the signing process and before they're stored and published. For this reason, EJBCA provides the Validator construct, where Validators can be instanced and configured based on templates and configured to have various effects on the issuance process, varying from just warning to outright rejecting the certificate being issued. Examples of validation operations are:
Checking that the size and security of submitted public keys align to predefined constraints.
Checking submitted public keys against a known block list of weak keys.
Performing online checks, such as Certificate Authority Authorization.
Validators are created and configured in the CA UI and selected per CA.
For more information on validators and how to extend them, see Validators Overview.
CA Lifecycle
Each CA in EJBCA has a status:
Uninitialized - The status of a CA without a key pair. CAs imported with Statedump or Configdump start off in this state. Once a key pair has been generated for the CA, the status changes to Waiting for certificate response.
Waiting for certificate response - The status of a CA without a certificate chain. It is possible to generate a CSR and ship it off to another CA for signing. Once a certificate chain is associated with the CA, the status changes to Active.
Active - The status of a CA with a key pair and certificate chain. An active CA can sign certificates, and be put offline or be revoked if required.
Offline - The status of a CA with a key pair and certificate chain, which has been temporarily disabled (e.g. to prevent unauthorized access). It can be put online again if needed.
Revoked - The terminal status of a CA that has been manually revoked. Once a CA is revoked it is not possible to perform any operations with it (e.g. sign certificates or renew the CA certificate).
Expired - The status of a CA whose CA certificate has expired. This status is set automatically by EJBCA. Once a CA has expired, it can be returned to Active status by renewing its CA certificate.
External CA - The status of a CA with a certificate chain but without a key pair associated with it.
The flowchart below describes the lifecycle of a CA based on these statuses:
Renewal
All certificates should expire within a reasonable date, if for no other reason to enforce that security fixed and updated algorithms are universally rolled out. EJBCA provides full support for renewing Certificate Authority certificates and rolling those out, including the use of rollover certificates. For more information on the process of renewal, see Managing CAs.
