kristapsdz / acme-client-portable Goto Github PK

Hello,

On Ubuntu, it would be nice to install acme-client with apt:

sudo apt install acme-client-portable

I have some knowledge about building PPAs and I would be glad if you allow me to that. :-)

Oops, I didn't read the README.md closely enough, sorry, and I'm closing the issue! However, I still think an INSTALL file with the configuration info from the README.md would be useful.

I wasn't informed about the following config issues until running acme-client with real inputs:

1. non-existent directory "/var/empty"

2. the DEFAULT_CA wasn't correct, and I'm still investigating how to change it

I think an INSTALL file with such details would be helpful.

Thanks for an excellent and much needed project!

BTW, libseccomp failed the live tests on my host.

Trying to get cert on ipv6-connected machine:

Started Check and renew ACME TLS certificates.
acme-client: /var/lib/acme/certs/DOMAIN/privkey.pem: domain key exists (not creating)
acme-client: /var/lib/acme/accounts/letsencrypt.pem: account key exists (not creating)
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:2d:480::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:2d:487::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.206.21.80
acme-client: 2a02:26f0:2d:480::3d5: tls_connect_socket: acme-v01.api.letsencrypt.org, ssl verify setup failure
acme-client: https://acme-v01.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(1745): 1
[email protected]: Main process exited, code=exited, status=1/FAILURE

Although ipv6 works like a charm:

$ curl -v https://acme-v01.api.letsencrypt.org/
*   Trying 2a02:26f0:2d:480::3d5...
* Connected to acme-v01.api.letsencrypt.org (2a02:26f0:2d:480::3d5) port 443 (#0)
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
...
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: acme-v01.api.letsencrypt.org
...
> 
< HTTP/1.1 200 OK
...

Thanks for your work on this. It looks very promising.

I'm running -portable on Linux. I've gotten it built and am able to run a command to register and request some certs from the staging service. However, during this run I get the following:

./acme-client -s -vvNnm -C /acme/challenges -c /acme/public -k /acme/private/domain.pem -f /acme/account/account.pem example.com
acme-client: /acme/account/account.pem: generated RSA account key
acme-client: /acme/private/domain.pem: generated RSA domain key
acme-client: https://acme-staging.api.letsencrypt.org/directory: directories
acme-client: acme-staging.api.letsencrypt.org: DNS: 104.96.225.80
acme-client: acme-staging.api.letsencrypt.org: DNS: 2001:418:1416:284::3d5
acme-client: acme-staging.api.letsencrypt.org: DNS: 2001:418:1416:29d::3d5
acme-client: transfer buffer: [{ "key-change": "https://acme-staging.api.letsencrypt.org/acme/key-change", "new-authz": "https://acme-staging.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-staging.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-staging.api.letsencrypt.org/acme/new-reg", "revoke-cert": "https://acme-staging.api.letsencrypt.org/acme/revoke-cert" }] (372 bytes)
acme-client: https://acme-staging.api.letsencrypt.org/acme/new-authz: req-auth: [mydomain]
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "No registration exists matching provided key", "status": 403 }] (120 bytes)
acme-client: bad exit: netproc(15477): 1

It appears that the client is trying to authorize to request certificates before it's registered.

I've only begun digging into what's happening, but in the course of diagnosing, I encountered a Heisenbug: some of my debug printfs caused the whole routine to work. Reducing this, if I put a usleep(500) at the top of xrun(), I get a successful run every time. If I remove the usleep(), it fails every time. (I am clearing and replacing the whole of /acme with each run.)

This begins to smell of a race condition, so I thought I'd go ahead and report it even though I don't have a solution yet.

Specifically, add options to read all cert data and do one of two things:

1. renew expiring certs (able to be used as a single cron job)

2. report the current status of all certs (allow to be executed by a non-root user)

The desired capability assumes the -m option is the default (see issue #33) so all cert data are filed under appropriate DOMAIN.TLD directories.

Hello,

What do you think about to build and install acme-client as below?:

./configure
make
sudo make install

If you like this we could create the autotools files. :-)

