Certificate Authority Overview
A Certificate Authority (CA) instance is the basic building block of a PKI installation, and can in an instance be described as the basic building block. The primary role of a CA is to handle issuance and revocation of certificates, and secondarily to validate, publish and provide workflows for effective certificate management. If you scale it down, a CA could simply consist of a key pair and a script, but in EJBCA we try to provide far more than that.
This Certificate Authority Overview covers conceptual information on CAs.
For more information on how to create, edit and manage CAs, see Certificate Authority Operations.
Certificate Authority Type
The first question to take into account when creating CA is the type. EJBCA currently supports two types:
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 be referenced in older documentation and configuration files. The two terms can be considered equivalent.
Key Pairs
A CA is defined to use several key pairs which are mapped to a purpose. In the following example, the purpose mapping can be seen on the left while the key pair alias is on the right. Note that the same alias can be used for several 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).
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.
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, only the RSA and Elliptic Curve Cofactor Diffie Hellman (ECCDH) suites are supported. In the case of ECCDH, only ciphers with a cofactor of 1 may be used, limiting curve choices to the following: P-224, P-256, P384, P-521, K-233, K-283, K-409, K-571, B-233, B-283, B-409, and B-571, see NIST's internet draft on ECC CDH Component Capabilities JSON Values.
For architectural reasons, when using key archival the end entity key cipher must match that of the signing and encryption keys, in other words only EC end entity keys can be archived by an EC CA (though they can have different curves), and only RSA end entity keys can be archived by an RSA CA.
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.
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
For more information on Approvals and workflows, see Approvals Overview.
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.
Publishers
For more information on existing publishers and how to configure them, see Publishers Overview.
Signing and storing certificates is often not enough, they need to be published to various locations as well.
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
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
For more information on validators, what they do and how to extend them, see Validators Overview.
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 can be created and edited in the CA UI and are chosen per CA for use.
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 been 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 activated again by renewing the CA.
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.
Certificate Authority Overview Topics