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ć.

Apple has done it again. In 2020, when CAs refused to voluntarily accept shorter certificate lifetimes, Apple forced the issue and made everyone accept lifetimes of 398 days. Because Apple is so dominant, CAs had no choice. Now, five years later, Apple has done it again and restricted certificate lifetimes to only forty-seven days. On this occasion, the decision formally happened through the CA/Browser Forum as it should have been, because there was little resistance from CAs. The conversation started in October of last year and went through several iterations. The final ballot was SC-081v3 (see the discussion and results).

We all knew this day was coming. After the initial reduction to 398 days, Google spent years saying it wanted to reduce that down to ninety days in the company’s Moving Forward, Together manifesto. That seemed like the natural next step, and so most people were surprised by Apple going further than that. If the number forty-seven seems odd to you, just think about it as monthly certificate updates with some extra time available to sort out renewal problems should they come up.

There is no reason to panic just yet: The adopted approach plans to gradually reduce maximum certificate lifetimes across several years, from the current 398 days to 200, then 100, and then finally to 47 days. The first reduction is planned for March 2026 and the last for March 2029.

In essence, the clock is now ticking for everyone to get their houses in order before it becomes untenable to replace certificates manually. ACME support is currently poor. As just one example, we at Feisty Duck recently reinstalled one of our servers that is relying on the Apache web server. Although it’s now possible to use ACME out of the box (via mod_md), there was still a steep learning curve. Most other web servers do not provide native support for ACME. Servers that make it easy are rare, with Caddy being an exception. Institutions will need to think about the following points:

• Software and hardware vendors have to implement ACME universally.
• Infrastructure that is still being supported has to be upgraded.
• Legacy infrastructure may need to be replaced. If that is not possible, then reverse proxies will have to be used as a workaround.
• There will be situations in which internal infrastructure relies on public certificates. Some companies will likely switch to private CAs rather than automate the issuance.

In parallel, the CT ecosystem will need to be upgraded. Even today, with longer-lived certificates still allowed, many individual CT logs are struggling to cope with the load. Just this month, three logs malfunctioned and had to be shut down. Between certificate lifetimes being reduced on the one hand and Let’s Encrypt offering six-day certificates soon on the other, the ecosystem will need to improve in both robustness and redundancy quickly.

Other News

• CA/Browser Forum is preparing a new ballot. SC-085, currently in the early stages, will require CAs to take DNSSEC into account when issuing certificates and validating CAA.
• Starting March 15, CAs are required to use multi-perspective issuance corroboration (MPIC) when issuing certificates. MPIC is designed to counter BGP attacks, which can be used to obtain fraudulent certificates. Additional network perspectives (currently two) can defeat the attacks. Acting on irregularities is not yet required, but it will be from September 15, 2025. From September 2026, CAs will have to use at least five remote network perspectives.
• In anticipation of Let’s Encrypt’s six-day certificate offerings, CertBot 4.0 and Caddy 2.10.0 have added support for this new certificate profile.
• The PQCrypto 2025 conference was held in Taipei, and the videos and slides are now available. For most readers, the three invited talks will be of special interest: NIST PQC Standardization Moving Forward (video, slides), State of the Post-Quantum Internet (video, slides), and Expected and Unexpected Developments in Quantum Computing (video, slides).
• SSL.com was discovered to have broken domain control validation, allowing anyone to get a certificate for any domain name where they have a mailbox (e.g., gmail.com). It doesn’t look like the problem has been exploited.
• On the topic of testing how CAs check domain control, take a look at DCV inspector, a very useful tool provided by Andrew Ayer.
• Bruce Schneier has a blog post on the US government’s recent, inappropriate use of Signal for official communication.
• A couple of months ago, we reported on the UK’s secret order to compromise Apple’s encryption and Apple’s subsequent withdrawal of Advanced Data Protection for UK customers. In a win for encryption advocates, the Investigatory Powers Tribunal ruled that the matter cannot remain secret.
• OpenSSH version 10.0 now uses the mlkem768x25519-sha256 hybrid key exchange by default. This combination of traditional and post-quantum methods is based on ML-KEM, which is a NIST standard. The previous default, sntrup761x25519-sha512@openssh.com, also hybrid, had been in use since version 9.0. (Thanks Joachim Schipper.)
• Cloudflare announced Azul, a new CT log platform built on its Workers platform and implemented in Rust.
• CT logs managed by DigiCert ran into further performance problems, which ultimately led to the premature death of Sphinx2025h1 and Wyvern2025h1, and Nessie2025. Sectigo’s CT logs are also buckling under load, as are the logs managed by TrustAsia. At the same time, monitors are complaining that they are not able to follow the Yeti2025 log due to request limits. It’s not looking good.
• Apple updated its CT policy and log program to allow for next-generation (static) CT logs.
• Pierre Barre wrote a blog post about using and optimizing Postgres for Certificate Transparency monitoring in Merklemap.
• Lukasz Olejnik wrote a blog post about the proposed solution to browser history leakage.
• Frank Denis wrote an Internet-Draft about methods for IP address encryption and obfuscation, as well as several implementations.
• libsodium-rs is a comprehensive and idiomatic Rust wrapper for libsodium.