Given the security focus, signed snapshots seems like it would make sense? The hashes on the website only provide a modicum of security, without a root trust anchor.

Hello, here is my working patch for adding CF dns api support, it is used on our servers for about year without any issues, but still incomplete in terms of correct way implementation (sockets/independent processes/etc), because i don't have that much time to work on it anymore, so currently it is more like a hack and probably not recommended for usage on high-level security servers without proper process isolation, but maybe someone needs it, feel free to improve it as you need :)
acme-client-portable-cf.patch.txt

I haven't yet tried the -f option to see if it overrides -m, but I think the default behavior to create an account key per domain is not a good choice. (I don't pretend to be an expert, but I don't think my previous, but unsatisfactory client, used separate account keys per domain.)

This seems similar to issue #10 but does not involve IPv6.

On an Ubuntu AWS instance (Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-77-generic x86_64)
freshly updated with dist-upgrade, I downloaded the latest LibreSSL (2.5.4) and the latest
acme-client-portable (0.1.16). I installed libseccomp-dev and libbsd-dev via apt-get,
built and installed LibreSSL (./configure && make && sudo make install), built acme-client-portable and got no errors whatsoever.

When I run acme-client I get this:

# acme-client -vNn example.com
acme-client: /etc/acme/privkey.pem: account key exists (not creating)
acme-client: /etc/ssl/acme/private/privkey.pem: domain key exists (not creating)
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 104.90.35.210
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:1408:2000:18b::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:1408:2000:19c::3d5
acme-client: 104.90.35.210: tls_connect_socket: acme-v01.api.letsencrypt.org, ssl verify memory setup failure
acme-client: https://acme-v01.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(31587): 1

I can use the openssl s_client command to connect to acme-v01.api.letsencrypt.org from the command line without issues. I have verified that I'm using the LibreSSL version of the openssl command from /usr/local/bin

For reference:

# openssl version                       
LibreSSL 2.4.5                                                                  
# uname -a                              
Linux ip-x-y-z-q 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux                                                   

Please let me know if there are more details I can provide.

Hi there,

Your project has a hardcoded URL reference to the current Let's Encrypt subscriber agreement:

https://github.com/kristapsdz/acme-client-portable/blob/e82c130dd942a74c50c1631042c1bc60fafe8bad/main.c#L35:L36

This URL is going to change November 15th. If your project does not address the stale URL at this point subsequent new-registration/account requests may begin to fail.

ACME clients do not need to hardcode a subscriber agreement URL and Let's Encrypt discourages this practice. You should learn the current agreement URL at runtime instead so that it is always current.

One option is to reference the agreement URL from the "meta" key's "terms-of-service" element from the response to a GET request to the ACME server's /directory endpoint:

{
  <snip>
  "meta": {
        "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"
  },
  <snip>
}

A second option is to learn the current subscriber agreement URL at runtime as part of the new-reg flow: Client code can submit an initial new-reg request without an agreement value in the request payload. The account will be created and in the response will be a Link header with a terms-of-service relation pointing at the current agreement URL. Once this Link header has been seen the client should update the registration to agree to the terms by sending a payload with the agreement value set to the current agreement URL.

Thanks!

And change the current default that creates multiple account keys if using domain-specific directories.

Hello,

It would be nice to use something like this:

# acme-client -d 60

-d - it creates a cron entry for 60 days.

Please sorry for a lot of FEATURE REQUEST, but I'm just want to improve this awesome tool (and I think I'm able to help in the implementation :-) ).

I downloaded letskencrypt-portable-0.1.7.tgz and the associated file letskencrypt-portable-0.1.7.sha256 from https://kristaps.bsd.lv/letskencrypt/snapshots/.

However, the checksum contains a SHA512 hash rather than a SHA256 hash:

