Tinklaraštis

On July 1, 2025, Let’s Encrypt announced a significant expansion of its services: it has begun issuing HTTPS certificates for IP addresses (not just domain names). This means that a server identified solely by an IP address (for example, 192.0.2.123 or an IPv6 address) can now obtain a publicly trusted TLS/SSL certificate to enable secure HTTPS connections – without needing any domain name. Let’s Encrypt has already issued its first IP address certificate in a test environment and plans to gradually roll out IP certificate support to all users, with general availability expected later in 2025. This post explores what this new capability entails, why it’s significant for the web ecosystem, the technical and policy considerations behind it, and how you can obtain and use an IP address certificate from Let’s Encrypt.

What Are IP Address Certificates?

In the context of HTTPS, a certificate is typically associated with a domain name (such as example.com). Web browsers and users rely on domain names because they’re human-friendly, and the Domain Name System (DNS) maps those names to the numeric IP addresses of servers. This indirection provides flexibility: a website can change its hosting provider or server IP address, and by updating its DNS records, it doesn’t need a new certificate every time the IP changes. For nearly a decade, Let’s Encrypt (and most certificate authorities) only issued domain-validated certificates for precisely this reason – it aligns with how people use the web.

By contrast, issuing certificates directly for IP addresses has been less common. IP addresses are the numerical codes that underlie the internet (e.g. 54.215.62.21 for IPv4, or 2600:1f1c:446:4900::65 for IPv6). Technically, nothing is preventing an X.509 certificate from containing an IP address as the subject (in the Subject Alternative Name field) instead of a domain name. Industry standards have always allowed IP address certificates, and a handful of certificate authorities have offered them on a limited basis. However, IP address certificates were rare due to practical challenges: IP addresses often change or get reassigned, especially dynamic addresses provided by ISPs to home users, making them a shaky foundation for long-lived certificates. There’s also a weaker sense of “ownership” for IPs – you might control an IP today, but it could be someone else’s next month if it’s not static. Due to these issues, Let’s Encrypt held off on supporting IP certificates until specific safety measures (like very short certificate lifetimes) were in place.

Now that Let’s Encrypt is introducing support for IP address certificates, it’s essentially allowing the same secure HTTPS padlock you see for websites to appear even when you visit a service by its raw IP. This is accomplished by issuing a certificate that lists an IP address as the identifier, which browsers will accept when you connect to that IP over HTTPS (just as they do for domain names, provided the certificate matches). It’s a significant change that broadens the scope of encryption on the web.

Why This Is Significant for the Web

Enabling SSL/TLS certificates for IP addresses is a notable development for the web ecosystem. It opens up new possibilities for secure HTTPS access without a domain name, a long-standing request from many developers and system administrators. In the past, if you tried to serve a website or API solely on an IP address, you had no easy way to get a browser-trusted certificate for it (unless you purchased one from the few CAs offering such certs, often at a cost). This meant users connecting to an https://IP_address URL would encounter browser warnings or be forced to use self-signed certificates. Now, Let’s Encrypt is filling that gap by providing free, publicly trusted certs for IPs, which is a big step toward making all internet traffic encrypted – even for services that operate outside the realm of traditional domain names.

While most websites will continue to use domain-based certificates (since users generally find sites by name, rather than by numeric address), this new capability is instrumental in specific scenarios. Some examples of where IP address certificates can make a difference include:

• Direct IP Website Access (No Domain): For individuals or small businesses that don’t have a registered domain name, an IP address certificate still allows them to offer HTTPS. For instance, if you run a personal server at home on your public IP, you can now secure it with Let’s Encrypt. Visitors using your raw IP address in the browser will see a valid padlock instead of a certificate error, albeit with the caveat that IP addresses may be more complicated to remember than domains.

• Hosting Provider Default Pages: Hosting companies can install an IP certificate as the default for their servers’ bare IP addresses. This way, if someone accidentally visits https://<server-ip> directly (instead of a proper domain), they won’t get a scary browser warning. The connection will be encrypted and trusted, providing a more professional appearance and a safer fallback page.

