Terminology

ACME

Automatic Certificate Management Environment (ACME) is a communications protocol created by the Internet Security Research Group (opens in a new tab) (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).

CA

A Certificate Authority (CA) validates websites and issues digital certificates that certify the authenticity, encryption, and integrity of the webservers. These certificates allow webservers and clients (such as browsers) to communicate securely by encrypting the traffic between them.

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.

PKI

Public Key Infrastructure (PKI) refers to the services and resources that provide a layer of security for a network, or the internet at large. Typically the resources are X.509 Certificates that provide a verifiable identity for computers on the network and CA services that provision the X.509 certificates. The PKI for the internet, sometimes referred to as WebPKI, is a collection of public CAs, like LetsEncrypt, that issue certificates to verified domain name owners. The certificates they issue allow browsers to securely connect to web servers over HTTPS using these domain names. PKI models (often based on and similar to WebPKI) can be deployed inside a private network or company infrastructure, and these are known as internal PKIs.

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.

SSL

SSL stands for Secure Sockets Layer and it was an earlier version of TLS. SSL was developed by Netscape in the 1990s and a later version of SSL was renamed TLS. SSL has now been deprecated in favor of TLS, the preferred standard for internet encryption on HTTPS, email, and VPN.

TLS

Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication on the internet. TLS ensures that data sent between a client (a browser) and a server (a website) remains confidential by encrypting the HTTP to become HTTPS (HyperText Transfer Protocol Secure). TLS establishes a secure connection between the client and server through a process called a handshake. During this handshake, the client and server encrypt the session by authenticating each other's identities and exchanging keys used to encrypt and decrypt the data being transmitted.

Each new version of TLS improves the security and algorithms to keep the data secure.

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 wizard 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. Anchor provides two types of packages: 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, 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 belongs 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.

Custom Domain

A custom domain is often used to establish a specific subdomain for each customer. However the Certificate Transparency (CT) logs then expose the list of your customers to the world. Anchor doesn't publish to public transparency logs so with Anchor your customers remain private. For example you can see the publicly visible certificates that Anchor has registered (opens in a new tab). If you're using a custom domain locally then you will need lcl.host for browsers to recognize your custom domain as secure.

It's a bad practice to create a wildcard certificate like *.anchor.dev to hide subdomains because if the private key of that wildcard certificate is compromised, an attacker could impersonate any subdomain. Read more on the Anchor blog about how to reduce the blast radius and make your site more secure (opens in a new tab).

Another risk of these CT logs is announcing test environments to the public, such as StagingEnv.CompanyDomain.com and TestingEnv.CompanyDomain.com. These environments may have less secure passwords for accessing your systems and could give attackers more information that you realize. Similarly if you use a public certificate for your local development on a new feature, you could leak infrastructure changes to the public with your NewFeature.CompanyDomain.com 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 certificates 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, each time generating a 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 its 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.

Secure Context

A secure context is a browsing environment using HTTPS to encrypt data sent between the webserver and the browser. This ensures privacy and protection against eavesdropping or tampering attacks.