Project

General

Profile

Actions
History

DuckCorp-Infra »

PKI

Self-Signed CAs

Current Status

These self-signed Cas are in use in DC's infrastruture:
  • duckcorp : the main CA, we plan to continue using it for non-user-facing services
  • duckcorp-backup : used for our backup software to secure TLS communications
  • duckcorp-monitoring : used for our monitoring software to secure TLS communications

The duckcorp-backup and duckcorp-monitoring CAs could have been sub-CAs but our tool does not support it.

Managing Certificates

We use mkcert manually to generate and renew certificates. It can be run in place in our infra repository, as described in source:README.md.

Let's Encrypt

Current Status

All user facing services are using Let's Encrypt or soon are (#676).

Managing Certificates

Web certificates are easy to create, as certbot can use the web server for its challenge. The httpd Ansible role automates the creation of Let's Encrypt certificates using this method.

Non-Web certificates are more tricky, as we do not want to install a web server on all machine, thus we rely on the DNS challenge. With this method certbot needs to be able to update the zone but we do not want it to become fully dynamic. Fortunately there is a patch to follow CNAMEs it is not yet integrated upstream but working very well. With is patch it is possible to delegate the RR to update to another zone. For example _acme-challenge.mx1.duckcorp.org is CNAMEd to _acme-challenge.mx1._kage.duckcorp.org; duckcorp.org remains static and managed as usual while the shadow zone, kage.duckcorp.org, is dynamic and can receive updates. We created a key for each machine and the DNS master has an extensive ACL list, allowing updates to specific machine and RR couples. The kage.duckcorp.org zone does not need to have slaves for such volatile challenges, but this zone is also used for DANE, so we added the usual set of slaves and reduced the TTL a lot to not hinder propagation.

After the certificate is created, it needs to be deployed. Certain services run as root or are dropping privilege after reading the config and can access the certificate directly in the certbot directory. Other service would lack permissions thus we created a certbot hook dc_cert_renewal_deploy that takes care of copying the files and set the proper permissions.

After deployment the service needs to be notify of the change. Sometimes it can be reloaded (often using SIGHUP or SIGUSR1/2) but sometimes it needs to be restarted (we try to avoid). The certbot hook dc_cert_renewal_restart_services takes care of this task.

DANE

DANE is a security protocol used to reinforce TLS certificate validation by publishing certain information in the DNS. It requires your DNS zones to be secured using DNSSEC.

Current Status

Our zones are DNSSEC secured and we publish DANE-EE TLSA DNS records for the leaf certificates.

Services supporting DANE (or WIP):
  • Postfix
  • Web vhosts do not have a TLSA record yet, but this is coming (#675).

Managing Certificates

For certificates managed with our own main CA we use the adm_publish_tlsa script in our infra repo to scan the certificates in pki/ and generate TLSA RRs. In our DC and MP zones we include a TLSA-dedicated file which is filled with the generated records. Finaly the script reloads the zones.

For certificates generated with Let's Encrypt, we created the srv_cert_tlsa_gen script to generate and update a TLSA RR on the shadow zone. We use the same system with CNAMEs to delegate the RR from the main zone. Currently the script needs to be told the name of the shadow zone but there is a plan to make it follow CNAMEs like certbot. The script is called in the dc_cert_renewal_restart_services hook in order to update the RR whenever the certificate is renewed.

Checking DANE

The danetls tool is not packaged but there is a web service called danecheck by the same author.

DANE adoption

These are just notes to check on DANE adoption in various client software.

Updated by Marc Dequènes about 4 years ago · 7 revisions