Continuing their trend of radical change for the better, Let's Encrypt have announced that, this year, you will be able to request certificates with a validity period of only 6 days!

Let's Encrypt

I remember sitting in the room for this DEF CON 23 panel discussion in Las Vegas, almost 10 years ago in 2015(!), discussing the launch of Let's Encrypt. I also remember how utterly radical, almost to the point of ridiculous, it was, that they were going to be launching with a validity period on their issued certificates of only 90 days in the broader Web ecosystem.


Despite how limiting that would be for their adoption, because almost nobody would be in a position to automate certificate renewal and deployment that well, it was the right thing to do because it's what the industry needed. They created the demand for widespread support and use of automation by dangling a carrot, and that carrot was free certificates. Speaking on 90-day certificates, Josh Aas, executive director of the ISRG / Let's Encrypt said:

They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.

source: https://letsencrypt.org/2015/11/09/why-90-days/

In some ways, you could argue that this means the announcement of 6-day certificates is somewhat irrelevant, but I'd disagree. Yes, you can reasonably assert that anyone using 90-day certificates from Let's Encrypt is already using automation, because what sensible person would do that manually? If you're not doing it manually, it's automated, and if it's automated, the validity period of the certificate really doesn't matter at all. But, even with that said, I don't think we can underestimate the second seismic shift in our industry that Let's Encrypt are bringing about here. They're not going from 90 days down to 60 days, or 30 days, or heck, even 14 days! They're going from 90 days, straight down to 6 days, at a time when the rest of the industry is complaining about taking the first step from 398 days to 200 days as the maximum...

Don't worry, it will be opt-in

Before anyone gets too concerned about this change, 90-day certificate aren't going anywhere, and they will still be the default. To support the different types of certificates that Let's Encrypt will be issuing, they've now added support for Certificate Profiles. This is a simple way of indicating your preference for what 'type' of certificate you want from Let's Encrypt by indicating your choice of profile, and there will be a total of 3 profiles available.

Certificate Profiles

The classic certificate is the one that you will have used all along with Let's Encrypt, and will become the default option when no profile is specified, meaning nothing will change for existing users and their existing automated processes. Here are the main highlights from the traits of these certificates.

Property Value
Certificate Common Name Yes
Key Encipherment KU Yes
TLS Client Auth EKU Yes
Subject Key ID Yes
Validity Period 90 days

The next profile is the tlsserver profile, and while not the main focus of this blog post, it still has some interesting things to note.

Property Value
Certificate Common Name No
Key Encipherment KU No
TLS Client Auth EKU No
Subject Key ID No
Validity Period 90 days

In an effort to modernise certificates, and further improve performance, some redundant fields have been trimmed out of the certificate. In the past, Let's Encrypt have even registered and used shorter domains names to reduce the number of bytes in a certificate, so the ability to chop out entire fields and values is another big step forwards. There was also another round of reducing and removing fields back in 2020 too, and when you think about how many trillions of times per day that certificates are transmitted across the Internet, every single byte that you can remove translates to enormous savings!

Finally, though, we have the certificate profile that you all came here looking for;

The shortlived profile.

Property Value
Certificate Common Name No
Key Encipherment KU No
TLS Client Auth EKU No
Subject Key ID No
Validity Period 160 hours

160 hours!! How about that for a validity period! Whilst we have to wait a little longer to start playing with our own 6-day certificates, Let's Encrypt have already issued themselves one to test it out. Here's the PEM for that certificate:

-----BEGIN CERTIFICATE-----
MIIDSzCCAtGgAwIBAgISA7CwFcGk4mQWEXMacRtxHeDvMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NjAeFw0yNTAyMTkxNzMwMDFaFw0yNTAyMjYwOTMwMDBaMAAwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAAQoSItt2V1aocI5dxrKR8iLfmm0KiVvOhiwKByzu2kLeC7C
0BdfAgtwdICdkuEhAXokhXLq6DNZZgmh5T4flVwZo4IB9zCCAfMwDgYDVR0PAQH/
BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0j
BBgwFoAUkydGmAOpUWiOmNbEQkjbI79YlNIwVQYIKwYBBQUHAQEESTBHMCEGCCsG
AQUFBzABhhVodHRwOi8vZTYuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6
Ly9lNi5pLmxlbmNyLm9yZy8wKAYDVR0RAQH/BB4wHIIaaGVsbG93b3JsZC5sZXRz
ZW5jcnlwdC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwggEFBgorBgEEAdZ5AgQC
BIH2BIHzAPEAdgDM+w9qhXEJZf6Vm1PO6bJ8IumFXA2XjbapflTA/kwNsAAAAZUf
d/zOAAAEAwBHMEUCIFNd51TfSNiJrO+294t49C5ANc4oC7gTUzf7xnlNlhKsAiEA
wi5hfiC9SsKLxlTQ0sctUxhLmdYh40r6ECWQS/yWw2AAdwDgkrP8DB3I52g2H95h
uZZNClJ4GYpy1nLEsE2lbW9UBAAAAZUfd/0TAAAEAwBIMEYCIQCs2NuZIUIloOaH
1t9eXDKb8bjoWESBPsK4i2BxMvEIswIhAOMNaQNyr1YkzrcNUz15qGV0oVLg5BJN
+ikWxXOdcRHFMAoGCCqGSM49BAMDA2gAMGUCMDANqy7G09AIwzXcd7SNl7uFwhC+
xlfduvp1PeEDHc/FA9K3mRYkGXuKtzNdOh7wcAIxALjEMDmBQiwXbB447oGkaZAe
0rqxA3EtNV5wj0obeObluj/NgUsVEG9OqiBIoggFRw==
-----END CERTIFICATE-----

