The next line in letsencrypt.sh seems to fail (although if I manually do the command on the cli on above content, it greps the content fine and would put it in $challenges.). Nothing else behinde line 386 is running and letsencrypt.sh simply exits.
Any ideas what this could be?
It happens on several machines, where I have letsencrypt.sh running fine for the last couple weeks.
Originally created by @fbatschi on GitHub (May 21, 2016).
I am running the latest git version of letsencrypt.sh
Script ran fine the last several weeks.
Today, when requesting a new cert, it simply stops at the point
``` ...
Processing foo.com
+ Signing domains...
+ Creating new directory /etc/ssl/certs/foo.com ...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for foo.com ...
```
Looking into the script, it runs fine until line 384
```
response="$(signed_request "${CA_NEW_AUTHZ}" '{"resource": "new-authz", "identifier": {"type": "dns", "value": "'"${altname}"'"
```
$response is filled with a json response like this from letsencrypt, so connection to Let's Encrypt API works.
```
{ "identifier": { "type": "dns", "value": "bar.foo.com }, "status": "pending", "expires": "2016-05-28T16:42:04.050529229Z", "challenges": [ { "type": "dns-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/AoeDKdkeJF-PgaffffffffhJxsSTD4SBjARBOJHT0kd0ulWqq4/12345678", "token": "bpcTwqRrZvhoHwEG49k1RODWbgaL8cTit_Iv5Nn5gwM" }, { "type": "http-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/AoeEgVJF-PgaffffffffhJxsSTD4SBjARBOJHT0kd0ulWqq4/12345678", "token": "DwbZqn27oLukrVavxWtTpyNJXbN1FYBfLgc8Zyro6_s" }, { "type": "tls-sni-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/AoeEgVJF-PgaffffffffhJxsSTD4SBjARBOJHT0kd0ulWqq4/12345678", "token": "pGQFERvi3yW0fp3IXWuEpPV2F3W4JW4XiIwEnT46OeE" } ], "combinations": [ [ 0 ], [ 2 ], [ 1 ] ] }
```
The next line in letsencrypt.sh seems to fail (although if I manually do the command on the cli on above content, it greps the content fine and would put it in $challenges.). Nothing else behinde line 386 is running and letsencrypt.sh simply exits.
Any ideas what this could be?
It happens on several machines, where I have letsencrypt.sh running fine for the last couple weeks.
It's silently failing exactly that way for me too. I'm running letsencrypt.sh in a FreeBSD 10.3-RELEASE jail and cannot figure out what's wrong. These are the relevant parts of my config.sh:
CHALLENGETYPE="http-01"
BASEDIR="/usr/local/etc/letsencrypt.sh"
WELLKNOWN="/usr/local/www/.well-known/acme-challenge"
alias openssl='/usr/local/bin/openssl'
Directory permissions:
# ls -lisa /usr/local/www/.well-known/acme-challenge/
total 8
4099163 4 drwxrwxr-x 2 root letsencrypt 512 May 21 18:53 .
4098077 4 drwxr-xr-x 3 root wheel 512 May 21 18:27 ..
# ls -lisa /usr/local/etc/letsencrypt.sh
total 44
4103539 4 drwxrwx--- 4 root letsencrypt 512 May 21 18:57 .
4099103 4 drwxr-xr-x 10 root wheel 512 May 21 18:24 ..
4103548 4 drwxr-xr-x 2 root wheel 512 May 21 18:12 .acme-challenges
4103556 4 drwx------ 3 letsencrypt letsencrypt 512 May 21 18:45 certs
4099192 4 -rw-r--r-- 1 root letsencrypt 3263 May 21 18:34 config.sh
4103540 4 -rw-r--r-- 1 root wheel 3191 May 21 18:12 config.sh.example
4099207 4 -rw-r--r-- 1 root letsencrypt 13 May 21 18:36 domains.txt
4103542 4 -rw-r--r-- 1 root wheel 73 May 21 18:12 domains.txt.example
4103541 4 -rw-r--r-- 1 root wheel 2709 May 21 18:12 hook.sh.example
4103554 4 -rw------- 1 letsencrypt letsencrypt 928 May 21 18:35 private_key.json
4103552 4 -rw------- 1 letsencrypt letsencrypt 3243 May 21 18:35 private_key.pem
Are you both running the latest version (master branch) of letsencrypt.sh? In 561f0626b8 i made changes for letsencrypt.sh to be compatible with the newer json format.
@lukas2511 commented on GitHub (May 21, 2016):
Are you both running the latest version (master branch) of letsencrypt.sh? In 561f0626b855ec4ee94856884e2f1eff9ade2d88 i made changes for letsencrypt.sh to be compatible with the newer json format.
did u update it recently? that looks like the json+sed problem from the other ticket
(and yes, the FreeBSD-10.3-RELEASE pkg version does not have this update)
@ma0am commented on GitHub (May 21, 2016):
did u update it recently? that looks like the json+sed problem from the other ticket
(and yes, the FreeBSD-10.3-RELEASE pkg version does not have this update)
The security/letsencrypt.shport does not contain that commit indeed (as it has been last updated with v0.1.0). I cannot speak for OP of course. Will there be a minor release in the near future to push out these changes to packaging systems not following master?
Thank you very much for creating letsencrypt.sh by the way. Cannot be stressed enough.
@embik commented on GitHub (May 21, 2016):
The `security/letsencrypt.sh` [port](https://www.freshports.org/security/letsencrypt.sh/) does not contain that commit indeed (as it has been last updated with v0.1.0). I cannot speak for OP of course. Will there be a minor release in the near future to push out these changes to packaging systems not following `master`?
Thank you very much for creating letsencrypt.sh by the way. Cannot be stressed enough.
@lukas2511 you are right - I am sorry. I actually used a fork of letsencrypt which does not have the commit you mentioned. After merging upstream it works (again).
@fbatschi commented on GitHub (May 21, 2016):
@lukas2511 you are right - I am sorry. I actually used a fork of letsencrypt which does not have the commit you mentioned. After merging upstream it works (again).
I just released version 0.2.0 that contains this patch among a few other changes (see changelog). Hoping this will make its way into all those ports/packages soon.
@lukas2511 commented on GitHub (May 22, 2016):
I just released version 0.2.0 that contains this patch among a few other changes (see changelog). Hoping this will make its way into all those ports/packages soon.
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 @fbatschi on GitHub (May 21, 2016).
I am running the latest git version of letsencrypt.sh
Script ran fine the last several weeks.
Today, when requesting a new cert, it simply stops at the point
Looking into the script, it runs fine until line 384
$response is filled with a json response like this from letsencrypt, so connection to Let's Encrypt API works.
The next line in letsencrypt.sh seems to fail (although if I manually do the command on the cli on above content, it greps the content fine and would put it in $challenges.). Nothing else behinde line 386 is running and letsencrypt.sh simply exits.
Any ideas what this could be?
It happens on several machines, where I have letsencrypt.sh running fine for the last couple weeks.
@embik commented on GitHub (May 21, 2016):
It's silently failing exactly that way for me too. I'm running
letsencrypt.shin a FreeBSD 10.3-RELEASE jail and cannot figure out what's wrong. These are the relevant parts of myconfig.sh:Directory permissions:
My nginx configuration looks like this:
Running
letsencrypt.sh:User
letsencryptis indeed member of the corresponding group and should be able to access the directory:I'm eager to help debug this issue!
@lukas2511 commented on GitHub (May 21, 2016):
Are you both running the latest version (master branch) of letsencrypt.sh? In
561f0626b8i made changes for letsencrypt.sh to be compatible with the newer json format.@ma0am commented on GitHub (May 21, 2016):
did u update it recently? that looks like the json+sed problem from the other ticket
(and yes, the FreeBSD-10.3-RELEASE pkg version does not have this update)
@embik commented on GitHub (May 21, 2016):
The
security/letsencrypt.shport does not contain that commit indeed (as it has been last updated with v0.1.0). I cannot speak for OP of course. Will there be a minor release in the near future to push out these changes to packaging systems not followingmaster?Thank you very much for creating letsencrypt.sh by the way. Cannot be stressed enough.
@fbatschi commented on GitHub (May 21, 2016):
@lukas2511 you are right - I am sorry. I actually used a fork of letsencrypt which does not have the commit you mentioned. After merging upstream it works (again).
@lukas2511 commented on GitHub (May 22, 2016):
I just released version 0.2.0 that contains this patch among a few other changes (see changelog). Hoping this will make its way into all those ports/packages soon.
@embik commented on GitHub (May 22, 2016):
Thank you very much!