boulder

Boulder é uma implementação de uma autoridade certificadora (CA) baseada em ACME, e é o software que executa o Let's Encrypt. O protocolo ACME permite que uma CA verifique automaticamente se um solicitante de certificado realmente controla um identificador, e permite que assinantes emitam e revoguem certificados para identificadores que controlam. Arquitetura O Boulder é dividido em componentes separados por contexto de segurança: - Web Front Ends (um por versão de API) - Registration Authority - Validation Authority - Certificate Authority - Storage Authority - Publisher - CRL Updater O Web Front End, a Validation Authority, o CRL Storer e o Publisher precisam de acesso à Internet e, portanto, estão em maior risco de comprometimento. A Registration Authority pode operar sem conectividade com a Internet, mas se comunica com o Web Front End e a Validation Authority. A Certificate Authority recebe instruções apenas da Registration Authority. Todos os componentes usam a Storage Authority para persistência, que é respaldada pelo MariaDB. Os componentes se comunicam por gRPC; componentes remotos são instanciados como pares cliente/servidor, onde o cliente implementa a interface Go do componente e o servidor contém a lógica real. Internamente, o sistema é organizado em torno de cinco tipos de objetos que mapeiam diretamente para os recursos ACME: contas, autorizações, desafios, pedidos e certificados. Solicitações de clientes ACME criam novos objetos e modificam os existentes, e a Storage Authority mantém cópias persistentes do conjunto atual de objetos. Configuração de desenvolvimento O Boulder inclui um Dockerfile e usa Docker Compose para instalar e configurar todas as dependências. Essa é a maneira recomendada pelos mantenedores para executá-lo em desenvolvimento e experimentação, e explicitamente não é adequada como ambiente de produção. O projeto sugere o Pebble, uma versão em miniatura do Boulder, para integração contínua e experimentação rápida por desenvolvedores de clientes ACME. Fluxo de trabalho típico: - Clone o repositório e garanta que o Docker Engine 1.13.0+ e o Docker Compose 1.10.0+ estejam instalados; recomenda-se pelo menos 2 GB de RAM para o host Docker. - Execute ./t.sh para a bateria padrão de lints, testes unitários e de integração; ./t.sh -u para testes unitários, ./t.sh -i para testes de integração e ./tn.sh para a configuração "config-next" que representa um provável estado futuro. - Execute docker compose run bsetup uma vez para gravar certificados em test/certs e, em seguida, docker compose up para iniciar o Boulder. - O docker-compose.yml monta o checkout em /boulder para que as edições no host sejam refletidas imediatamente nos contêineres. Por padrão, o Boulder usa um resolvedor de DNS falso que resolve todos os nomes de host para 127.0.0.1, o que atende aos testes de integração dentro do contêiner. Para permitir que um cliente baseado no host se comunique com o Boulder, encontre o IP Docker do host e defina a variável de ambiente FAKE_DNS de acordo; o resolvedor stub (sd-test-srv) então responde a todas as consultas A com esse endereço. Firewalls baseados no host devem permitir conexões da instância Docker para o host nas portas de validação necessárias. Trabalhando com clientes ACME Com o ambiente de desenvolvimento em execução, os endpoints ACME são expostos ao host em http://localhost:4001/directory (ACME v2, HTTP) e https://localhost:4431/directory (ACME v2, HTTPS). Usar os endpoints HTTPS requer configurar o cliente com um truststore contendo o certificado CA test/certs/ipki/minica.pem. Como o resolvedor falso retorna 127.0.0.1 para qualquer consulta, certificados podem ser emitidos para qualquer domínio como se resolvessem para localhost; alterar FAKE_DNS altera o endereço retornado, e frequentemente é definido como a máquina host que executa o cliente ACME. O README mostra a execução do Certbot contra um Boulder local com uma variável de ambiente SERVER personalizada e a opção --standalone. Notas de produção O projeto afirma que o Boulder é feito sob medida para o Let's Encrypt e destinado apenas a suportar a Web PKI e os requisitos de linha de base do CA/Browser Forum. Observa que o Boulder frequentemente não é a escolha certa para organizações que o avaliam para produção, e que uma PKI gerenciada centralmente sem autorização de domínio ACME geralmente é uma escolha melhor. Um guia de implantação e implementação é oferecido, descrevendo o trabalho necessário e as considerações de segurança. O ambiente de desenvolvimento baseado em Docker explicitamente não é adequado para produção: usa material de chave privada publicamente disponível, expõe portas de depuração e é frágil a falhas de componentes. O suporte e o desenvolvimento priorizam a missão do Let's Encrypt, portanto, suporte oportuno ou pull requests que se desviem significativamente dos objetivos de primeira linha podem não ser aceitos. Contribuição e licença Diretrizes de contribuição, processo de revisão de código, código de conduta e outras dicas estão em CONTRIBUTING.md; o código de conduta da comunidade é referenciado no fórum da comunidade Let's Encrypt. O projeto é licenciado sob a Mozilla Public License 2.0.