I ran this command: N/A
It produced this output: N/A
My web server is (include version): Microsoft-IIS/10.0
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is: Self-hosted
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A
The problem is that I have recently been hired into a company as the IT department. One of the duties is riding herd over the self-hosted website. I recently received notice the SSL Certificate is coming up for renewal in a couple of months, and it was issued by Let's Encrypt. Everyone remotely involved with managing our DNS record swears they had nothing to do with obtaining the certificate. Also, there isn't a scrap of documentation here or in emails going back nearly five years that show anyone at this company did anything with Let's Encrypt. Logically, the certificate didn't create and install itself. Yet, here we are.
How do I find out who/what/where/when the Let's Encrypt SSL certificate for our company/website was issued?
Thanks for any and all help pointing me in the right direction.
So your current website has a cert. It was issued April 20, and expires on July 19.
It looks like you have a single server (running IIS as you mentioned), so I'd start by examining that server to see if there's an ACME (Let's Encrypt protocol) client installed. It's most likely that is where your cert is issuing from.
Using crt.sh to search for certificates:
It looks like you've got a couple different certs under that domain, so it's possible different systems are issuing those different certificates as well.
Just looked on the server and cross-referenced all the installed programs vs. the "master" ACME client list on the web from Let's Encrypt and came up with nothing. Searches come up empty, and even going to Add/Remove and physically double-checking comes up empty. If it is there, it's very well hidden.
It just boggles my mind something so trivial would be so well hidden, with zero documentation and no email trial to back it up.
Once an ACME client is setup for a particular cert it generally auto-renews every 60 days since the life of an LE cert is 90 days.
Your cert for adaktu.net and its www subdomain looks to be renewing regularly. You might try looking on the System Task Scheduler for a job that may do this.
Windows IIS server usually uses one of the Windows based ACME clients. Certify The Web may be the most popular of those. Certbot requires extra manual steps to integrate with IIS so we don't see that on Windows as much unless server is Apache or nginx or similar. Certbot is the most common on linux.
It's possible a custom client was developed but that seems less likely here.
I assume you've looked through the list below. After Certify The Web we see posh-acme and win-acme the next most frequent.
No go on the System Task Scheduler. The only things in there all track back to bone stock server stuff.
I can't even find a rogue .sh file on the server. As I stated before, if it is there someone went to a LOT of trouble to hide it. There is very little that isn't bone stock installed on that server. Even manually looking in Program Files one can find but maybe six programs that are not part of the stock install.
I am very grateful for the help, but I don't think we are going to find anything automatic on that server.
I have even rummaged around in the Manage Computer Certificates and nothing listed there has an expiry date that lines up. Mostly way before (aka already expired) or far-flung into the future. Someone had to start the ball rolling, but whoever it was covered their tracks very, very well.
Let's Encrypt is an API, automated by a client. We definitely have records of past issuance flow, but that wouldn't tell us what person did it or what computer they used. You already know what email they've provided (as we sent an email to you with the expiry notice).
I did not get the notice by e-mail, and the person that one would logically believe to have been the one to receive it was with the company eleven years. I have the entire archive of emails going back to day one. Not one mention of Let's Encrypt. Not one mail, not one word, not one byte.
So either they were erased, which given the triviality of this is bizarre in the extreme, or someone outside of our company set it up. The weight of evidence so far leans to that side of the ledger. That's the entire impetus for the search.
Actually, it was during a security audit brought about by the installation of a new Wordpress plugin that I even had it brought to my attention. Wanting to get ahead of the renewal lest there be something catastrophic happen, I tugged the thread and was immediately yanked down this very bizarre rabbit hole, so to speak.
One thing worth noticing. According to censys.io (a search engine over CT logs, like crt.sh; requires login), there are wildcard certificates for *.adaktu.net: censys search for *.adaktu.net.
The only way to get a wildcard certificate is to solve a DNS challenge, which requires access (usually API access) to modify your DNS zone. The ACME client solving a DNS challenge does not have to run on the machine that will eventually serve the certificate. In fact, it's often good to have a non-Internet-facing server that manages the ACME account and solves DNS challenges, and which then pushes the resulting certificates to your Internet-facing server.
So the next avenue I would recommend exploring is to log in to your DNS provider, and find out what API tokens are extant, if any. Then you could try to find out who created those tokens. Another avenue would be to find out what systems under your control have permission to push files / certificates to your Internet-facing server.
And it's entirely possible someone was previously issuing certificates using an ACME client on their laptop, manually solving challenges using your DNS provider, and then manually installing them on the Internet-facing server.
A brilliant thought, but as I mentioned earlier everyone involved in the management of our DNS record has denied everything. The one exception is they are still managing the Let's Encrypt record for a now defunct e-mail service that is no longer used. Bizarrely, they totally copped to that one. They are flatly stating they have nothing to do with the top level adaktu.net or anything else.
Yes, it's quite the mess I have inherited, but I have to tame this gordian knot... eventually.