How Phishing Sites Use Let's Encrypt Certs on IP

Phishing sites have started using Let's Encrypt certificates on raw IP addresses - not on domains. The shift is simple but effective: security filters that flagged plain HTTP URLs pointing to IPs can no longer easily distinguish malicious from legitimate when the same IP now serves a valid HTTPS certificate, issued by a trusted CA, at zero cost.

This is not a Let's Encrypt problem. It's a filter maintenance problem that defenders need to think through.

How Let's Encrypt Issues Certificates for IP Addresses

Let's Encrypt runs an ACME (Automated Certificate Management Environment) server. The standard ACME HTTP-01 challenge works by placing a file at a specific path on the target server. For domain names, the CA verifies you control the DNS. For IP addresses, the same HTTP-01 challenge applies - the CA verifies that you control the server at that IP.

There is no DNS involvement. No domain ownership required. A server with a public IP and a web-facing HTTP port can get a certificate for that IP alone, valid for 90 days, renewable automatically, at no cost.

The relevant LE policy: Let's Encrypt has issued certificates for IP addresses since 2018, under CA/Browser Forum baseline requirements. IPs are limited to IPv4 and IPv6 addresses the requestor demonstrates control over. The certificates look just like any other LE cert - they chain to the same ISRG Root X1, trusted by all major browsers and operating systems.

The result is a valid, browser-trusted certificate on an IP address that any security filter might have previously assumed was safe because HTTPS on an IP used to mean "a real server with a real certificate, likely legitimate."

Why Raw-IP HTTPS Now Evades Traditional URL Filters

Historically, email security filters scored URLs in several ways:

Plain text URLs with IP addresses - many filters flagged these as suspicious by default, because legitimate email rarely contains a link to a raw IP

HTTP URLs without HTTPS - some filters applied lower trust scores to non-HTTPS links in email

Known malicious IP blocklists - static IP reputation lists flagged known bad actors

The problem is that none of these scoring mechanisms account for what happened next: a trusted CA started issuing browser-trusted certificates to IPs, and the IPs started hosting convincing phishing pages.

When a phishing URL now looks like `https://45.33.32.156/setup.exe` instead of `http://45.33.32.156/setup.exe`, several things change for the filter:

HTTPS on an IP is no longer unusual enough to score down

The certificate is valid and trusted, so SSL inspection may not trigger

The URL appears to pass basic reputation checks that would have caught the HTTP version

The filter's assumptions broke. The signal changed, but the scoring rules didn't update.

Detection Signals for Defenders

The key to catching this is understanding what makes a certificate-on-IP suspicious, independent of the URL itself. A few concrete signals:

**Certificate issued directly to an IP**

This is rare for legitimate use. When you inspect the certificate details and the Subject or Subject Alternative Name (SAN) field contains only an IP address (no domain), that is an unusual configuration. Legitimate HTTPS on servers almost always uses a domain name, even internal ones. Score this as higher-risk.

**Certificate issued very recently to an IP that has never had one before**

Certificate Transparency (CT) logs are publicly accessible. If an IP that has never had a certificate suddenly receives a new LE cert, that's a strong signal of a new host - possibly a phishing host that appeared quickly and will disappear after the campaign. CT logs can be queried retroactively.

**Certificate subject doesn't resolve in DNS**

If the certificate was issued to `45.33.32.156` but nothing resolves to that IP in public DNS, that's unusual. Most legitimate web servers have both a certificate and a DNS name. This gap is a useful scoring factor.

**Newly observed IP hosting a login page for a known brand**

Phishing campaigns often replicate login pages for Microsoft, Google, or financial brands. If a newly certified IP serves a fake Office 365 login page, that's not a certificate problem - it's a brand impersonation problem. The certificate is just enabling the impersonation to appear more credible.

**Low reputation scores on the IP in threat intelligence feeds**

Some TI vendors now flag IPs with LE certificates that have short lifespans and appear in phishing-related URL patterns. This is a maturing detection category.

What This Attack Does Not Bypass

The critical point: certificates on IPs do not bypass domain-level email authentication. SPF, DKIM, and DMARC are entirely unaffected by this technique because they operate on domain names in the SMTP envelope and message headers - not on URLs in the message body.

A phishing email with a link to `https://45.33.32.156/fake-login` can still be evaluated by DMARC, SPF, and DKIM on the sending domain. If the sending domain has a strong p=reject policy and the phisher's domain has no authentication, DMARC will fail regardless of what certificate is on the IP. The attack works against URL filters, not against email authentication protocols.

This is worth stating clearly: domain-based email authentication catches phishing that certificate-based evasion cannot. The attacker avoids domain-level authentication by not using a domain in the first place - which means the email's From domain can be checked and will fail authentication if it's being impersonated.

What Defenders Should Update

If you maintain URL scoring rules in your email gateway, SEGs, or SOAR platform:

1. **Add IP-based certificate inspection to your scoring logic** - if the certificate SAN contains only an IP with no associated domain, flag it for review

2. **Track CT logs for newly issued certificates on IPs** - automated monitoring of certificate issuance to IPs can surface new infrastructure before it's used widely

3. **Cross-reference brand impersonation URLs with CT data** - if a known phishing domain resolves to an IP that just received a LE cert, that's a high-confidence detection

4. **Do not block Let's Encrypt wholesale** - LE serves millions of legitimate sites; blocking it will break legitimate email. Score, don't block

The underlying principle: certificates were never a trust signal for IP addresses. The fact that a trusted CA issues them to IPs doesn't change what the certificate actually proves - that someone controlled the IP at the time of issuance. That proof has the same value for a phishing host as for a legitimate one.

The Bottom Line

Phishing operators found that valid HTTPS on a raw IP is enough to get past filters that were scoring plain HTTP IPs as suspicious. That's not a sophisticated attack - it's a basic adjustment that exploits outdated scoring rules.

The fix isn't to distrust Let's Encrypt. It's to update URL scoring logic to evaluate certificate-on-IP as a distinct signal, not as a trust indicator. And to remember that email authentication - SPF, DKIM, DMARC - operates on a completely different layer and remains unaffected.

Domain-based authentication doesn't care what certificate is on the destination IP. It only cares whether the sending domain's authentication records match. That's why strong DMARC policy catches phishing that URL filters, even sophisticated ones, can miss.

**Frequently asked questions**

**Q: Can I just block all URLs with IP addresses in them?**

A: You can score them higher, but some legitimate internal tools use IP-based URLs. A blanket block will break some business workflows. Score and flag instead of blocking.

**Q: Do all Certificate Authorities issue certificates for IP addresses?**

A: No. Let's Encrypt and a few others under CA/Browser Forum rules, but not all CAs support IP certificates. Most still only issue to DNS-proven domain names.

**Q: Can I detect this through Certificate Transparency logs?**

A: Yes, if you have access to CT log data. Services like crt.sh let you search by IP, though CT data at scale requires API access or a commercial CT monitoring service.

**Q: Does this affect links in emails or only the web pages themselves?**

A: It affects both. Email security filters inspect URLs in the message body. A link to an IP with a valid HTTPS certificate will likely score differently than the same link with HTTP - which is the entire point of the evasion.

**Q: Is this related to Spoofing or Business Email Compromise?**

A: It's a delivery mechanism that can be used in BEC and credential phishing campaigns. The certificate on the IP doesn't authenticate the sending domain, so DMARC alignment checks on the email's From address still apply and will fail if the domain is being impersonated.