Let’s Encrypt IP SSL: Secure HTTPS Without a Domain

Let’s Encrypt IP SSL: Secure an IP Address with HTTPS Without a Domain Name

Let’s Encrypt, the free and open-source certificate authority, now offers SSL/TLS certificates for IP addresses, without requiring a Fully Qualified Domain Name (FQDN). This innovation enables encrypted HTTPS communication on servers accessible via raw IP addresses, without relying on DNS. It’s ideal for DevOps pipelines, test labs, and local or self-hosted network appliances.

Let’s Encrypt IP SSL vs Domain-Based SSL

Let’s Encrypt primarily issues free SSL certificates for domain names, but it also supports securing public IP addresses directly through the ACME protocol. This article explores how Let’s Encrypt IP SSL differs from traditional domain-based certificates and when this approach makes sense.

Let’s Encrypt IP SSL vs Domain-Based Certificates

Let’s Encrypt is historically known for issuing domain-validated SSL/TLS certificates. However, it now also supports issuing certificates directly for public IP addresses. This removes the dependency on DNS and makes it possible to secure services by IP alone.

Unlike domain-based certificates, which require a Fully Qualified Domain Name (FQDN), IP SSL certificates use the SAN field to declare the IP address (IPv4 or IPv6). This change facilitates secure deployments in contexts like DevOps, IoT, or test environments without needing to register domains.

Official Let’s Encrypt Forum Post · ACME Protocol – RFC 8555

Why Use HTTPS on an IP Without a Domain?

• Test or Staging Environments: No need to register temporary domains—launch secure interfaces instantly.
• Cloud Instances & Containers: Secure dynamic or short-lived cloud workloads with HTTPS without DNS hassle.
• Internal or Local Networks: Access NAS devices, routers, DoH/DoT services, or IoT devices without browser warnings, even without a domain.
• Use in Security-Conscious or Air-Gapped Environments: Combine IP SSL certs with self-hosted ACME setups to create secure enclaves without domain exposure or internet reliance.

Validity and ACME Requirements

Let’s Encrypt IP certificates are valid for just 6 days. This short lifetime helps enhance security by quickly invalidating certificates in case of IP address changes or misconfigurations. Source: Let’s Encrypt Forum Post Certificate issuance requires the ACME protocol, defined in RFC 8555, using the http-01 or tls-alpn-01 challenges. DNS-based validation is not supported for IP certificates. Reference: Let’s Encrypt Challenge Types To automate certificate renewal, use compatible ACME clients such as:

• Certbot Documentation
• acme.sh GitHub

Pros and Cons

DIY: Create Your Own SSL Certificate

For environments not requiring public trust, you can generate a free self-signed certificate with OpenSSL that works over an IP address.

Technical Note: Generating an IP-based certificate manually requires a Certificate Signing Request (CSR) or equivalent parameters, ensuring the IP address is declared in the SAN (Subject Alternative Name) field. Some modern browsers and systems will ignore the CN (Common Name) if the SAN is missing or incomplete.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 
-keyout server.key -out server.crt 
-subj "/CN=203.0.113.10" -addext "subjectAltName=IP:203.0.113.10"

⚠️ You’ll need to manually install this certificate in each client system or browser to avoid trust warnings.

OpenSSL directly builds this certificate inline, skipping the traditional CSR request step. Because it’s self-signed, a trusted certificate authority (CA) does not issue it. If you later decide to obtain a certificate from a CA, you’ll need to prepare a properly formatted CSR.

WordPress & IP SSL: Plugin Recommendation

In rare WordPress setups where the site is served over an IP:

• Generate an IP SSL certificate with acme.sh
• Modify wp-config.php to define siteurl as the IP
• Use the plugin Really Simple SSL to enforce HTTPS

⚠️ Some WordPress features may not function fully without a domain.

Comparison Table: Let’s Encrypt vs Other Free Alternatives

Example: Benchmark with Shell Script

You can run a real benchmark Script  using /usr/bin/time to compare performance between ACME and OpenSSL:

#!/bin/bash
echo "Benchmarking Let's Encrypt (acme.sh)..."
time acme.sh --issue --standalone -d 203.0.113.10 --server https://acme-staging-v02.api.letsencrypt.org/directory

echo "Benchmarking Certbot..."
time certbot certonly --standalone -d 203.0.113.10 --test-cert

echo "Benchmarking OpenSSL self-signed..."
time openssl req -x509 -nodes -days 365 -newkey rsa:2048 
  -keyout test.key -out test.crt 
  -subj "/CN=203.0.113.10" -addext "subjectAltName=IP:203.0.113.10"

Note:

• Replace 203.0.113.10 with your actual public IP.
• Root privileges and open ports 80/443 are required for ACME clients.
• Results can guide optimizations for secure, scalable deployments.

ACME vs OpenSSL — Performance Snapshot

ACME (Let’s Encrypt IP via acme.sh):     ~6.4 seconds
ACME (Let’s Encrypt IP via Certbot):     ~7.9 seconds
OpenSSL Self-Signed (RSA 2048):          ~1.1 seconds

