Project

General

Profile

PKI » History » Version 5

Marc Dequènes, 2020-04-06 15:57

1 1 Marc Dequènes
h1. PKI
2
3
h2. Self-Signed CAs
4
5 3 Marc Dequènes
h3. Current Status
6 1 Marc Dequènes
7 3 Marc Dequènes
These self-signed Cas are in use in DC's infrastruture:
8
* _duckcorp_ : the main CA, we plan to continue using it for non-user-facing services
9
* _duckcorp-backup_ : used for our backup software to secure TLS communications
10
* _duckcorp-monitoring_ : used for our monitoring software to secure TLS communications
11 1 Marc Dequènes
12 3 Marc Dequènes
The _duckcorp-backup_ and _duckcorp-monitoring_ CAs could have been sub-CAs but our tool does not support it.
13 1 Marc Dequènes
14 5 Marc Dequènes
h3. Managing Certificates
15
16 4 Marc Dequènes
We use project:mkcert manually to generate and renew certificates. It can be run in place in our infra repository, as described in source:README.md.
17 3 Marc Dequènes
18 1 Marc Dequènes
h2. Let's Encrypt
19
20 3 Marc Dequènes
h3. Current Status
21 1 Marc Dequènes
22 3 Marc Dequènes
All user facing services are using Let's Encrypt or soon are (#676).
23
24 5 Marc Dequènes
h3. Managing Certificates
25
26 3 Marc Dequènes
TODO: more technical details
27 5 Marc Dequènes
28
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.
29
30
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":https://github.com/certbot/certbot/pull/7244; 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 _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.
31
32
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.
33
34
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.
35 3 Marc Dequènes
36 1 Marc Dequènes
h2. DANE
37
38 3 Marc Dequènes
"DANE":https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities 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":https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions.
39 1 Marc Dequènes
40 3 Marc Dequènes
h3. Current Status
41
42
Our zones are DNSSEC secured and we publish DANE-EE TLSA DNS records for the leaf certificates.
43
44
Services supporting DANE (or WIP):
45
* Postfix
46
* Web vhosts do not have a TLSA record yet, but this is coming (#675).
47
48
h3. Checking DANE
49
50
The "danetls":https://github.com/shuque/danetls tool is not packaged but there is a web service called "danecheck":https://www.huque.com/bin/danecheck by the same author.
51
52
h3. DANE adoption
53
54
These are just notes to check on DANE adoption in various client software.
55
56
* HTTPS: "plugins for majors browsers were developed and abandoned":https://www.dnssec-validator.cz/ because necessary API support in the browsers vanished and there is no replacement
57
* SMTP: seems to have gained traction, suggested by the various checkers, Postfix supports it and we support it (see [[Mail]])
58
* IMAP/POP3: "Thunderbird integration was refused":https://bugzilla.mozilla.org/show_bug.cgi?id=1479423 because it needs to be integrated in Firefox core first, but the "Firefox integration":https://bugzilla.mozilla.org/show_bug.cgi?id=672600 does not seem to go anywhere
59
* IRC: "Weechat integration":https://github.com/weechat/weechat/pull/121 is not making much progress despite a patch being available
60
* XMPP-c2s: ???
61
* XMPP-s2s: Prodosy has an "experimental module":https://modules.prosody.im/mod_s2s_auth_dane.html but it is unmaintained and supposed to crash sometimes (according to the known issues)