The Electronic Frontier Foundation's Certbot team shipped support for a capability Let's Encrypt had already made generally available: certificates that secure a specific IP address directly, rather than a domain name. Certbot 5.3 added a --preferred-profile flag for selecting certificate profiles, and 5.4 followed with an --ip-address flag specifically for requesting this new certificate type.
Why an IP address certificate is a genuinely new thing
Public certificates have always been issued for domain names — a certificate for 203.0.113.5 directly, with no domain involved at all, wasn't something a publicly trusted CA offered. This matters for infrastructure that's reachable by IP without a stable domain name attached: some internal tooling, certain IoT and embedded device scenarios, and services that specifically want to avoid any DNS dependency at all. Requesting one still starts the same way as any other certificate — with a CSR, just naming an IP address instead of a hostname.
How to try it
sudo certbot certonly --staging \
--preferred-profile shortlived \
--webroot \
--webroot-path /var/www/html \
--ip-address YOUR.IP.ADDRESS.HERENote the --staging flag — worth testing against Let's Encrypt's staging environment first, since IP address certificates are issued as short-lived (6-day) certificates specifically, a meaningfully different renewal cadence than the certificates most sites are used to managing.
Why short-lived and IP-address certificates arrived together
Both capabilities shipped as part of the same underlying infrastructure work, and both point in the same direction as this year's broader certificate lifecycle trend: shorter validity windows, more automation, and less reliance on long-lived, manually-managed credentials.
This is our own summary and analysis of publicly reported news, written independently — not a reproduction of any single source's article. Where we reference a specific announcement, we link to it or name the organization directly.