Tested on:
VPS OVHcloud – 2 vCPU – 4GB RAM  
Ubuntu 22.04 LTS – Localhost Challenge

Tip: Self-signed is faster but not trusted by browsers. Use ACME for production and automation.

Live Benchmark Demo (Simulated)

Click below to simulate certificate generation speed:

Waiting for input…

Cybersecurity Considerations for IP-Based SSL

Using Let’s Encrypt IP SSL certificates introduces new security and privacy considerations, especially when bypassing traditional DNS structures.

• Public Exposure via CT Logs: Every Let’s Encrypt certificate is publicly logged through Certificate Transparency. Even without a domain name, an exposed IP may leak infrastructure details.
• Passive Scanning: Tools like Shodan or Censys index IPs with SSL. Consider firewalls or geo-fencing to restrict access where applicable.
• No PTR Record ≠ Anonymity: An IP without a reverse DNS entry may still be fingerprinted through TLS metadata or service banners.
• Short Validity, Frequent Rotation: The 6-day lifetime improves security by reducing exposure, but make sure automated renewal is robust to avoid service interruption.
• Zero Trust Implications: In Zero Trust or segmented environments, use IP SSL certificates alongside mTLS or gateway-based access control.
• GDPR Compliance: IP addresses can be considered personal data under GDPR. Ensure lawful basis and appropriate controls are in place.

Best Practice: Combine IP SSL with firewall rules, strong client authentication, logging, and certificate monitoring tools to reduce the attack surface.

Technical Glossary

• ACME: Automatic Certificate Management Environment. A protocol (RFC 8555) used to automate the issuance and renewal of certificates.
• SAN: Subject Alternative Name. A field in SSL certificates allowing multiple identifiers (e.g. IPs or domains).
• FQDN: Fully Qualified Domain Name. A complete domain name including all subdomains and the root domain.
• TLS: Transport Layer Security. The protocol that provides HTTPS encryption.
• CSR: Certificate Signing Request. A block of encoded text used when applying for an SSL certificate.
• HTTP-01: ACME challenge using a file served over HTTP.
• TLS-ALPN-01: ACME challenge using a temporary TLS certificate.
• SSL: Secure Sockets Layer. A deprecated cryptographic protocol once used for securing HTTP (HTTPS). Modern HTTPS uses TLS instead of SSL, but the term “SSL” is still commonly used to refer to HTTPS certificates.
• Benchmark Script: A shell-based automation script used to compare the performance of multiple certificate issuance methods (e.g. ACME clients vs OpenSSL) by measuring execution time and resource usage.

What This Article Didn’t Cover (Yet)

We should explore these topics in greater depth, and plan to revisit them in a future update.

• Wildcard + IP Certs: Exploring mixed SANs (domain + IP) and use cases.
• IP Certificates on Shared Infrastructures: Managing certs across virtual hosts or reverse proxies.
• Commercial vs. Free IP Certificates: Durability, legal liability, SLAs, and compatibility audits.
• Integration with Appliances and Industrial Hardware: Are SASE, ZTNA, and IoT ecosystems fully compatible?

Timeline Highlights

• January 2025: Launch of short-lived certificate support (7 days).
• July 2025: First IP address certificate issued via staging.
• Late 2025: Expected general availability of IP certificates in production.

Strategic Wrap-up: A Game Changer for HTTPS Adoption

The ability to secure raw IPs without domains makes HTTPS easier to adopt in automation, IoT, and internal infrastructures. DevOps teams benefit from agile deployments, while local services gain privacy and security.

Want to go further?

• Build CI/CD pipelines with auto-renewing IP certs
• Deploy encrypted services in air-gapped environments
• Explore compatibility with reverse proxies and smart gateways
• Benchmark ACME certificate issuance times vs OpenSSL self-signing
• Consider legal implications of public IP exposure without DNS

Legal & Security Considerations

Deploying SSL on raw IP addresses may have implications depending on jurisdiction, network policies, or data protection regulations:

• GDPR Compliance: Ensure IP-based SSL usage complies with data protection laws. See CNIL (France) or GDPR.eu.
• Network Trust Models: Some corporate firewalls and proxies might distrust certificates not tied to domains.
• Audit & Logging: Ensure secure logging and identity verification where ACME automation is involved.
• Certificate Transparency: All Let’s Encrypt certificates are public. Don’t expose sensitive IPs without awareness.
• Best Practices: Refer to NIST Cybersecurity Framework and ENISA Guidelines for secure deployment.
• Reverse DNS leaks: Serving an IP SSL without PTR can still expose servers via Certificate Transparency logs.
• Passive scanning: Some tools index IPs with SSL enabled, which can be a privacy concern (e.g., Shodan, Censys).
• Phishing via IP URLs: Untrusted users may be misled by IP‑based links with trusted padlocks; monitor Certificate Transparency and educate users.