💬 This is a comment on

6-day and IP Address Certificates are Generally Available by Matthew McPherrin (via)

Let’s Encrypt has just announced that short-lived¹ certificates are generally available. They can also be used for IP addresses, which is especially useful for DNS over HTTPS. Those certificates could be smaller in the future, if information for validity checks is omitted. However, for now at least, these certificates still include revocation information.

Using Those New Certificates With Caddy

I wanted to give those certificates a try with Caddy. Caddy needs to use the shortlived Let’s Encrypt profile. The profile feature isn’t explicitly mentioned in the docs, but some community posts use a profile directive. This also works in the global configuration:

{
	cert_issuer acme {
		profile shortlived
	}
}

Reloading the Caddy configuration was not enough to prompt an early renewal, so I deleted the underlying certificate files and restarted Caddy:

sudo rm -rf /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/example.com
sudo systemctl restart caddy

And I got a brand new certificate for my domain name, valid only for a few days. It’s marginally smaller² than with the classic profile, mostly because these short-lived certificates also use the new generation hierarchy. But they should be roughly the same size as the tlsserver profile.

Conclusion

With Caddy, certificate renewal should be automated enough that short-lived certificates don’t cause any problems. But I’ll see with this experiment if there are any surprising pain points.

My understanding is that browsers only cache TLS sessions, not certificates: when a full handshake is performed, the full certificate chain is then sent anyway³. So even if the certificate expires more frequently, it is not sent more often. The slightly smaller certificate chain is thus a small net benefit.

I host my own instance of miniflux, an RSS reader. I do it as a hobby, I enjoy the learning opportunities that come along the way.

One such opportunity presented itself in November 2023.

Back then, a Man-in-the-Middle attack was reported against jabber.ru. You can go read the full details on that blog post, but let’s go over its main aspects. Without the attacker, a client connects directly to the jabber.ru server over TLS:

TLS encrypts the connection. A certificate is also presented when the connection is established, to ensure authenticity and integrity. For this to work, the Certificate Authority (CA), a trusted third party, signs the certificate. In doing so, it affirms that it saw a given certificate associated with a particular domain¹. This protects against some Man-in-the-Middle attacks, where an attacker inserts itself between a client (say on a public wifi network) and the website, as in the next diagram. If that attacker does not manage to similarly be between the CA and the website, then it will be unable to decrypt or alter the exchange without being detected, because it can’t present a certificate signed by the CA.

Nonetheless in November 2023, a Man-in-the-Middle attack against jabber.ru succeeded. In that instance, the attacker leveraged a privileged position on the network. They intercepted all TLS traffic to the victim’s server, then tricked² the Let’s Encrypt CA into issuing a certificate for the attacker server. Then, they could decrypt the traffic from the client, re-encrypt it, potentially alter it and send it to the server.

There was no need to compromise the server for this attack to work. It simply leveraged a privileged network position.

In a reply on his blog, ACME developer Hugo Landau points out the following mitigation:

This got me thinking: how would I implement this mitigation for my self-hosted services? In this post, we will use the CAA DNS record to limit issuance to one particular account registered at one particular CA, as suggested above.

The Setup

TLS Proxy

My setup looks like this:

Here caddy acts as a TLS proxy. It manages the TLS certificate, requesting a new one from Let’s Encrypt as needed. It also terminates the TLS connection from the browser and then connects to the underlying service, like miniflux. This example could of course be generalized to any service proxied by caddy, in particular services handling more personal data, like a self-hosted webmail or contact server.

DNS

The domain hosting the RSS reader, r.cj.rs, is in fact a CNAME record pointing to the underlying machine hosting the various services, Olivine. It looks like this:

dog r.cj.rs

CNAME r.cj.rs.             5m00s   "olivine.joly.eu.org."
    A olivine.joly.eu.org. 5m00s   132.145.68.59

CAA Records

Going back to the mitigation we want to implement:

Let’s Encrypt provides some documentation for the CAA record (which stands for Certification Authority Authorization). The key points are:

• CAA records closest to the domain take priority: a CAA on r.cj.rs takes precedence over one on cj.rs.
• CAA follows CNAME redirects.
• The issue and issuewild properties control the certificate authority allowed. If only issue is present, then the same constraints apply to both normal and wildcard certificates.
• The accounturi parameter can restrict issuance to a particular account, like https://acme-v02.api.letsencrypt.org/acme/acct/1234567890

So in our case, we can simply add an issue CAA record with the accounturi parameter on the DNS record directly pointing to the machine (olivine.joly.eu.org). Then other domains can alias with CNAME to that DNS record and will inherit the CAA constraints. And if a service moves to a different server, the CAA constraint will be that of the new server, if any.

Finding the accounturi Caddy Uses

Caddy automatically creates a Let’s Encrypt account if none is configured. It then issues certificates against that account. But where is the account number?

By default on Ubuntu, the parameters for that account are stored in /var/lib/caddy/.local/share/caddy/acme/acme-v02.api.letsencrypt.org-directory/users/default/default.json³. There, the location key contains the accounturi:

{
  // ...
  "location": "https://acme-v02.api.letsencrypt.org/acme/acct/1968958296"
}

Putting It All Together

Summing up the above, we know that we need a CAA record with the issue property and the same accounturi as caddy. It looks like this in the Bind format:

IN CAA   0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1968958296"

This record is placed on olivine.joly.eu.org, where a A (or AAAA) record contains the IP address of the Olivine server. In turn, the RSS reader host is a CNAME pointing to that A record.

Testing

To test that the new setup works, we can try to issue a certificate for a new domain. Just add it to the Caddy configuration as usual, for instance like this:

test-caa.cj.rs {
  respond "Hello, world!"
}

Caddy logs should show that the certificate was successfully issued:

{
  "level":"info",
  // ...
  "msg":"certificate obtained successfully",
  "identifier":"test-caa.cj.rs"
}

You can similarly test that changing the accounturi in the CAA. After the various caches expire, attempts to issue a certificate fail:

{
  "level":"error",
  // ...
  "msg":"could not get certificate from issuer",
  "error":"HTTP 0 urn:ietf:params:acme:error:caa - During secondary validation: While processing CAA for test-caa.cj.rs: CAA record for olivine.joly.eu.org prevents issuance"
}

Just a Mitigation in the End

We have limited the certificates that can be issued to a particular CA and to a particular account. In turn, that account is tied to a private key stored on the server.

However, as Hugo Landau explains, this is only a mitigation. A well resourced attacker could still succeed. For instance, they could alter the CAA record read by the CA.

Thus, complementary defenses include monitoring certificate transparency to spot suspicious issuance. Cloudflare offers such a service. So does crt.sh. While CAs sometimes emit certificates without logging them to Certificate Transparency⁴, those certificates should be rejected by most browsers. In our case, with web services, that would be enough. Other clients communicating over TLS might not reject them though, like XMPP clients of the jabber.ru example.

Despite the limitations of this CAA-based approach, it was interesting to learn more about it and see how the various pieces fit together. I hope you enjoyed reading!