• Infrastructure Services (DoH and APIs): Services such as DNS over HTTPS (DoH), VPN endpoints, or other API endpoints often rely on fixed IP addresses (for performance or to bypass specific DNS-based blocks). With IP certificates, these infrastructure services can present a valid certificate tied to their IP, simplifying client trust. For example, a DoH server can prove its identity with a publicly trusted cert even if a client connects via a literal IP address. This can help clients enforce encryption (requiring a valid cert) when connecting to such services.

• IoT and Home Devices: Many home users and IT enthusiasts access devices on their network (such as network-attached storage, cameras, or IoT gadgets) via a public IP address (often a static IP or using port forwarding) without a domain name. Now those devices can be set up with a Let’s Encrypt certificate for their IP, so that remote access over HTTPS is encrypted and doesn’t trigger security warnings. This is especially useful for home labs or small business setups where obtaining a domain might be overkill.

• Ephemeral or Internal Cloud Services: In cloud environments, servers or containers may be spun up temporarily with only an IP address and no stable domain name. Previously, securing direct connections to these on-the-fly resources was difficult. With IP certificates, one backend server can securely connect to another over HTTPS using the IP address, which is particularly useful for internal APIs, microservices, or admin interfaces that are short-lived or lack DNS names. It enables encryption in cases where setting up DNS records may not be practical or fast enough.

Overall, this expansion by Let’s Encrypt strengthens the web’s security by addressing use cases that were previously left unaddressed. It ensures that even if a service doesn’t have a “human-friendly” name, it can still protect user data in transit with encryption. As a result, more traffic can be locked down against eavesdropping or tampering, contributing to a more secure internet across the board.

Technical and Policy Considerations

Issuing certificates for IP addresses involves several important technical and policy considerations. Let’s Encrypt has carefully implemented this feature to maintain trust and security. Here are the key points to know about how IP address certificates work under the hood and the rules around them:

• Short Lifespan Certificates: All IP address certificates from Let’s Encrypt are issued as “short-lived” certificates, with a validity of roughly 6 days (144 hours). This is much shorter than the standard 90-day lifetime of Let’s Encrypt’s regular domain certificates. The reason is to mitigate risks associated with IP addresses – since an IP can quickly change hands or be reassigned, a short-lived certificate limits the window of trust. If the ownership of an IP address changes or a certificate’s private key is compromised, the certificate will expire on its own within days, significantly reducing the potential for misuse. (Short-lived certs also minimize reliance on revocation checks, which have historically been unreliable.) This policy means that anyone using IP certificates must be prepared to automate renewals frequently; however, modern ACME clients are designed for automation anyway.

• ACME Client Requirements (Profiles): To request an IP address certificate, your ACME client software (the tool that interacts with Let’s Encrypt) needs to support a new mechanism called ACME certificate profiles. Essentially, Let’s Encrypt requires that the client explicitly request the short-lived certificate profile when an IP address is included in the request. Many popular ACME clients have already added support for these profiles or will soon, but you may need to update to the latest version of your client. In practice, this profile mechanism is what tells the Let’s Encrypt server, “I’m okay with a 6-day cert for this IP.” If your client doesn’t request the short-lived profile (or doesn’t support IP identifiers at all), the request will be rejected by Let’s Encrypt’s API.

• Validation Methods – No DNS Challenges: To issue any certificate, Let’s Encrypt must validate that the requester controls the domain (or IP) in question. For IP address certificates, only the HTTP-01 and TLS-ALPN-01 challenge methods are allowed. These methods involve proving control by running an HTTP server on port 80 of the IP, or a TLS service on port 443 of the IP, respectively, to respond to a token that Let’s Encrypt provides. Notably, the DNS-01 challenge is not supported for IP certificates, because DNS-based validation doesn’t make sense for bare IP addresses. (There’s no domain to add a DNS TXT record to, and no reliable WHOIS or DNS record equivalent to prove “ownership” of an IP in the ACME process.) Similarly, DNS-based CAA records – which let domain owners restrict certificate issuance – have no equivalent for IP addresses, so Let’s Encrypt skips CAA checking for IP certificate requests. The bottom line is that if you want a certificate for an IP, you must be able to host a service on that IP (either an HTTP server or a TLS listener) to complete the ACME validation.

