My hosting provider, if applicable, is: Cloudflare Proxy + Origin Server
I have this domain proxied via Cloudflare. I’m using Page Rules (https://1drv.ms/u/s!ArgTGsCWDVSnk25srVg9eTckQCnn) that I’m fairly sure will allow Let’s Encrypt challenges to bypass the proxy allowing the origin server to request certificates.
As you can see in the CT logs, there are a lot of requests for certificates recently. With Cloudflare, if you add a basic CAA record to DNS (ex: 0 iodef "mailto:caa@example.com") they’ll automatically add Let’s Encrypt for issue and issuewild, so it’s possible either Cloudflare or the origin server is making those certificate requests.
I emailed the provider for the origin server to ask if they’re making the requests. In the meantime, is there any way for me to discover which provider is requesting certificates for my domain?
5 identical certificates in the last 7 days, that has hitted the limit. Same one week earlier.
Looks like you have a wrong configured cron job. Share your cronjob command.
And your configuration doesn't work. Cloudflare sends an 526 "Origin SSL Certificate Error". Deactivate Cloudflare, create a working vHost, then activate Cloudflare.
Hey. Thanks for the response. I should have been clear, I don’t have any access to the origin server. It’s a link shortening service. Since it’s only a test domain for me, I purposely left things broken while I wait for the provider of the shortening service to reply.
I was hoping that since I control the domain there would be some way for me to query some more verbose logging info such as the IP address of the certificate requester. I can’t find anything like that in the docs, so I’m guessing there isn’t much chance of getting that info.
It feels like an issue on the origin server, so I might just have to wait for them to get back to me.
However, the entries for npi.pe listed on crt.sh are not certificate requests, they are actually issued certificates. So that means whichever machine issued those certificates must have been able to successfully answer challenges. Almost certainly that means it's one of the two IP addresses that npi.pe points to, using an HTTP-01 challenge. Do you have access to those IP addresses? If so you can check their cron jobs and systemd timers.
There's a small chance that there is a machine with DNS credentials to update the npi.pe zone, and that machine is automatically issuing certificates over and over again. To rule out that possibility you'd need to get full control over the npi.pe zone and make sure no one else has credentials to update it.
@jsha Thanks for the info. I’m the only one with access to update the zone. I’m fairly convinced it’ll end up being the link shortening provider that acts as the origin server. The config I’m using isn’t documented / supported by them, but should work. My best guess right now is that their automation process for requesting / installing certificates is probably getting tripped up by having Cloudflare acting as a proxy. I see they’ve started using a LE certificate from June 30th now, so there’s a good chance someone fixed it on their end and that I’ll get an email about it soon.
It might be a moot issue anyway. In the 3 months I left my test domain sit there, they’ve drastically improved their SSL configs which was the main reason I was using Cloudflare as a proxy (to avoid an F at https://www.ssllabs.com/ssltest/).
If the domain is on your Cloudflare account, you can check Cloudflare’s Audit Logs to see if anything has been adding and removing DNS records.
If you make a lot of changes, it might be a little hard to find – a Let’s Encrypt ACME authorization is currently valid for 30 days, so you can issue excessive certificates while only modifying the DNS about once a month.