How to find out when and how Let's Encrypt issuance was configured?

Ultimately, you can just set up a new client and ignore whatever previous system may have existed.

7 Likes

Another brilliant thought, but sadly that email eventually routes back to me and was just set up a couple of weeks ago.

Don't even get me started on what it took to get that DMARC record in place. I would rather clean all the bathrooms in Grand Central Station with my tongue than go through that hell again. :wink:

1 Like

Can I though?

What would be the repercussions of trying to jam two apparently valid SSL certificates onto the same server? I have never tried to do so therefore I have literally no clue what would break/blow up/cause the planet to stop revolving were I to do so.

Please, enlighten this weary, but still very appreciative, soul about what would happen.

2 Likes

This is just to alert @webprofusion the author of Certify The Web. He often helps out on this forum (and of course his own).

5 Likes

Here is the DNS SOA Record

$ nslookup -q=soa adaktu.net ns1.neonova.net.
Server:         ns1.neonova.net.
Address:        137.118.1.28#53

adaktu.net
        origin = ns1.neonova.net
        mail addr = hostmaster.neonova.net
        serial = 2023051000
        refresh = 10800
        retry = 3600
        expire = 604800
        minimum = 900

You could try emailing hostmaster@neonova.net and see if they can track where/who the DNS-01 challenge is coming from that is setting the _acme-challenge.adaktu.net DNS Record needed for the DNS-01 challenge.

2 Likes

This is the company I have already been in contact with that is denying everything related to Let's Encrypt and adaktu.net. Unless I am totally goofy here, that would seem to be the logical road to go down, save for the fact they are cannonballing in the deep end of the river Denial.

I mean, it's just a DNS record for crying out loud. Why is finding the author of the SSL Cert being treated like a national security secret?

2 Likes

Also it seems that the Hosting company is GENERAL COMMUNICATION
and the Netblock Owner is GENERAL COMMUNICATION, INC.

I got that from here Site report for https://adaktu.net | Netcraft

2 Likes

That is incorrect. We self-host the website. GCI is the leading ISP - and quasi-governmentally protected - in all of Alaska.

I mean this seriously - I am in awe of the sheer brainpower here. There were a few trees that I didn't see for the forest, and for that I am deeply appreciative. You guys absolutely rock.

3 Likes

I think you're misunderstanding: nobody here knows, or can know, how certs were issued for your domain. Cert issuance through Let's Encrypt is an automated process--there was never a time when somebody at your company made a phone call, or sent an email, or filled in a web form, and someone at Let's Encrypt responded to issue the cert. It was all done through software that's almost certainly somewhere on your network. We can ask questions to try to pin down what's going on, but ultimately we don't and can't know.

8 Likes

Adding to @danb35's thoughts

And specifically Domain Validation:

2 Likes

Perhaps I phrased that rather unartfully. I get that nobody here on these forums could possibly know. One should think the company that IS riding herd over one Let's Encrypt SSL certificate would know something, but they are adamant about not knowing squat about the top level SSL certificate. That's the part I have a really tough time comprehending. They are, logically, the only suspect that COULD know what is going on, yet they are denying everything like they are the sole surviving witness to where Jimmy Hoffa is buried.

The simple fact there is not one scrap of documentation on our end seems to point to the fact this was started with us. Once again, logic would seem to say the company that is riding herd on one cert surely would have SOMETHING to do with the other. I say in half-jest this cert didn't install itself. I have literally asked that other company if we didn't do it, and you didn't do it, then just tell me- who did?

Hence the national security vent.

2 Likes

Should be fine. Worst case is some automated tool you haven't found yet updates the cert more often than is necessary, but they're not likely to really fight: IIS has a given Server Certificate associated with a site, and it'll only ever point at one Server Certificate.

Now that I think about it, actually, worst case is that you never find that automated tool, and the mystery follows us all to the grave....

5 Likes

And haunts us for the remainder of all time. :laughing:

3 Likes

Side note: this is the certificate presently being served crt.sh | 9206709835 or the censys.io link https://search.censys.io/certificates/cb9afaf473766a8801857458d2a7003d43b23d158cd245108b967d9476c141bb

2 Likes

Does the userportal.adaktu.net domain name mean anything to you? You are getting certs for that name regularly too. Is it a clue?

I looked more carefully at your cert history for adaktu.net and www and see something unusual. Usually, ACME clients renew 60 days after issuance. They don't have to it is just common. But, yours has been renewing every 56 days with some stray variances. In fact, it even briefly expired Dec25 2022 for 2 days.

This probably won't help you but I'm hoping it might remind another volunteer of something. And, it might point to this not being an auto-renew ACME client but something done manually as @jsha suggested earlier.

4 Likes

Like with this (let me tell you it is a bit of a pain remembering to renew not to often nor too late).
https://gethttpsforfree.com/

1 Like

I believe that was/is the defunct email portal I mentioned earlier.

Now what I would like to know is how/where you pulled up that cert history. I would love to learn about that.

I think you are on to something here. Correct me if I veer off into crazytown here, but that looks an awful lot to me like an automated system that someone forgets to restart/check on every once in a while. That rules out our server because the last restart was on 24 FEB this year, and before that was almost 6 months earlier, which scotches the December blip. Logically speaking it can't be our server.

That means it HAS to be someone or something external to our company!

Thank you very, very much for that. It gave us a great deal of information we didn't have before.

3 Likes

As @jsha mentioned here

censys.io is one online tool.

And as @mcpherrinm
here is another online tool https://crt.sh/ and here is a list of issued certificates crt.sh | adaktu.net

3 Likes

I don't draw the same conclusion. The 1-day variances might just be timing of an auto renewal request. I calculated based on just the date and did not study the full timestamps. But, the 56 day repeat is odd. And, whatever was happening didn't happen per usual around Nov21 2022 which was 56 days since prior issuance. Someone didn't correct this until Dec27 after it expired on Dec25

Rebooting a server might not have any impact.

Probably best to wait for the Windows wizards to chime in. @rmbolger would be another one of these. They might know some tricks.

6 Likes

There remains a lot of things not in either of those two locations.
[within both: NOT your server and NOT outside your company]
Unless...
The entire company is that one single server! LOL

If your server behind a firewall, perhaps there are some logs [or rules] that would show some access that could have made the file updates.

5 Likes