$ cat letskencrypt-portable-0.1.7.sha256 
SHA512(letskencrypt-portable.tgz)= 8b0e7e47054ce272486d472cef9e48c54b6179cd2da50967f373dd552ff59dd495758c56f8e147513267800254909e88304908f1495a969ed24ce8b43c0c64de

Also, the checksum itself was calculated on the "unversioned" filename, which is a little confusing, since the filename of the checksum includes the version.

It's probably worth signing the checksum as well, whether with PGP or signify.

I will submit a PR for this soon.

NOTE: values are not real (represents results of letsencrypts' staging server for a test ip)

So this isn't an issue per say; its more of not understanding how the response the client returns maps to TXT records (given that each DNS api has a slightly different implementation).

Reading through the README, I see this:

When using -t, each domain (primary and altnames) is authorised over standard output 
and input between the caller and acme-client as follows:

  (a). acme-client prints “challenge-type dns-domain token.thumbprint\n” (note the trailing newline) on 
        its standard output.

  (b). The caller performs any tasks to implement the challenge's response.
  
  (c). The caller writes the same three-field string and the newline to the standard input of acme-client.

This cycle repeats for each requested domain, then acme-client exits.

My question is:

• Which of the 3 part string in (a) response corresponds to TXT VALUE ?

I have tried using:

• all 3 parts combined (respecting the spaces between the 1st two and the period that joins the token
  and thumbprint)
• only the token
• only the thumbprint

None of the above work; instead returning errors that match this:

acme-client: transfer buffer: [
  { 
    "type": "dns-01", 
    "status": "invalid", 
    "error": { 
      "type": "urn:acme:error:unauthorized", 
      "detail": "Incorrect TXT record \"TChR2DfPtEOyWaxl750J4E_sJo97szwCVHq3PT5NfRU.LyF9F8lc51hP9u3aOG7Lwnt-3DnMV2MpLi0RgHGM-VA\" found at _acme-challenge.sub.domain.com", 
      "status": 403 
    }, 
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/LPRoT8sfbwpbQU99UXs10jI1VSn9HyhfIFDcvcDlo9Y/158596424", 
  "token": "2Q_pQKPWiun16FT60BGriRh1Tcb7fXrmOCOLOYXXTPc", 
  "keyAuthorization": "2Q_pQKPWiun16FT60BGriRh1Tcb7fXrmOCOLOYXXTPc.LyF9F8lc51hP9u3aOG7Lwnt-3DnMV2MpLi0RgHGM-VA" 
  }
] 
(590 bytes)
acme-client: bad exit: netproc(48): 1

I also ran dig -t txt _acme-challenge.sub.domain.com and confirmed got this results:

; <<>> DiG 9.10.6 <<>> -t txt _acme-challenge.some.subdomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1043
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_acme-challenge.some.subdomain.com. IN  TXT

;; ANSWER SECTION:
_acme-challenge.some.subdomain.com. 3600 IN TXT  "RogJGpjq1B6_3EyvUzkBhWMS7SwodiInW3bwgsYPpss"

;; Query time: 48 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Aug 11 15:29:18 EDT 2018
;; MSG SIZE  rcvd: 118

I'm generating letsencrypt certificates for internal domains currently with a public dns challenge to avoid opening up internal hosts to the internet with a shell script.
(my longtime goal is to replace all the self signed in house certs with LE ones.)

To make my setup future proof (a.k.a. secure), I'm thinking about your client.
Are you in the progress of writing it? Or is there any clue how a contributor could hack together the dns challenge support?

The DNS resolver only returns at most one address. On my non-ipv6 freebsd system this happens to be a ipv6 address. This causes acme-client to fail as it cannot connect to an ipv6 address:

acme-client: acme-v01.api.letsencrypt.org: DNS: 2001:668:108:9a92::3d5
acme-client: 2001:668:108:9a92::3d5: connect: No route to host
acme-client: https://acme-v01.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(83700): 1

Strangely enough the code is fully equipped to handle multiple ip addresses, however an early "break" inside the getaddrinfo processing code is causing at most one address to be returned, see
https://github.com/kristapsdz/acme-client-portable/blob/master/dnsproc.c#L108

After applying the following patch

--- dnsproc.c.orig      2016-10-26 00:26:16.443321714 +0200
+++ dnsproc.c   2016-10-26 00:26:23.620804948 +0200
@@ -105,7 +105,6 @@

                dodbg("%s: DNS: %s", s, vec[vecsz].ip);
                vecsz++;
-               break;
        }

        freeaddrinfo(res0);

