Originally created by @martin21 on GitHub (Jan 10, 2017).
dehydrated 0.3.1-1 from Debian Sid on Debian Jessie.
dehydrated forgets to add slash between hostname and ".well-known" in fifth domain name in first line of domains.txt, which contains a "-" sign. It gets it correct for port 80, but not for port 443.I am not sure what of this triggers the issue. certbot can get certs for all domains without issues.
TLD replaced.
Will use certbot now, maybe string handling in Bash just isn´t such a good idea.
~> cat /etc/dehydrated/domains.txt
example.de www.example.de mail.example.de martin.example.de martin-alt.example.de [… some more domains …]
example2.de www.example2.de
example3.de www.example3.de
Originally created by @martin21 on GitHub (Jan 10, 2017).
dehydrated 0.3.1-1 from Debian Sid on Debian Jessie.
dehydrated forgets to add slash between hostname and ".well-known" in fifth domain name in first line of domains.txt, which contains a "-" sign. It gets it correct for port 80, but not for port 443.I am not sure what of this triggers the issue. certbot can get certs for all domains without issues.
TLD replaced.
Will use certbot now, maybe string handling in Bash just isn´t such a good idea.
```
~> cat /etc/dehydrated/domains.txt
example.de www.example.de mail.example.de martin.example.de martin-alt.example.de [… some more domains …]
example2.de www.example2.de
example3.de www.example3.de
```
Error output:
```
+ Responding to challenge for martin-alt.example.de...
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "Could not connect to martin-alt.example.de.well-known",
"status": 400
},
"uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/N2ZBMW-W9zY33JarjmY4bETgmacQEt-NeY9KQBb-mNU/490467475",
"token": "dgGNQ2VAKOcqwytPbAcC6BKCa-p43X_3fUXr5koPwM0",
"keyAuthorization": "dgGNQ2VAKOcqwytPbAcC6BKCa-p43X_3fUXr5koPwM0.kDORmaAUEf43wIyVtGEZv1smbfcz0px6LiYs5UGymXk",
"validationRecord": [
{
"url": "http://martin-alt.example.de/.well-known/acme-challenge/dgGNQ2VAKOcqwytPbAcC6BKCa-p43X_3fUXr5koPwM0",
"hostname": "martin-alt.example.de",
"port": "80",
"addressesResolved": [
"[… IPv6 address …]",
"[… IPV4 address …]"
],
"addressUsed": "[… IPv4 address …]"
},
{
"url": "https://martin-alt.example.de.well-known/acme-challenge/dgGNQ2VAKOcqwytPbAcC6BKCa-p43X_3fUXr5koPwM0",
"hostname": "martin-alt.example.de.well-known",
"port": "443",
"addressesResolved": null,
"addressUsed": ""
}
]
})
```
Thanks Lukas, that worked. It was a combination of missing slash in RedirectPermanent, as well as for one domain another wrong rewrite rule that was hidden well by HSTP. I wonder why certbot didn´t fail on this one tough. Maybe it used the HSTP redirect.
@martin21 commented on GitHub (Jan 30, 2017):
Thanks Lukas, that worked. It was a combination of missing slash in RedirectPermanent, as well as for one domain another wrong rewrite rule that was hidden well by HSTP. I wonder why certbot didn´t fail on this one tough. Maybe it used the HSTP redirect.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @martin21 on GitHub (Jan 10, 2017).
dehydrated 0.3.1-1 from Debian Sid on Debian Jessie.
dehydrated forgets to add slash between hostname and ".well-known" in fifth domain name in first line of domains.txt, which contains a "-" sign. It gets it correct for port 80, but not for port 443.I am not sure what of this triggers the issue. certbot can get certs for all domains without issues.
TLD replaced.
Will use certbot now, maybe string handling in Bash just isn´t such a good idea.
Error output:
@lukas2511 commented on GitHub (Jan 29, 2017):
Duplicate of #305, please see my comments in that thread.
@martin21 commented on GitHub (Jan 30, 2017):
Thanks Lukas, that worked. It was a combination of missing slash in RedirectPermanent, as well as for one domain another wrong rewrite rule that was hidden well by HSTP. I wonder why certbot didn´t fail on this one tough. Maybe it used the HSTP redirect.