Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

In January 2025, Let’s Encrypt announced it would offer short-lived certificates and, this month, it did. If you’ve been following the drama about the reduction of certificate lifetimes to only forty-seven days, wondering what the fuss was about—then this will be great news for you. Now you can go as low as six days (and a few hours). In addition, for the first time ever, Let’s Encrypt is now issuing certificates for IP addresses.

Is a Six-Day Certificate Better or Worse?

Let’s unpack what’s new, why it’s happening, and what you can do with it. First, you can now use six-day certificates for your properties. If you decide to use them, it will be because you care about the potential window of opportunity for attackers who compromise your key material. The scenario here is this: Either (1) someone breaks into your servers or (2) one of your staff decides to steal the keys. Because these new certificates expire quickly, there is a very short window in which they can be exploited, compared to the previous best of ninety days. If you’re wondering why you can’t just revoke these compromised certificates, it’s because no one will notice. We wrote about the problems with certificate revocation at length last year, in response to Let’s Encrypt’s original announcement.

Clearly, not everyone is going to care enough about this. Those who do will be a potential target for someone to both steal their keys and use them in active network attacks. Think about financial institutions and very popular consumer systems, for example.

These new certificates come at a cost. If you decide to use them, you will already have automation in place, so you’ll just need to make a small configuration change. Things will continue to work. If you’re currently renewing every sixty days, these six-day certificates renew after approximately four days, so that will be a fifteenfold increase in the issuance rate. I don’t think that the increase matters a great deal as such, but the fact that you will be renewing so close to the expiration means that there will be a much slimmer margin of error. If your certificates are checked daily, then renewing thirty days before a certificate expires means you have about thirty opportunities to get a new certificate. With six-day certificates, that will probably reduce to just three opportunities. You don’t need to have people on call for this, but you will need to have people doing weekend shifts.

A few years ago, a mention of short-lived certificates would have made me worry about end user clock skew. When you’re serving a very wide audience, a lot of your customers are going to have broken clocks. This can lead to downtime even with a longer certificate, but it’s going to be worse with these very short ones. It’s not clear if this is a real problem still, because no one has complained about it in the last couple of years. But it’s something to keep in mind.

One-Day Certificates

Let’s Encrypt is not the only CA to support short-lived certificates; in fact, Google Trust Services does so as well. Further, this CA will allow you to choose the exact duration in days. That made me think about what the lowest duration we can get might be—but Scott Helme beat me to it. The answer is a one-day certificate.

Remember, just because you can get one of these, it doesn’t mean you should.

Certificates for IP Addresses

This new update from Let’s Encrypt also introduced certificates for IP addresses. Although definitely a niche use case, it’s a great thing to be able to issue certificates for network devices that need security but don’t necessarily have hostnames. Actually, it’s something we will use at Feisty Duck. In our training courses, we give our students servers to work on, and we will use IP address certificates to protect the servers’ control interfaces out of the box. There are other ways in which we could achieve the same effect, but it feels natural just to protect IP address access directly.

How Do You Get These New Certificates?

Getting a six-day certificate should be easy with any ACME client that supports profiles. With Let’s Encrypt, you just need to switch to its “shortlived” profile. I tried this with Certbot and it worked just fine. If you’re after an IP address, the latest released version of Certbot (5.2.2) doesn’t have support yet. A new release that fixes this is expected soon. In the meantime, lego worked just fine when I tried it the other day:

# lego --accept-tos --domains 206.189.27.68 --http --disable-cn \
  run --profile shortlived

Short News

• WhisperPair is a discovery of a major vulnerability in many bluetooth accessories, enabling eavesdropping and location tracking.
• In December, there was yet another disclosure of problems in the PGP/OpenPGP ecosystem (gpg.fail). Following this, Soatok wrote a thorough blog post looking at the history of email security and why it’s doomed to continue failing.
• Quantum Security 25 is a celebration of the most influential people shaping the future of quantum-secure computing. The nominations are open for another week, through February 6, 2026.
• RFC 9909 has been published to enable use of SLH-DSA in X.509. A couple of months ago, RFC 9881 did the same for ML-DSA.
• Jan Schaumann surveyed the top one million domain names for use of post-quantum cryptography to protect SMTP. He discovered that, of the main email providers, only Google, Yahoo, and Seznam had upgraded.
• The G7 Cyber Expert Group released a coordinated roadmap for post-quantum transition. If you haven’t started to work on a transition, you’re a year late.
• JP Aumasson has written a light introduction to quantum computing and its impact on cryptography, for people who are not into either computing or cryptography.
• Moxie Marlinspike wants us to have more privacy when talking to LLMs and has launched Confer, which tries hard to do the right things. It’s a good effort that relies on Trusted Execution Environments (TEEs) and transparency, but it’s not end-to-end encryption, despite the claims on its homepage.
• For a reminder that TEEs are difficult to get right: tee.fail.
• Reading about Moxie’s new venture, we came across this novel use of passkeys for encryption on the Confer blog.
• Last month we wrote about how OpenSSL messed up big time with its 3.x branch. Since then, the team behind Python’s cryptography stack wrote in more detail about their problems. If you’ve seen their video last month, you’ll know the story. But, scroll to the end where they say what they’re planning to do; in essence, they want to move away from OpenSSL.
• Speaking of OpenSSL, just a couple of days ago they disclosed twelve new vulnerabilities. That's nothing new, you might say, except that they were discovered by AISLE, which bills itself as “accelerated by AI”. LessWrong offers a good blog post from one of the researchers that gives us the background.
• Last month, Andrew Ayer wrote about how some CAs are not adding the correct Certificate Transparency proofs to their certificates.
• It was big news back in the day when we discovered that the NSA is collecting Internet traffic metadata. In Germany, it looks like they want to do the same (or keep doing it), while making it law. Up to 30% of all traffic, metadata, and content, kept for up to 6 months… That’s a lot of data.
• The USENIX Security 2026 Enigma Track Call for Participation is open. You have until March 31, 2026, to apply.
• The Security Cryptography Whatever podcast has a new episode that talks about the recent Internet voting failure involving top cryptographers themselves.