The network communication now works as expected:

acme-client: acme-v01.api.letsencrypt.org: DNS: 2001:428:7000:58c::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2001:428:7000:58b::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2.19.77.173
acme-client: 2001:428:7000:58c::3d5: connect: No route to host
acme-client: 2001:428:7000:58b::3d5: connect: No route to host

Hi there,

I'm trying to migrate from letsencrypt.sh to acme-client via the FreeBSD ports and getting the following error when running it:

acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 400

My acme-client.sh that I'm using to invoke the client looks like the following (this is the base sample that comes with the port with the extra -vv params added):

#!/bin/sh -e

BASEDIR="/usr/local/etc/acme"
SSLDIR="/usr/local/etc/ssl/acme"
DOMAINSFILE="${BASEDIR}/domains.txt"
CHALLENGEDIR="/usr/local/etc/ssl/acme"

[ ! -d "${SSLDIR}/private" ] && mkdir -pm700 "${SSLDIR}/private"

cat "${DOMAINSFILE}" | while read domain line ; do
   CERTSDIR="${SSLDIR}/${domain}"
   [ ! -d "${CERTSDIR}" ] && mkdir -pm755 "${CERTSDIR}"
   set +e # RC=2 when time to expire > 30 days
   acme-client -b -C "${CHALLENGEDIR}" \
               -k "${SSLDIR}/private/${domain}.pem" \
               -c "${CERTSDIR}" \
               ${domain} ${line} \
               -vv
   RC=$?
   set -e
   [ $RC -ne 0 -a $RC -ne 2 ] && exit $RC
done

The private keys were copied from letsencrypt.sh and are placed in /usr/local/etc/ssl/acme/private/

Given that this looks a bit like a black box am not sure how to proceed. Any help would be much appreciated, thank you in advance.

-- Attila

Running letskencrypt in a FreeBSD 10.3-RELEASE-p3 jail I get the following error message:

letskencrypt: /usr/local/etc/ssl/letsencrypt/private/.pem: generated RSA domain key
letskencrypt: /usr/local/etc/letsencrypt/privkey.pem: generated RSA account key
letskencrypt: https://acme-v01.api.letsencrypt.org/directory: directories
letskencrypt: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:7b:48f::3d5  
letskencrypt: https://acme-v01.api.letsencrypt.org/acme/new-reg: new-reg
letskencrypt: https://acme-v01.api.letsencrypt.org/acme/new-reg: bad HTTP: 400
letskencrypt: transfer buffer: [{ "type": "urn:acme:error:malformed", "detail": "Provided agreement URL [https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does not match current agreement URL [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]", "status": 400 }] (265 bytes)
letskencrypt: bad exit: netproc(76752): 1  

It seems that LetsEncrypt has updated their agreement:
dehydrated-io/dehydrated@afabfff
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833336

In Linux, libwaive can be used to implement parts of the functionality of pledge(2) without having to deal with seccomp filters (or libseccomp) manually. I have an not-so-complete but functional implementation of pledge(2) using libwaive which works fine for the portable signify which I have been maintaining. You may want to pick the code from there — it uses the same BSD license as OpenBSD.

Hello,

I can't make acme-client-portable work with libseccomp, whereas it works flawlessly without it.
Kernel: Linux-3.18.43. I have no choice about the kernel, unfortunately; if the answer is "it's too old", I'll understand. But it has CONFIG_SECCOMP=y, as well as CONFIG_SECCOMP_FILTER=y and CONFIG_HAVE_ARCH_SECCOMP_FILTER=y.
Libc: musl. The system has been entirely hand-built from scratch.
The numbers reported by the error message are 4:95.

