I had the exact same thing happen as this user within a second or so of starting my services. I'm using nginx-letsencrypt-companion docker setup. @zeroware, have you gotten this since? I noticed the thread is closed, but I think if we'd allow a thread to stay open we can gain clues and examine a potential attack happening against us.
2019/09/04 21:11:09 [warn] 18#18: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: "/etc/nginx/certs/staging1.our.tld.crt"
When you request a certificate, it will be public, so anybody could decide to check if your website has flaws. Be sure to have a secure website before allowing outside access.
It's not related to let's encrypt: all certificate authorities must publicly log certificates. What you can do to reduce the risk is use a wildcard certificate: "*.example.com" so without more information, the subdomain can't be easily known.
Well that’s concerning… Is there a testing mode where we don’t publish our URLs?
Why must LetsEncrypt publish the URLs to a central repo of “hey everyone these are freshly (and I mean freshly) launched sites!”
The idea is, if a rogue (valid) certificate is create, how to detect it? The solution adopted is, the certificate must contains at least 2 proof of publication to be valid. So as a website owner, you can know the list of certificates created for your website.
No, even the let's encrypt staging (which allow to create test certificates), will publish them (in a test transparency list).