letsencrypt.sh stopped working #103

Closed
opened 2025-12-29 00:24:58 +01:00 by adam · 7 comments
Owner

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.

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.
adam closed this issue 2025-12-29 00:24:58 +01:00
Author
Owner

@embik commented on GitHub (May 21, 2016):

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

My nginx configuration looks like this:

server {
        listen 80 default;
        server_name pkg.embik.me;

        root /var/packages;
        location / {
                autoindex on;
        }

        location /.well-known/ {
                add_header Content-Type text/plain;
                alias /usr/local/www/.well-known/;
        }
}

Running letsencrypt.sh:

# su -m letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron'
# INFO: Using main config file /usr/local/etc/letsencrypt.sh/config.sh
Processing pkg.embik.me
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for pkg.embik.me...

User letsencrypt is indeed member of the corresponding group and should be able to access the directory:

# id letsencrypt
uid=1001(letsencrypt) gid=1001(letsencrypt) groups=1001(letsencrypt)

I'm eager to help debug this issue!

@embik commented on GitHub (May 21, 2016): 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 ``` My nginx configuration looks like this: ``` server { listen 80 default; server_name pkg.embik.me; root /var/packages; location / { autoindex on; } location /.well-known/ { add_header Content-Type text/plain; alias /usr/local/www/.well-known/; } } ``` Running `letsencrypt.sh`: ``` # su -m letsencrypt -c 'bash /usr/local/bin/letsencrypt.sh --cron' # INFO: Using main config file /usr/local/etc/letsencrypt.sh/config.sh Processing pkg.embik.me + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for pkg.embik.me... ``` User `letsencrypt` is indeed member of the corresponding group and should be able to access the directory: ``` # id letsencrypt uid=1001(letsencrypt) gid=1001(letsencrypt) groups=1001(letsencrypt) ``` I'm eager to help debug this issue!
Author
Owner

@lukas2511 commented on GitHub (May 21, 2016):

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.
Author
Owner

@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)

@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)
Author
Owner

@embik commented on GitHub (May 21, 2016):

The security/letsencrypt.sh port 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.
Author
Owner

@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).

@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).
Author
Owner

@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.

@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.
Author
Owner

@embik commented on GitHub (May 22, 2016):

Thank you very much!

@embik commented on GitHub (May 22, 2016): Thank you very much!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#103