Terminology

ACME

Automatic Certificate Management Environment (ACME) is a communications protocol created by Internet Security Research Group (ISRG) to automate obtaining and managing the X.509 certificates needed for TLS encryption.

ACME has near ubiquitous support across languages and frameworks. Anchor uses the ACME protocol for certificate provisioning, which keeps required setup minimal.

If you'd like a deep-dive into ACME, check out RFC 8555 (opens in a new tab).

CRL

A Certificate Revocation List (CRL) catalogs revoked certificates from a Certificate Authority. This method for tracking revoked certificates has been replaced by newer technology, like OCSP. Anchor supports CRLs for legacy reasons.

OCSP

Online Certificate Status Protocol (OCSP) provides the revocation status of a certificate. Some browsers, like Firefox, use OCSP to validate HTTPS certificates. By default, Anchor supports OCSP.

Core Concepts

Services

Services represent networked programs deployed to internal infrastructure, typically application software with client and server components. Anchor manages TLS encryption for these software deployments.

A service belongs to an Organization but may span multiple Realms. You can create a new service by following the New Service wizord on the services overview page.

Creating a new service will generate some or all of the following items:

Packages

Packages are the artifacts used by your applications and hosts to establish trust for the Chains in a Realm. Packages have two basic types: language and system.

Language packages provide language specific configuration for an application so that Anchor provisioned certificates will be trusted.

System packages configure host systems to trust Anchor provisioned certificates and manage CRL distribution for revocation.

Organizations & Realms

Organizations and realms allow you to arrange and fit Anchor X.509 PKI deployments to your infrastructure.

Organizations allows multiple members to collaborate together, and realms provide workspaces within organizations. Realms typically correspond to existing infrastructure layouts, but can overlap if needed.

You can create an organization by following the New Organization wizard on the organizational overview page. You can also create a Personal Organization by signing in with the GitHub Single-Sign On (SSO) provider (opens in a new tab).

A realm belong to an organization. You can create a realm with the New Realm wizard on the realms overview page, or when registering a new Service.

Chain

A Chain represents an X.509 deployment. It is made up of the certificates, certificate credentials, CRLs, OCSP responders, CT logs, and EAB tokens.

You can create a new chain by following the New Chain wizard from a realm's chain overview page. Creating a new chain will create the AnchorCA certificate.

AnchorCA, SubCA, and Leaf Certificates

AnchorCA, SubCA, and Leaf certificates are the three certificate types found in a two-tier PKI.

AnchorCA certificates are self-signed root CA certificate that issue SubCA certificates. There is only one AnchorCA certificate per Chain.

SubCA certificates are intermediate CA certificates that issue Leaf certificates. They also act a template to help maintain consistency among their Leaf certificates. A chain can have many SubCA certificates.

Leaf certificates are the end user or subject certificates used for TLS encryption by servers and/or clients. They are typically provisioned using an ACME client with EAB tokens.

Certificates

Each certificate has one or more Certificate Credentials. A Certificate Credential is the encoded artifact (typically in PEM format) of certificate properties for a validity period and key pair. Because a certificate can have multiple credentials, certificates can be thought of as a grouping of multiple versions of the same certificate.

Certificate can be renewed, generating one (or more) new certificate credential for the same key pair and certificate properties, but for a different validity period.

Key Pairs

Key Pairs are the pairing of a private key and it's public key component. Key pairs typically belong to a certificate, but are also used in ACME workflows and Webauthn authentication.

Anchor key pairs always contains the public key component, but Anchor may not have access to the private key data, depending how the key pair was created. For example, key pairs for ACME provisioned certificates do not send the private key material to Anchor.