Could you perhaps clarify a little bit more about, well, everything? Because I'm afraid I don't really understand what you're asking.. What's the situation? Which client are you referring to? What software? Et cetera et cetera.
as that is CRL(certificat revokation list) infomation points of ISRG root X1, its message is signed by root key itself, and using https there causes loop in verification (how se verify a certificate if we use same certificate to sign its revocation status?)
@orangepizza It's not just the loop, the reason HTTP is fine is because a CRL is signed. HTTPS would be redundant.
well it will cause loop in https because before read the https it will check its certificate- which will point to this endpoint again. and pointless to this message is signed. its like apt will errors then https mirror get invalid certificate, while actually authentication came from package file's gpg sign.
I didn't say it wouldn't cause a loop, I just gave another reason for using HTTP only: it's good enough.
I detected client try to request(GET Method) to http://x1.c.lencr.org manytimes in a day but client already have Root CA(ISRG Root X1) in thier notebook. I worry about BlackMatter Ransomware cause I got the alert from SOC system that detected Malicious URL from many client.
Please see the relationship as picture below.
Hosts in c.lencr.org each serve a single file that is the Certificate Revocation List (CRL) for one of our TLS Certificate Authority root certificates.
A URL with one of these CRL hostnames is embedded in Let’s Encrypt intermediate certificates, so that clients may use it to check whether the intermediate certificate is still valid.
When connecting to a site or service that presents a TLS certificate, some (not all) client applications access the CRL as part of validating the chain of trust for that certificate.
So, the connection is a non-malicious side effect of activity that may or may not be malicious. The connection is a signal that a) the host is accessing a site or service that's presenting a Let's Encrypt certificate, and b) the host is using some kind of software that does validate CRLs.
a) is not a signal you can confidently identify as innocent or malicious. You can usually ignore it and concentrate on identifying the other host(s) being accessed.
However, if the host does not routinely retrieve CRLs from the Internet, b) might be a useful signal that some non-routine software is running.
Thank you James. I found svchost.exe request c.lencr.org every 1 hour and DST Root CA X3 will expire on September 30, 2021. Did it occur owing to windows check Root CA expire date from your hosts?
svchost.exe is a container process for potentially multiple Windows services. You need to find out which services were being hosted within that process to find out what is actually talking to the Internet. It's likely a service that is connecting to something on the Internet that uses a Let's Encrypt cert.
Process Explorer is a useful way to get more detail on what service(s) is(are) running within that svchost process.