mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-08-28 14:37:22 +02:00
Issue with failing to acquire root domain certs #256
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/dehydrated#256
Reference in New Issue
Block a user
Originally created by @Timetreck on GitHub (Oct 17, 2017).
Errors on just the root domain, on www. it validates and issues a cert fine.
Also worth noting -- last week this worked fine on a bunch of other domains. But twice today this has come up, on two entirely different domains.
I've considered this could be a CAA record problem, but I'm fairly sure it's not after digging into both domains.
INFO: Using main config file /etc/dehydrated/config Processing domain.com with alternative names: www.domain.com + Signing domains...
Details:
{
"type": "urn:acme:error:unauthorized",
"detail": "Error creating new cert :: authorizations for these names not found or expired: domain.com",
"status": 403
}
@txr13 commented on GitHub (Oct 17, 2017):
See #431.
The tell-tale part, to me, is that we get the expected response for www.domain.com, but there's no "Challenge is valid!" for domain.com. So that challenge isn't being validated, and that's most likely an issue with your webserver config.
(You should probably also upgrade your copy of
dehydratedto see if the bugfix from #431 gives us any additional info.)@Timetreck commented on GitHub (Oct 18, 2017):
Updated dehydrated to the latest and this is the error I get now:
It may be a webserver config problem, but I just wanted to make sure it's not something else.
95% of every other domain works fine, and I've checked this for pointing issues, CAA records and AAAA records and everything checks out. I'm at a loss for why this would fail to validate.
INFO: Using main config file /etc/dehydrated/config Processing domain.com with alternative names: www.domain.com + Signing domains...
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "Fetching http://domain.com/.well-known/acme-challenge/dnxByHUZsidE4fyG7N0HeWu7tyjyIf1MY8lVsBkgzlI: Timeout",
"status": 400
},
"uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/FxQzsh54BvUA9YTS1TjV3ItOSf4jo54txw4-Xvuqkis/2231839467",
"token": "dnxByHUZsidE4fyG7N0HeWu7tyjyIf1MY8lVsBkgzlI",
"keyAuthorization": "dnxByHUZsidE4fyG7N0HeWu7tyjyIf1MY8lVsBkgzlI.3uMsTTCiuRJRG1ajofVu8FCAbuYKHHUPYbGkoeN4ElU",
"validationRecord": [
{
"url": "http://domain.com/.well-known/acme-challenge/dnxByHUZsidE4fyG7N0HeWu7tyjyIf1MY8lVsBkgzlI",
"hostname": "domain.com",
"port": "80",
"addressesResolved": [
"1.2.3.4",
"5.6.7.8"
],
"addressUsed": "1.2.3.4",
"addressesTried": []
}
]
})
@txr13 commented on GitHub (Oct 19, 2017):
The error says that LE timed out while trying to access the validation path. (http://domain.com/.well-known/acme-challenge/dnxByHUZsidE4fyG7N0HeWu7tyjyIf1MY8lVsBkgzlI)
I would suggest placing a dummy file in the acme-challenge directory and seeing what happens when you try to access it with that domain name, see if that sheds any more light on the issue.
@Timetreck commented on GitHub (Oct 20, 2017):
Figured it out, was a strange webserver issue. Thanks!