• Gradual Rollout and Monitoring: Let’s Encrypt is introducing IP certificates carefully. As of the announcement, this feature is available only in Let’s Encrypt’s staging environment (a test sandbox) for initial rollout. They plan to gather feedback and ensure everything works smoothly before enabling IP certs in the production (live) environment. General availability in production is expected later in 2025, likely coordinated with the broader rollout of short-lived certificates for the public. Until then, issuance might be limited to certain testing partners on a case-by-case basis. This cautious approach enables Let’s Encrypt to monitor any issues (such as misissued certificates or new security considerations) and adjust policies as needed. So far, the issuance of IP certificates has been done incrementally and with oversight, reflecting the significant impact this change will have on the Web PKI ecosystem.

In summary, Let’s Encrypt’s support for IP addresses comes with extra safeguards – short-lived certs, required client updates, and restricted validation methods – to ensure that this new capability doesn’t introduce security holes or operational problems. These measures address the inherent challenges of IP identifiers, and they align with Let’s Encrypt’s mission to keep automation and security at the forefront.

How to Obtain and Use an IP Address Certificate from Let’s Encrypt

For server operators and enthusiasts eager to take advantage of this feature, here’s a practical guide to getting an IP address certificate from Let’s Encrypt. Please note that as of mid-2025, you may need to utilize the staging environment or specific client settings to obtain an IP certificate, as full production support is still pending. The process will evolve, but the general steps are as follows:

1. Ensure You Have a Stable, Public IP Address: First, identify the public IP address of the server or device you want to secure. It should be an IP that you control and one that can be reached from the internet. If the IP address is dynamic (i.e., it changes periodically) or behind a carrier-grade NAT, consider that an IP certificate may become invalid when the IP address changes. Ideally, use a static IP or be prepared to update your setup if the IP shifts. Remember that the certificate will only be valid for the exact IP address. If your ISP assigns you a new address, you’ll need a new certificate for the new IP address.

2. Use an ACME Client that Supports IP Certificates: Ensure you have an ACME client (such as Certbot, ACME.sh, or Caddy) that is up-to-date and supports the new IP identifier and short-lived certificate profile. Many clients have already added preliminary support since Let’s Encrypt’s announcement. For example, you might need to install a beta version or enable a feature flag in some clients to allow requesting a certificate for an IP address. Check your client’s documentation or release notes for “IP certificate” or “short-lived certificate” support. If your current client doesn’t support it, you may need to switch to one that does (or wait for an update to be released).

3. Test in Let’s Encrypt’s Staging Environment (Optional but Recommended): Since IP address certificates are new, it’s wise to do a trial run in Let’s Encrypt’s staging environment before trying the real thing. The staging environment is a testing service that works like production but issues untrusted test certificates (so you won’t accidentally hit rate limits or jeopardize a real certificate during testing). Most ACME clients let you point to the staging server easily – for instance, with Certbot, you can use the --test-cert flag to obtain a certificate from staging instead of production. This way, you can verify that your setup (firewall, ports, client commands) is correct. Keep in mind that a staging certificate won’t be trusted by browsers (a test CA signs it), but you can at least confirm the issuance process works.

