I notice that the hostname is prepended with ".well-known" Could that be the issue ?
Regards and thanks for a nice script
Supergoof
Originally created by @Supergoof on GitHub (Nov 15, 2016).
I have followed the nice example at https://www.aaflalo.me/2016/09/dehydrated-bash-client-lets-encrypt/ and have things setup on an Ubuntu 14.04
But I seem to have a missing slash "/" somewhere and I cant find it.
My output is:
```
Processing sub.mydomain.dk
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for sub.mydomain.dk...
+ Responding to challenge for sub.mydomain.dk...
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "Could not connect to sub.mydomain.dk.well-known",
"status": 400
},
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/6LxKELET2eL6diD-ovIPrKE9LHKQNGU2SmZh3MLsDc4/16900890",
"token": "KP8Um5SjkvoYi41fE2Hmsg7Gn4BClvPx3CjpNcqzTCo",
"keyAuthorization": "KP8Um5SjkvoYi41fE2Hmsg7Gn4BClvPx3CjpNcqzTCo.RzSA_osSH4_aPw-z2ZyR0ob05YOIOwsnySON7jA3zzE",
"validationRecord": [
{
"url": "http://sub.mydomain.dk/.well-known/acme-challenge/KP8Um5SjkvoYi41fE2Hmsg7Gn4BClvPx3CjpNcqzTCo",
"hostname": "sub.mydomain.dk",
"port": "80",
"addressesResolved": [
"194.88.216.41"
],
"addressUsed": "194.88.216.41"
},
{
"url": "https://sub.mydomain.dk.well-known/acme-challenge/KP8Um5SjkvoYi41fE2Hmsg7Gn4BClvPx3CjpNcqzTCo",
"hostname": "sub.mydomain.dk.well-known",
"port": "443",
"addressesResolved": null,
"addressUsed": ""
}
]
})
```
I notice that the hostname is prepended with ".well-known" Could that be the issue ?
Regards and thanks for a nice script
Supergoof
This looks like you are doing a redirect on your webserver, and it is missing the '/' on the redirected path, nothing to do with this script or Let's Encrypt.
@lukas2511 commented on GitHub (Dec 18, 2016):
This looks like you are doing a redirect on your webserver, and it is missing the '/' on the redirected path, nothing to do with this script or Let's Encrypt.
I don't think it's that because I have the same problem and if I access the url in the browser with 'http' instead of 'https' it redirects correctly. And the alias is created like in your doc file.
@cdarken commented on GitHub (Jan 26, 2017):
I don't think it's that because I have the same problem and if I access the url in the browser with 'http' instead of 'https' it redirects correctly. And the alias is created like in your doc file.
@cdarken you can clearly see that it first tries the http:// url with correct path and only tries the broken path afterwards, and that only happens if your server is sending a redirect. none of my example configs do redirects, so this has to be something else in your configuration.
since i did this mistake myself a few times i know how easy it is to make, check using curl or something else, your browser might not be a good debugging tool if you have/had hsts enabled, it will do its own redirect and not ask the server on what to do.
Just an example with apache:
# this will result in broken urls
Redirect permanent / https://example.org
# this will work
Redirect permanent / https://example.org/
@lukas2511 commented on GitHub (Jan 29, 2017):
@cdarken you can clearly see that it first tries the http:// url with correct path and only tries the broken path afterwards, and that only happens if your server is sending a redirect. none of my example configs do redirects, so this has to be something else in your configuration.
since i did this mistake myself a few times i know how easy it is to make, check using curl or something else, your browser might not be a good debugging tool if you have/had hsts enabled, it will do its own redirect and not ask the server on what to do.
Just an example with apache:
```
# this will result in broken urls
Redirect permanent / https://example.org
# this will work
Redirect permanent / https://example.org/
```
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 @Supergoof on GitHub (Nov 15, 2016).
I have followed the nice example at https://www.aaflalo.me/2016/09/dehydrated-bash-client-lets-encrypt/ and have things setup on an Ubuntu 14.04
But I seem to have a missing slash "/" somewhere and I cant find it.
My output is:
I notice that the hostname is prepended with ".well-known" Could that be the issue ?
Regards and thanks for a nice script
Supergoof
@lukas2511 commented on GitHub (Dec 18, 2016):
This looks like you are doing a redirect on your webserver, and it is missing the '/' on the redirected path, nothing to do with this script or Let's Encrypt.
@cdarken commented on GitHub (Jan 26, 2017):
I don't think it's that because I have the same problem and if I access the url in the browser with 'http' instead of 'https' it redirects correctly. And the alias is created like in your doc file.
@lukas2511 commented on GitHub (Jan 29, 2017):
@cdarken you can clearly see that it first tries the http:// url with correct path and only tries the broken path afterwards, and that only happens if your server is sending a redirect. none of my example configs do redirects, so this has to be something else in your configuration.
since i did this mistake myself a few times i know how easy it is to make, check using curl or something else, your browser might not be a good debugging tool if you have/had hsts enabled, it will do its own redirect and not ask the server on what to do.
Just an example with apache: