LetsEncrypt: Shaving ~50 bytes off HTTPS certificates with tlsserver profile

ACME-profiles is a relatively new extension added to ACME, and LetsEncrypt already supports a new tlsserver profile.

An ACME-profile lets you select a set of HTTPS certificate characteristics by a profile name. For example, a particular Certificate Authority can issue a certificate from a certain intermediate certificate, using a certain validity duration, and a set of flags in the certificate based on the profile name set in the certificate request.

With a named profile, it is no longer necessary to associate an account ID (using EAB) only to obtain a certain feature.

Typically, as of now, LetsEncrypt certificates are valid for a duration of 90 days, with an authorization reuse window of 30 days, and come with certain fields such as Certificate Common Name and Subject Key ID, which are no longer strictly necessary. The latest CA/B guidelines discourage these fields, but LetsEncrypt (and other CAs) issue certificates with these profiles for compatibility with a wide range of clients. These characteristics are now collectively named as the classic profile.

LetsEncrypt's new tlsserver profile gets rid of the fields that are no longer necessary, and comes with slightly restrictive order and authorization windows. The advantage of this is that the lead certificate will now be ~50 bytes smaller.

50 bytes may not seem that much, but considering that the certificate is sent to the client for every HTTPS handshake, this can add up to a meaningful difference. Apart from the 50 bytes shaved off a certificate, the new profile is leaner, and is a good enough reason to write a blog post on a blog that I had not written anything in four years!

ACME Clients with profiles support

For this blog and several other web sites I manage, I use getssl to issue and renew HTTPS certificates. getssl is a light weight ACME client written entirely in bash, in a single file. I'm comfortable hacking it if I have to, so it's been my choice of ACME-client for many years.

getssl recently added support for ACME profiles, so I tried to obtain a certificate for aye.sh domain name using the tlsserver profile.

Quite a few ACME clients already support profiles, including the Certbot (the CLI client) and Caddy (the web server, which I also use on this site).

LetsEncrypt ACME Profiles

LetsEncrypt lists three profiles as of now:

classic	tlsserver	shortlived
Maximum duration a client can take to complete validation	7 days	1 hour	1 hour
Authorization reuse period	30 days	7 hours	7 hours
Validity	90 days	90 days	160 hours
Max No of SANs	100	25	25
Supports IP certificates	No	No	Yes
Contains Subject Common Name field	Yes	No	No
Contains Subject Key Identifier field	Yes	No	No
Contains Key Usage field	Yes	No	No
Contains Extended Key Usage field	Yes	No	No

In both tlsserver and shortlived profiles, the leaf certificates will not contain a few fields that are not strictly required or discouraged by the CA/B baseline requirements.

With the unnecessary fields/extensions removed, certificates issued with the tlsserver and shortlived profiles are ~50-60 bytes smaller.

shortlived certificates

LetsEncrypt has announced that it will support shortlived certificates that have significantly short validity periods, and with support for IP certificates.

At this time, it is not possible to use this profile, and the allowlist is not open to the public yet.

Trying tlsserver profile

Using getssl, I could easily obtain a certificate using the tlsserver profile by setting PROFILE="tlsserver" in the getssl.cfg file for the aye.sh domain name.

Upon a forced renewal, my new certificate was issued using this profile, and I can already see it's smaller!

openssl x509 -in aye.sh.ec.crt -outform DER | wc -c
851

By using an EC 256 bit certificate, I'm already using a much smaller key compared to a traditional RSA certificate. Combined with the tlsserver, the certificate is now merely 851 bytes. If I were to not combine aye.sh and www.aye.sh into a single certificate, I could have shaved off a few more bytes as well.

Potential downsides

Because the tlsserver-issued certificates do not contain the Common Name field, it can throw off certain user interfaces that use it to display a label for a certificate.

• In LetsEncrypt Discourse, someone mentioned that their Synology DSM had an issue with the certificate select list because the list uses the Common name field to populate the select list.

• crt.sh shows the Common name field in search results, but for tlsserver and shortlived certificates, this field will be empty.

---

LetsEncrypt's ACME-Profiles opens up a way to easily obtain and opt-in to certain new features, which go beyond what a typical CSR can request. Newer improvements, such as short-lived certificates and IP certificates, open up a wide range of new use cases and pave the way to an even more secure web!