Yet another "Timeout" while verifying via HTTP

I don't think anybody really has more debugging information they could give you. All Let's Encrypt's servers know is that they sent packets addressed to your server and didn't get a response. If the primary datacenter can connect but the secondary locations can't, the error message specifically calls out that "secondary validation" failed.

It gets tricky to publish which IPs can and can't connect to your systems, as that information would also be valuable to somebody trying to trick what routes Let's Encrypt's networks should use and such. They need to try to ensure that the requester of the certificate owns the certificate as seen from everywhere on the Internet.

1 Like

Nah, I understand about the IPs - security is important.

More info like, "primary server 1 - failed (timeout)" or "secondary server 3 - HTTP Fail (404)". In cases like this, it would have helped me determine that SOME servers were hitting it, some weren't. Granted, I wound't have been able to do anything about it still, but it would have helped me pinpoint the issue. (As well as posting here then with a message saying, 'hey, 1 of the 4 servers can't connect; what does that mean'? instead of saying that the 'firewall issue' is just flat-out wrong. :smiley:

Interestingly, I just performed an expirement:
I went to create a new certificate. This time, I added in mail.tsqmadness.com. (Port 80 points to the same exact server/instance/AppPool that tsqmadness.com does.) The first time, it failed with the same error. I waited about thirty minutes and tried again. Same error. Waited another hour, and it then passed.

Wondering if it's a delayed DNS lookup or something in one of LE's primary server/services.Give it enough time, and it works fine.

I do wonder if there's some kind of weird routing issue between Let's Encrypt's main datacenter(s) and yours, where just sometimes it works and sometimes it doesn't (maybe based on which server or router or something got your request).

I think it's really rare for the main request to fail while the secondary succeed; for many people it's the other way around (because they block traffic from AWS or the like, where the secondary datacenters are hosted). I could see giving a message that the secondary succeeded while the primary failed might be helpful. The software that Let's Encrypt uses to issue certificates is open-source and available at https://github.com/letsencrypt/boulder; you could raise an issue for it there if you wanted, or maybe post a thread here in the Feature Requests section about that. I'm not sure if there's some security or operational reason they'd want to not say anything more if the primary validation is what's failing, though.

3 Likes

Maybe an attempt to MitM :scream:

1 Like

Thanks for that link - wasn't aware it was open-source.

I wouldn't mind working with them to figure out what's going on - as a developer myself, I made sure to try to check everything I could before posting here originally. :slight_smile:

I'll edit to say this: In the past, I've used the DNS method of verification, and no issues obviously. I, unfortunately, am stuck with my current DNS/Registrar for the next 3 years, and they have no API for creating TXT records. I really do want to have to manually update my DNS records every 3 months for the next 3 years, until I can move to a registrar that has an API (and is effin' cheaper). :smiley:

Why not keep your registrar and just move your DNS to another provider? It's a common mistake to assume they have to be the same.

1 Like