If we run that through openssl x509, it gives us the following output:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:b0:b0:15:c1:a4:e2:64:16:11:73:1a:71:1b:71:1d:e0:ef
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=Let's Encrypt, CN=E6
        Validity
            Not Before: Feb 19 17:30:01 2025 GMT
            Not After : Feb 26 09:30:00 2025 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:28:48:8b:6d:d9:5d:5a:a1:c2:39:77:1a:ca:47:
                    c8:8b:7e:69:b4:2a:25:6f:3a:18:b0:28:1c:b3:bb:
                    69:0b:78:2e:c2:d0:17:5f:02:0b:70:74:80:9d:92:
                    e1:21:01:7a:24:85:72:ea:e8:33:59:66:09:a1:e5:
                    3e:1f:95:5c:19
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2
            Authority Information Access:
                OCSP - URI:http://e6.o.lencr.org
                CA Issuers - URI:http://e6.i.lencr.org/
            X509v3 Subject Alternative Name: critical
                DNS:helloworld.letsencrypt.org
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : CC:FB:0F:6A:85:71:09:65:FE:95:9B:53:CE:E9:B2:7C:
                                22:E9:85:5C:0D:97:8D:B6:A9:7E:54:C0:FE:4C:0D:B0
                    Timestamp : Feb 19 18:28:32.078 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:53:5D:E7:54:DF:48:D8:89:AC:EF:B6:F7:
                                8B:78:F4:2E:40:35:CE:28:0B:B8:13:53:37:FB:C6:79:
                                4D:96:12:AC:02:21:00:C2:2E:61:7E:20:BD:4A:C2:8B:
                                C6:54:D0:D2:C7:2D:53:18:4B:99:D6:21:E3:4A:FA:10:
                                25:90:4B:FC:96:C3:60
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : E0:92:B3:FC:0C:1D:C8:E7:68:36:1F:DE:61:B9:96:4D:
                                0A:52:78:19:8A:72:D6:72:C4:B0:4D:A5:6D:6F:54:04
                    Timestamp : Feb 19 18:28:32.147 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:AC:D8:DB:99:21:42:25:A0:E6:87:D6:
                                DF:5E:5C:32:9B:F1:B8:E8:58:44:81:3E:C2:B8:8B:60:
                                71:32:F1:08:B3:02:21:00:E3:0D:69:03:72:AF:56:24:
                                CE:B7:0D:53:3D:79:A8:65:74:A1:52:E0:E4:12:4D:FA:
                                29:16:C5:73:9D:71:11:C5
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:65:02:30:30:0d:ab:2e:c6:d3:d0:08:c3:35:dc:77:b4:8d:
        97:bb:85:c2:10:be:c6:57:dd:ba:fa:75:3d:e1:03:1d:cf:c5:
        03:d2:b7:99:16:24:19:7b:8a:b7:33:5d:3a:1e:f0:70:02:31:
        00:b8:c4:30:39:81:42:2c:17:6c:1e:38:ee:81:a4:69:90:1e:
        d2:ba:b1:03:71:2d:35:5e:70:8f:4a:1b:78:e6:e5:ba:3f:cd:
        81:4b:15:10:6f:4e:aa:20:48:a2:08:05:47

As someone who deals with certificates regularly, this is really weird to see! The removed KU and EKU values, the lack of a Subject CN, the Not Before and Not After timestamps being so close together! There are so many things here that are a drastic improvement over where we currently are, it's really encouraging to think that this will become a reality in 2025, at long last.

Further Details

I've long talked about the value of reducing certificate lifetimes on this blog, in conference talks and webinars, and just about anywhere else that people would listen! The purpose of this post isn't to re-tread that same ground, though, so I won't go deep into the reasons why I think this is essential in here. I also won't go into why I believe that most of the arguments in SC-081 aren't hitting the mark as reasonable justifications to keep certificates at such long validity periods, but I may do a separate post on that if there's interest, so let me know in the comments.

One thing I can recommend is that if you really want to deepen your understanding of this ecosystem, our Practical TLS and PKI training course will do just that.

Yes, yes, I know, a shameless plug, but we've spent years making this course what it is and while we spend a lot of time with hands-on practical work building and deploying this stuff, we also talk in great detail about the realistic constraints of operating the Web PKI. So often I find that once someone has a deeper insight into how these things work, and visibility of the real challenges we're facing, much of the change that we're pushing for in this industry suddenly becomes quite reasonable...