Please let me know if you need more information.

dns-01 challenges require not just the token or privkey thumbprint, but an extra step of placing the urlsafeb64(sha256(token||"."||thumbprint)) into the DNS TXT RR. Wrapperware can do that computation, but why not just include it in dns-01 challenges since we already have all the inputs and functions?

Patch:
dnstxt.txt

I get the following error when I try to run the portable version:
letskencrypt: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 403

I also had to disable IPv6 since letskencrypt initially tried to connect via an IPv6 address.

I also made some changes to the code since it would not compile on my Debian.

In extern.h, I changed
include <bsd/stdlib.h>
include </bsdstring.h>
to
include <stdlib.h>
include <string.h>
BDW, the latter above is the correct way to include the standard header files.

I also changed main.c to use argv[0] instead of the BSD only 'getprogname()'.

Hello,

I've fixed issue #21 and finally acme client works like a charm here on my Ubuntu Server with nginx:

https://brookframework.org

So it would be nice to publish at the acme-client-portable page the full steps to use it with nginx and Ubuntu.

I did some changes in the files config.h and http.c, but I need to recreate the steps from scratch to get the changes I've done and finally open a pull-request sending a patch.

My colleagues have shamed me into using Homebrew, against my own judgment. Acme-client-portable does not build without change now because it doesn't know where to find LibreSSL. This patch should help it work for any Homebrew Mac while not harming a Mac without Homebrew. (It is not however clever enough to locate LibreSSL on a Mac that has Homebrew, but doesn't get LibreSSL from it.)

homebrew.txt

Such a feature would allow such options as OCSP, DOMAIN.TLD enforcement, and future key type selection to be set for consistency throughout the cert database.

Hello,

It would be nice to have the option make uninstall.

Thank you!

Config.h is not portable as it is configured to use <bsd/stdlib.h> and <bsd/string.h> did not work on Ubuntu Linux as packaged

The FreeBSD port builds acme-client with the static versions of the libressl libraries when libressl is not the default ssl. This worked until the libressl port was upgraded to 2.7.2. If you run:
acme-client -bmnNe -vvv -F -C /tmp example.net example.net
you'll see:
acme-client: tls_init: No error: 0
Here's a link to the FreeBSD PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228438
As far as I can tell the issue only surfaces when using the static libraries.

Hello,

Thank you for making this. I just started getting the deprecated message. I have tried to update the url to no avail. I have been trying using https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf for the url.

Thank you again.

I'm trying to maintain multiple certificates, so I'm using -m key. Obtaining a certificate seem to work fine

acme-client: /usr/local/etc/ssl/acme/domain.org: creating directory
acme-client: /usr/local/etc/ssl/acme/private/domain.org: creating directory
acme-client: /usr/local/etc/acme/domain.org: creating directory
acme-client: /usr/local/etc/ssl/acme/private/domain.org/privkey.pem: generating RSA domain key
acme-client: /usr/local/etc/acme/domain.org/privkey.pem: generating RSA account key
acme-client: adding SAN: domain.org
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 1:2::3:4
acme-client: acme-v01.api.letsencrypt.org: DNS: 1:2::3:4
acme-client: acme-v01.api.letsencrypt.org: DNS: 1.2.3.4
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: new-reg
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: domain.org
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: domain.org
acme-client: /usr/local/www/acme/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: created
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY/1588909670: challenge
acme-client: /usr/local/www/acme/UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU: created
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ/1588909727: challenge
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY/1588909670: status
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ/1588909727: status
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
acme-client: http://cert.int-x3.letsencrypt.org/: full chain
acme-client: cert.int-x3.letsencrypt.org: DNS: 2a00:1e48:1:41::bc2b:4c33
acme-client: cert.int-x3.letsencrypt.org: DNS: 2a00:1e48:1:41::bc2b:4c3a
acme-client: cert.int-x3.letsencrypt.org: DNS: 87.245.196.83
acme-client: cert.int-x3.letsencrypt.org: DNS: 87.245.196.99
acme-client: /usr/local/etc/ssl/acme/domain.org/cert.pem: linked to cert-1500654343.pem
acme-client: /usr/local/etc/ssl/acme/domain.org/chain.pem: linked to chain-1500654343.pem
acme-client: /usr/local/etc/ssl/acme/domain.org/fullchain.pem: linked to fullchain-1500654343.pem
acme-client: /usr/local/etc/ssl/acme/domain.org/chain.pem: created
acme-client: /usr/local/etc/ssl/acme/domain.org/cert.pem: created
acme-client: /usr/local/etc/ssl/acme/domain.org/fullchain.pem: created

