-
-
Notifications
You must be signed in to change notification settings - Fork 612
Deployment & Implementation Guide
This document will grow to include details useful for those wishing to operate a CA using Boulder.
- Security Contexts
- Inter-Process Communication
- Distributed Validation Authorities
- Database Permissions
- OCSP
- Audit Logging
Spread the different Boulder components into appropriate security contexts, and apply restrictive firewall rules.
Use AMQPS (AMQP over TLS) with client-certificates for all internal communication. In Boulder, configure this with the "amqp->tls" configuration section.
Each Boulder instance should have only its' own AMQP account information, and each account should be restricted to writing to only the necessary topics. A sample configuration and configuration tool reside at {{TBD}}.
The VA is designed to be run in multiple locations, to test multiple paths to validate domains.
You should configure an appropriate voting quorum in the RA based on your performance metrics. For example, if you have 4 VAs, you may want to hear positive answers from 3 and no negative answers before issuing.
Each Boulder process requiring DB access should do so with its' own DB account information, and each account should be restricted to the minimum permissions required.
Run the OCSP Updater tool regularly, and from an appropriate security context.
All log messages defined by the Baseline Requirements as auditable events, as well as others defined by the Boulder team, are marked with the string [AUDIT] at the beginning of their message payload. These messages should be specially filtered and retained per your audit requirements.
NOTE: There is an outstanding issue with reliable logging from Boulder directly, Issue #298. Implementing parties should log using UNIX sockets to a standard logging daemon on the host system (syslog-ng, rsyslog, etc), and configure that to transmit the logs over TCP if they need to go off-box.