All tools

Guides Certificates

What is lencr.org, and is it malware?

Updated 8 min read

Short answer

No, lencr.org isn’t malware. It’s Let’s Encrypt’s own domain. Let’s Encrypt is the free certificate authority, and in its own words, “the data on lencr.org is never malicious.”

ye.c.lencr.org and yr.c.lencr.org serve Let’s Encrypt’s lists of revoked certificates (CRLs). Addresses ending in .i.lencr.org serve issuer certificates. These requests don’t prove the website being checked is safe.

What to do: don’t block lencr.org for this traffic alone. If something blocks it, allow outbound HTTP on port 80 to lencr.org and its subdomains. To judge the website, look at the connection just before the lencr.org one.

Run your own sites on Let’s Encrypt? It stopped emailing before certificates expire in June 2025. Expiry Watch does it for free, for up to 10 domains. Watch a domain

Why your device contacted it

Something on your network checked a certificate issued by Let’s Encrypt, and needed one of the two files that certificate points to:

  • The certificate that signed it, from an .i address, when a website didn’t send its full chain. Browsers fill that gap themselves, as Mozilla describes; most command-line tools don’t. Fix “unable to get local issuer certificate” explains why that matters.
  • The list of revoked certificates, from a .c address, when the software checks that the certificate hasn’t been cancelled.

It may not be the device you were using. Firewalls and proxies that inspect encrypted traffic check certificates for everyone behind them, so they make these requests themselves.

To find the website, look at the connection that started just before the one to lencr.org. That is Let’s Encrypt’s own advice: “focus on the connection that started just before the connection to lencr.org”.

The lencr.org request doesn’t vouch for that website. It shows only that something checked a certificate Let’s Encrypt issued, and Let’s Encrypt can’t say whether the site behind it is malicious. If the site worries you, investigate that earlier connection, not lencr.org.

If a firewall or DNS filter blocks it

Certificate traffic to lencr.org is no reason on its own to block it. Blocking it can keep devices and apps from downloading the issuer certificates and revocation lists served there, which can slow connections down or make them fail. How much depends on the client and what it has cached: Let’s Encrypt’s lencr.org page says a client may never fetch this data, may fetch only part of it, and may keep a copy until it expires.

  • Allow outbound HTTP to lencr.org and all its subdomains, on port 80. Devices on your network fetch these files, so the rule is for traffic going out; a DNS filter needs the same names allowed. A rule for one address, such as r10.c.lencr.org, breaks again when the names change, as they did with Generation Y.
  • Don’t allow HTTPS only. Certificates list these addresses as http://.
  • If a security product flagged lencr.org itself, report the false alarm to the vendor, and tell Let’s Encrypt on its community forum. Its staff have contacted vendors before.

Getting or renewing your own certificates needs different rules. Let’s Encrypt’s Integration Guide says your ACME client, such as Certbot, needs outbound HTTPS on port 443, that the HTTP-01 challenge needs port 80 open inbound, and that Let’s Encrypt’s validation requests come from addresses it doesn’t publish, which change without notice. An inbound rule that admits only lencr.org doesn’t cover them, so it can make renewals fail. Certbot renew failed explains the connection error that follows.

It has been flagged before

Security products and blocklists have mistaken lencr.org for a threat several times. Every time, it was a false alarm:

What each address serves

The middle part of the name says what kind of file an address serves, and the first part names the certificate it belongs to. We requested each of these on October 20, 2026:

Addresses What they serve Examples
*.i.lencr.org One certificate: the one that signed yours (“CA Issuers”) yr1.i, ye2.i, yr.i, x2.i
*.c.lencr.org Lists of revoked certificates (CRLs) ye2.c, yr.c, x1.c
*.o.lencr.org OCSP answers, until August 6, 2025 r3.o, r10.o, e5.o
  • .i addresses answer with a certificate file (application/pkix-cert). The first part names it: ye1 to ye3 and yr1 to yr3 are the Generation Y intermediates, ye and yr are Root YE and Root YR cross-signed by an ISRG root, x1 is ISRG Root X1, and x2 is ISRG Root X2 cross-signed by X1.
  • .c addresses answer with a revocation list (application/pkix-crl). Each root’s list sits at /, as at x1.c.lencr.org. An intermediate’s list is split into numbered files, such as ye2.c.lencr.org/96.crl.
  • .o addresses were the OCSP responders, which answered “is this certificate revoked?” one certificate at a time. None of r3.o, r10.o, e5.o or o.lencr.org resolves in DNS any more.

