Setting up a perfect x509 certificate management infrastructure using acme-dns
Duration: 2 hours
Joona Hoikkala is a privacy and security enthusiast hacker and open so(u)rcerer involved in projects like Certbot, acme-dns and ffuf. Approaches problems from purple teamer perspective.
Abstract: Learn how to set up a no-compromise ACME certificate validation infrastructure that doesn't require opening ingress traffic to the boxes needing to handle the certificates. The workshop will go through the typical security failures that users are making when using DNS validation and automation of ACME certificates, and focuses on building a micro infrastructure that addresses these issues and allows people to handle the automation in a flexible way. The most common security pitfalls will be pointed out and addressed, providing few valuable crumbs of knowledge to red teamers as well.
Learn how to set up a no-compromise ACME certificate validation infrastructure that doesn't require opening ingress traffic to the boxes needing to handle the certificates. The workshop will go through the typical security failures that users are making when using DNS validation and automation of ACME certificates, and focuses on building a micro infrastructure that addresses these issues and allows people to handle the automation in a flexible way.
Let's Encrypt provides two (three in the future when ALPN method lands) methods of proving your ownership over a domain for certificate validation, namely DNS and HTTP validation. HTTP validation requires the server validating a certificate to allow ingress connections to port 80, which renders it unusable for some scenarios. In addition to that, some features that Let's Encrypt provides are tied to DNS validation, namely wildcard certificates. DNS validation also provides more flexibility, as the validation token is fetched from the authoritative DNS servers of a domain - meaning that no ingress traffic needs to be allowed for the server requesting a certificate. An longstanding issue with DNS validation and its automation however is that in order to make the certificate renewals to work, the users will need to store credentials for updating the DNS records of said domain on every box renewing their certificates using this validation method. Needless to say, getting one of said boxes compromised leads to attacker usually gaining control over the whole DNS zone, and being able to pivot from there by capturing all e-mail traffic for example.
These issues can be completely eliminated by using a self hosted instance of a software called acme-dns - a limited DNS server providing HTTP API to update its ACME validation records - and nothing more. In short, it's tailored for this very narrow use case. Technically this means setting up your own acme-dns instance, pointing a NS record for a domain apex to its IP address making it the authoritative DNS server for all requests under its domain. For example NS record for acme-dns.example.com makes the server responsible for answering DNS requests for names like: 1.acme-dns.example.com and a.really.long.one.acme-dns.example.com. This combined with CNAME records for the "magic" validation subdomain - namely _acme-challenge.example.com - used by ACME protocol makes it trivial to point these validation subdomains to an acme-dns instance, thus enabling the user to handle certification validation automation while saving credentials with minimum possible permissions to the box itself.
- Going through the mentioned security issues in detail, and with examples (good additions to red team toolkit)
- Setting up a virtual machine for acme-dns
- Installing and configuring acme-dns software
- Setting up the DNS records to the main validation zone to allow acme-dns instance to handle certain names
- Examining the acme-dns API, and the additional features like source IP whitelisting
- Setting up different ACME clients capable of handling the acme-dns validation automation
- Internet connection, we're making this live
What is provided:
- Test domains
- Virtual machines for running acme-dns and demonstration client, provided by UpCloud.com. Participants will leave with a working infrastructure that they can keep using in the future if desired.