Skip to main content

Anapaya legacy SCION CA (HashiCorp Vault-based)

The SCION CP-PKI requires some ASes to act as certificate authorities (CA) in their local ISD. These ASes need to provide a certificate renewal service to their customer ASes. The certificate renewal request is sent via SCION to the Anapaya appliance in the CA AS. On successful certificate issuance, the CA returns a valid SCION CP-PKI certificate chain consisting of the SCION CP-PKI AS and CA certificates. This document describes the different deployment models the Anapaya appliance supports for such a CA AS, and goes into details on the configuration and operations of the standard solution (Anapaya SCION CA).

The rest of the chapter only explains the configuration and operation of the Vault-based Anapaya SCION CA.

Deployment models​

The Anapaya appliance supports multiple deployment models for a SCION CP-PKI CA (CA). The different models are tailored to address different needs and requirements. In the rest of this section, these models are explained in more detail.

Vault-based SCION CP-PKI CA​

The standard solution is to use HashiCorp Vault as the SCION CP-PKI CA backend. The Anapaya appliance internally has an adapter that exposes the SCION CA REST HTTP API and translates the received requests into calls to the Vault.

The required configuration of Vault is described in Configuration.

Key concepts in Vault-based CA deployment​

Familiarity with the following concepts is crucial to understanding the rest of the documentation:

  • Secrets engine: A secrets engine is a term defined by Vault that describes a component that stores, generates, or encrypts data. They are very flexible and define most of Vault's capabilities. An instance of a secret engine can be enabled at a specific "path" (think URL path). Multiple instances of the same type of secret engine can be mounted at different paths, each instance will have their own state. This allows us to mount separate PKI engine instances per SCION AS. For more details, see https://www.vaultproject.io/docs/secrets.

    The two most relevant types of secret engines are:

    • PKI engine: Vault defines a secrets engine specifically for handling X.509 certificates called PKI. To avoid confusion, this secrets engine is called PKI engine for the rest of this document. For more details, see https://www.vaultproject.io/docs/secrets/pki.

    • Key/Value Engine: Vault defines a secrets engine for storing arbitrary secrets in a key value storage. To avoid confusion, this secrets engine is called Key/Value engine for the rest of this document. For more details, see https://www.vaultproject.io/docs/secrets/kv/kv-v2v.

  • Policy: Various degrees of access to the secrets and secrets engine functionality can be defined for individual users and/or applications. The rules for access control are defined in policies. For more details, see https://www.vaultproject.io/docs/concepts/policies.

  • CA adapter The CA adapter is part of the Anapaya appliance. It only interacts with a subset of the available secrets engine endpoints. The sign-verbatim endpoint is used by the CA adapter to service the certificate renewal requests. This endpoint issues certificates as specified in a certificate signing request (CSR). All the validation steps are done in the CA adapter itself.

    To simplify the storage requirements and ensure consistency between different Anapaya appliances, Vault acts as the storage backend for the necessary TRCs, as well as the blocklist that prevents specific SCION ASes from renewing their certificates.

    The CA adapter requires a token to interact with Vault. Tokens in Vault always have a TTL and need to be renewed periodically, the CA adapter takes care of this internally. It authenticates itself periodically with Vault via the AppRole authentication method and fetches the token. The secrets for this need to be provisioned in the Anapaya appliance configuration.

  • CA provisioning: The Vault needs to be provisioned with the right data in order for the SCION AS to provide the correct SCION CP-PKI CA functionality. Because of the short lifetime of the SCION CP-PKI CA certificates (recommended is 11 days), this task needs to be automated and executed periodically.

  • Manual intervention Manual intervention is only necessary to adapt the blocklist and to provision new TRCs after a TRC update.

The following diagram highlights the role of above-mentioned concepts in the interactions between different Vault clients and the respective Vault endpoints.

Vault overview

VaultCA service​

The VaultCA service automates certain parts of the Vault base CP-PKI CA. The service is developed by Anapaya and together with the HashiCorp Vault deployment forms the Anapaya SCION CA.

External SCION CP-PKI CA​

In high-security networks, customers usually require specific policies on the management of the certificates and keys. These customers can provide their own implementation of a SCION CP-PKI CA that adheres to these policies. For example, a policy could be to store private keys for the SCION CP-PKI CA certificate in an HSM, or to have strict identity checks before issuing an initial SCION CP-PKI AS certificate.

The Anapaya appliance is capable of using an external SCION CP-PKI CA implementation via a REST HTTP API. For this deployment type, the Anapaya appliance needs to be configured with a shared-secret such that it can authenticate itself with the external CA service.

The diagram below shows the flow of a certificate renewal request from the customer SCION AS to CA AS.

  1. The customer AS sends the certificate renewal request to the CA AS via SCION.
  2. The CA AS appliance does minimal validation of the request and forwards the request to the external CA service.
  3. The external CA returns the certificate chain to the CA AS appliance.
  4. The CA AS appliance returns the certificate chain to the customer AS via SCION.

External CA overview

In-process SCION CP-PKI CA​

warning

Do not use the in-process CA for production deployments. It is only meant for testing.

For testing purposes, the Anapaya appliance supports renewing SCION CP-PKI AS certificates in-process. In this mode, no external CA service or Vault is required. However, a valid CA private key and the corresponding SCION CP-PKI CA certificate are required and must be stored on the appliance itself.