The ye and yr names belong to Generation Y, the hierarchy Let’s Encrypt now issues from: intermediates YE1 and YE2 (ECDSA keys) and YR1 and YR2 (RSA keys), valid until September 2, 2028, with YE3 and YR3 as backups (Let’s Encrypt’s certificate list). The older R10 to R14 and E5 to E9 intermediates are listed there as retired, though r12.i, e7.i and the rest still serve their files. Let’s Encrypt YE1 and YR1 certificates has each one’s official download and fingerprint, and Let’s Encrypt YE1 and YR1 chain errors covers what the new hierarchy changes for servers.

The OCSP addresses went quiet on schedule. Let’s Encrypt stopped putting OCSP addresses in certificates on May 7, 2025 and turned the responders off on August 6, 2025. Lookups of an .o name in your DNS logs today come from software that still expects them; nothing answers.

Why it uses plain HTTP

Certificate traffic over unencrypted HTTP looks wrong, but the rules require it. The CA/Browser Forum Baseline Requirements (version 2.3.1), which every publicly trusted certificate authority follows, say:

  • Revocation lists: “the scheme of each MUST be http” (section 7.1.2.11.2).
  • The certificate that signed yours: “A HTTP URL of the Issuing CA’s certificate” (section 7.1.2.7.7).

HTTPS would also be circular: to fetch a file over HTTPS, the client would first have to check another certificate, possibly with the same files. And encryption isn’t needed to keep the files honest. A certificate is signed by its issuer, and a revocation list is “a time-stamped list identifying revoked certificates that is signed by a CA” (RFC 5280, section 3.3), so a file changed on the way fails its signature check and is rejected.

Check it yourself

Every Let’s Encrypt certificate carries its two lencr.org addresses. You can read them from any site that uses one:

echo | openssl s_client -connect letsencrypt.org:443 \
    -servername letsencrypt.org 2>/dev/null \
  | openssl x509 -noout -ext authorityInfoAccess,crlDistributionPoints
Authority Information Access: 
    CA Issuers - URI:http://ye2.i.lencr.org/
X509v3 CRL Distribution Points: 
    Full Name:
      URI:http://ye2.c.lencr.org/96.crl
  • CA Issuers is where to download the certificate that signed this one, here the intermediate YE2.
  • CRL Distribution Points is where to download the list of certificates YE2 has revoked.

On macOS’s built-in openssl (LibreSSL), which lacks -ext, use openssl x509 -noout -text and look for the same two headings.

You don’t have to take anyone’s word for what an address serves, either. This downloads the YR1 certificate from lencr.org and prints who it is for, who signed it and its SHA-256 fingerprint:

curl -s http://yr1.i.lencr.org/ \
  | openssl x509 -inform der -noout \
      -subject -issuer -fingerprint -sha256
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR
sha256 Fingerprint=13:94:96:34:D9:9C:D6:FD:6A:A8:0B:C0:34:FE:FA:CC:EB:19:69:FE:EF:98:65:86:71:3E:CD:BB:05:75:8D:3F

Then fetch the copy that Let’s Encrypt’s certificate list links to, over HTTPS, and compare. The fingerprints match:

curl -s https://letsencrypt.org/certs/gen-y/int-yr1.pem \
  | openssl x509 -noout -fingerprint -sha256
sha256 Fingerprint=13:94:96:34:D9:9C:D6:FD:6A:A8:0B:C0:34:FE:FA:CC:EB:19:69:FE:EF:98:65:86:71:3E:CD:BB:05:75:8D:3F

A revocation list can be checked against the key that signed it. This verifies Root YE’s list with the Root YE certificate from letsencrypt.org:

curl -s -o ye.crl http://ye.c.lencr.org/
curl -s -o root-ye.pem https://letsencrypt.org/certs/gen-y/root-ye.pem
openssl crl -inform der -in ye.crl -CAfile root-ye.pem \
  -noout -issuer -nextupdate
verify OK
issuer=C=US, O=ISRG, CN=Root YE
nextUpdate=May 11 23:59:59 2027 GMT

Any other file from an .i address works the same way: swap yr1 for the address’s first part and find the matching file on the certificate list. The certificate chain checker shows which of these addresses a site’s own chain relies on.

Sources

The earlier sources were checked on October 20, 2026. Let’s Encrypt’s lencr.org page was checked again on October 27, 2026, and the Integration Guide was added and checked that day. The lencr.org page and the Root YE and Root YR entries in Chains of Trust were checked again on October 31, 2026. The address list, content types and command output come from our own requests on October 20.

Keep reading