but trying to update it fails:

acme-client: /usr/local/etc/acme/domain.org/privkey.pem: account key exists (not creating)
acme-client: /usr/local/etc/ssl/acme/private/domain.org/privkey.pem: domain key exists (not creating)
acme-client: adding SAN: domain.org
acme-client: /usr/local/etc/ssl/acme/domain.org/cert.pem: domain not listed: domain.org
acme-client: bad exit: revokeproc(26165): 1

I'm using the same command for both:

/usr/local/bin/acme-client -vNnb -m domain.org domain.org

When using -t dns-01 to use a different validation method, acme-client instantly exits with an error, if the validation fails on first try:

acme-client: https://acme-staging.api.letsencrypt.org/acme/challenge/foobar/123: bad response
acme-client: transfer buffer: [{ "type": "dns-01", "status": "invalid", "error": { "type": "urn:acme:error:connection", "detail": "DNS problem: NXDOMAIN looking up TXT

-OR-

acme-client: https://acme-staging.api.letsencrypt.org/acme/challenge/foobar/123: bad response
acme-client: transfer buffer: [{ "type": "dns-01", "status": "invalid", "error": { "type": "urn:acme:error:unauthorized", "detail": "Correct value not found for DNS challenge",

Some validation methods like DNS-01 may take a few seconds or minutes before validation can succeed (depending on the DNS provider used).

Please add an option to allow acme-client to retry for a specified amount of time. Maybe something like -R 30 (retry 30 times) and -w 5 (wait 5 seconds between retries).

(As an alternative, maybe print the challenge URL earlier in the process, so that the external validation script can check the validation status before allowing acme-client to continue.)

Can you tag a new release? The current one is a bit stale.

Hello,

I've studied acme-client-portable sources and noticed that it could be a very useful library to be used in other languages like Python, JS, Pascal etc.

So, what do you think about to refactore acme-client-portable in a near future to make it a library? :-) With the library in hands, the acme-client-portable tool could use it. The curl tool follows a similar approach, it uses its libcurl library, and the new features are implemented in the library.

Now I'm getting the following:

$ sudo LD_LIBRARY_PATH=/usr/local/lib ./letskencrypt -vNn foo.com www.foo.com

: letskencrypt: /var/empty: chroot: No such file or directory
/var/empty: chroot: No such file or directory
/var/empty: chroot: No such file or directory
letskencrypt: /var/empty: chroot: No such file or directory
/var/empty: chroot: No such file or directory

I'm on Ubuntu.

sorry wrong repository!

Hello,

I would like to see some document showing the full steps to use acme client with letsencrypt CA. This was my result (the info below are just fictitious, however I've tried it with real info in my production environment and got similar errors):

1. root@myvps:/home/myuser# mkdir /etc/ssl/acme
2. root@myvps:/home/myuser# mkdir /etc/ssl/acme/private /etc/acme
3. root@myvps:/home/myuser# chmod 0700 /etc/ssl/acme/private /etc/acme
4. root@myvps:/home/myuser# acme-client -vNn mydomain.org www.mydomain.org
5. acme-client: /var/empty: chroot: No such file or directory
6. root@myvps:/home/myuser# acme-client: acme-client: acme-client: acme-client: /var/empty: chroot: No such file or directory
7. /var/empty: chroot: No such file or directory
8. /var/empty: chroot: No such file or directory
9. /var/empty: chroot: No such file or directory
10. acme-client: tls_config_set_ca_file: failed to open CA file '/etc/ssl/cert.pem': No such file or directory: No such file or directory
11. acme-client: /var/empty: chroot: No such file or directory

If I've understood the log, do I need to create a /var/empty directory too?

I've used certbot and it have worked fine, but I'm don't like to download a lot of python packages just to use a letsencrypt client, so I'm trying acme client, however I'm not sure if it really uses letsencrypt REST API to automate the steps, and I don't know how I could do it manually. :-/

Edit 1:

I'm using nginx server 1.12.0 downloaded from its PPA.

Edit 2:

I'm using Ubuntu Sever 16.04 - 64 bits.

Edit 3:

The steps I've tried was from man acme-client.

tried compiling from git,
installed libbsd from src.rpm, needed openssl-devel to compile, when trying to get libreSSL into the system, my knowledge (or time) so far fails, since the base install of my linux is dependent on OpenSSL.

Is there an easy way to get acme-client-portable compiled against a local LibreSSL?
(Do I need more GNUMakefile-Foo for that?)

The current cert creation process allows the first domain to be HOST.DOMAIN.TLD. The requested option would allow a user to enforce a stricter cert naming policy in his cert database.

It looks like letsencrypt has changed something, so now acme-client (0.1.16, FreeBSD) croaks with

acme-client: http://cert.int-x3.letsencrypt.org/: bad HTTP: 301

If one tries to access the URL in question by hand, the redirect is towards

https://letsencrypt.org/cert.int-x3/

I am surprized that acme-client does not follow redirects already, was it coded like that for security reasons?

Sveiki,
Thanks for a great piece of software. Perhaps I've missed it somewhere, but is there an option for the client to provide the recommended expiration email?

I've played around with the staging server, it worked fine. But when trying to generate the real certificate, I got the following error.

# acme-client -v foo.com                                                                                                        
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:dc:1a1::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:dc:190::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 104.127.53.83
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: foo.com
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "No registration exists matching provided key", "status": 403 }] (120 bytes)
acme-client: bad exit: netproc(3777): 1

(The domain I specify on the command line doesn't seem to affect anything.)

As far as I understand the problem is that -n (creates and registers) if key not exists. There doesn't seem to be a way to register an existing key currently.
I've found this on the internet: https://unix.stackexchange.com/questions/369261/switching-from-letsencrypt-client-to-acme-client-where-is-my-account-key/369661 It suggests using -DA options, but my version of acme-client doesn't seem to understand it. Maybe an older version had them or they just mixed it up with the ruby program of the same name?

Using acme-client 0.1.16 from alpine x86_64.

root@lepton ~/bin # ./update_ssl.sh
acme-client: /etc/ssl/acme/xxxxxxxxxxxxxxxx: creating directory
acme-client: /etc/ssl/acme/private/xxxxxxxxxxxxxxxxx: creating directory
acme-client: /etc/acme/xxxxxxxxxxxxxxxxxxx: creating directory
acme-client: /etc/acme/xxxxxxxxxxxxxxx/privkey.pem: generating RSA account key
acme-client: /etc/ssl/acme/private/xxxxxxxxxxxxxx/privkey.pem: generating RSA domain key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:78:19d::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2a02:26f0:78:189::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 95.101.240.249
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: new-reg
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: bad HTTP: 400
acme-client: transfer buffer: [{ "type": "urn:acme:error:malformed", "detail": "Provided agreement URL [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf] does not match current agreement URL [https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf]", "status": 400 }] (267 bytes)
acme-client: bad exit: netproc(29347): 1

it seems to Letsencrypt changes their agreement every year

Hello,
unfortunatelly the portable ACME client does not support CentOS 6.9.
Attached you'll find the modifications for support this operating system as well.

Regards,
Guenther

acme-client-portable-0.1.16-patches.zip