4. Request a Certificate for the IP Address: Run your ACME client to initiate a certificate request for your IP. This typically means providing the IP as the identifier, similarly to how you would for a domain name. For example, with many clients, you might specify the IP in place of a domain, such as:

   bash
   
   # Example using Certbot (hypothetical syntax)
   certbot certonly --standalone -d 203.0.113.45 --preferred-challenges http
   

   The above is an illustration – in practice, Certbot or other clients may have special options (or automatically switch to short-lived mode) when an IP is detected. The key is that the client must signal the short-lived certificate profile to Let’s Encrypt (often this is automatic if the client knows you asked for an IP). When you run the client, it will proceed to perform the validation challenge. Depending on which challenge you choose, ensure that:

   • For the HTTP-01 challenge, port 80 on the IP address is open and directed to the machine running the ACME client. The client will temporarily serve a token on http://<your-ip>/.well-known/acme-challenge/… for Let’s Encrypt’s validation server to fetch.

   • For TLS-ALPN-01 challenge: Port 443 on the IP is open. The client will bind a temporary service to handle a special TLS handshake on that port to prove control of the IP.

   You cannot use the DNS-01 challenge for IP certificates, so one of the above must work. If you’re requesting a home connection, you might need to adjust your router’s port forwarding to allow the Let’s Encrypt validators to reach your machine. On a cloud server or VPS, ensure that any cloud firewall permits the required port. The ACME client should report back when the challenge is completed successfully.

5. Obtain and Install the Certificate: Once validation succeeds, Let’s Encrypt will issue the certificate. Your ACME client will save the certificate and private key (for Certbot, typically under /etc/letsencrypt/live/<identifier>/). The certificate’s Subject Alternative Name (SAN) will include the IP address you requested. Now you can install this certificate in your web server or application just as you would for any domain certificate – the process of installation is the same (update your server’s SSL/TLS configuration to use the new cert and key files). For example, in an Nginx or Apache config, you’d point the ssl_certificate and ssl_certificate_key directives to the files provided by the client. Once installed, try accessing your service via https://<your-ip>/ and you should see a secure connection without browser warnings. The certificate will show your numeric IP in the details.

6. Automate Renewal: Given the short 6-day lifespan of IP address certificates, automation is not just convenient – it’s essential. You’ll want to have your ACME client renew the certificate frequently (most clients will attempt renewal halfway through the validity period or sooner for short-lived certs). Ensure that the command used to obtain the IP certificate can be run periodically (via a cron job or system service). In staging or testing, you may want to practice a couple of renewal cycles to ensure it works seamlessly. When Let’s Encrypt enables IP certs in production, the same automation should apply. If using Certbot, it will automatically attempt to renew certificates it has issued. For other clients, configure their renewal timers according to their documentation. The goal is always to get a new certificate before the old one expires, so your HTTPS service remains uninterrupted. Since the certificates are only valid ~6 days, you might renew every day or two. This sounds frequent, but ACME is designed to be lightweight and run unattended – and short-lived certificates eliminate much of the risk if something goes wrong, since you can quickly obtain a new one.

By following the above steps, you can start experimenting with Let’s Encrypt’s IP address certificates. During this early phase, you may need to troubleshoot issues (for example, some ACME clients may still be updating their support, and firewall/port issues are common hurdles in validation). The Let’s Encrypt community forum is a good place to seek help if you encounter problems. As the feature moves to general availability, the process will become more streamlined and documentation from Let’s Encrypt and ACME client developers will become more readily available.

Conclusion

Let’s Encrypt’s move to support IP address certificates is an exciting development for internet security. It extends the reach of HTTPS to corners of the web that previously had to remain unencrypted or use self-signed certificates. With this new capability, any service reachable at a public IP – whether it’s a hobby project on a home connection, a piece of network infrastructure, or an ephemeral cloud service – can potentially be secured with a free, trusted certificate. This change has been implemented thoughtfully, with short-lived certificates and proper validation methods to maintain the security standards users expect from Let’s Encrypt.

For most website owners, domain-based certificates will remain the norm. However, those with special use cases now have a robust option to adopt best practices (encrypt everything) even without a domain. As Let’s Encrypt continues to roll out IP address support into production, we can expect to see more widespread adoption of HTTPS in places where it wasn’t previously feasible. It’s another step toward the organization’s mission of encrypting the entire internet – now not just every website, but potentially every IP address can be part of a safer, privacy-respecting web.