Overview¶
The SCION CPPKI 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 CPPKI Certificate Chain consisting of the SCION CPPKI 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 CPPKI Certificate Authority (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 CPPKI Certificate Authority¶
The standard solution is to use HashiCorp Vault as the SCION CPPKI Certificate Authority 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.
The following list defines terms that will be used extensively throughout the document:
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. There are different types of secrets engines, the 2 relevant ones are explained below. 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.
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.
The following diagram highlights the interactions between different Vault clients and the respective Vault endpoints.
Certificate Authority Adapter
The Certificate Authority (CA) adapter is part of the Anapaya Appliance. It only interacts with a subset of the available secrets engine endpoints. The
sign-verbatimendpoint 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.
Certificate Authority Provisioning
The Vault needs to be provisioned with the right data in order for the SCION AS to provide the correct SCION CPPKI CA functionality. Because of the short lifetime of the SCION CPPKI 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.
VaultCA service¶
The VaultCA service automates certain parts of the Vault base CPPKI CA. The service is developed by Anapaya and together with the HashiCorp Vault deployment it forms the Anapaya SCION CA.
External SCION CPPKI Certificate Authority¶
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 CPPKI Certificate Authority that adheres to these policies. For example, a policy could be to store private keys for the SCION CPPKI CA certificate in an HSM, or to have strict identity checks before issuing an initial SCION CPPKI AS certificate.
The Anapaya appliance is capable of using an external SCION CPPKI Certificate Authority 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 shows the flow of a certificate renewal request from the Customrer SCION AS to CA AS.
The customer AS sends the certificate renewal request to the CA AS via SCION.
The CA AS appliance does minimal validation of the request and forwards the request to the external CA service.
The external CA returns the certificate chain to the CA AS appliance.
The CA AS appliance returns the certificate chain to the customer AS via SCION.