kristapsdz / acme-client Goto Github PK

So we are moving all our systems from Linux to BSD and we want to use acme-client. We configure all our systems with ansible right now and we're not sure the best way to handle this situation.

If we are standing up a new www server that hosts a number of different domains, we can't just start nginx with our normal configuration because the certs don't yet exist on the system. We can't get the certs with acme-client because it depends on a nginx or apache config, there's no internal www server it can use like with the python version of letsencrypt.

So what is the best way for us to handle this? Do we have to generate a dummy config for nginx every time we add a new domain and load that up temporarily till we have the initial cert? Is there a better way?

Sorry if this is way out of scope for the issue tracker.

When trying to add an additional SubjectAltName to an existing cert (like certbot's --expand), acme-client does not appear to like this change.

For example, adding test.cluebyfour.nl to a certificate, acme-client complains.

# acme-client -bmNv -f /etc/letsencrypt/account-key.pem cluebyfour.nl www.cluebyfour.nl test.cluebyfour.nl
acme-client: /etc/ssl/letsencrypt/private/cluebyfour.nl/privkey.pem: domain key exists (not creating)
acme-client: /etc/ssl/letsencrypt/cluebyfour.nl/cert.pem: domain not listed: test.cluebyfour.nl
acme-client: bad exit: revokeproc(86494): 1

When I first delete the existing certificate, the command completes fine (i.e. performs a challenge and obtains a cert with the requested SANs).

Proposed fix: create an option -E that copes with a domain that is not listed in the current certificate and requests a new certificate with SANs provided on the command line. A patch file to this effect is attached. Do you agree with the approach taken (still emit a warning, but only break out if ' expand == 0' )?

20161003 acme-client expand.patch.txt

When using LibreSSL 2.7.3, acme-client dies with

bad exit: netproc(29011): 1\0

This failure is not encountered when using LibreSSL 2.7.2.

See also: https://bugs.freebsd.org/228438 (incl. dtruss log)

Should be updated to:

https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf

According to https://letsencrypt.org/docs/expiration-emails/, if a contact mailto address is set at account registration (or updated to include a mailto address at some later point), Let's Encrypt will provide email notifications of expiry at 20, 10 and 1 days to expiry.

Due to faulty configuration my part I've had a certificate expire without realizing it. This seems like a great feature provided by Let's Encrypt and it'd be great if acme-client could expose the mechanism required to set/update the contact mailto address so that this feature works for acme-client users.

Here's the relevant bits in certbot that update the registration with the contact mailto address. Here's the relevant bit of the spec (though it does not detail the Let's Encrypt specific behavior).

Since September, every time I want to renew my certificate, I get:

acme-client: transfer buffer: [{ "type": "urn:acme:error:badNonce", "detail": "JWS has invalid anti-replay nonce 8QFQ22xIDcN0kq-CtGCiKNg6rjD3Cn7jHYz7XXbMNFU", "status": 400 }] (149 bytes)                      

The command I use is:

acme-client -vnNFO -f /usr/local/etc/acme/privkey.pem -k /usr/local/etc/ssl/acme/private/privkey.pem [follows 10 domains]

It worked fine before. Moreover, it still works fine if I add -s (staging server).

Before September, I renewed my certs in June, so the breakage must have happened in during those 3 months.

I use version 0.1.16 on FreeBSD 11.1-STABLE.

hello, I want to congratulate you on a good program!
Do you have plans to develop a second version?
ACME v2 and Wildcard Certificate Support is Live

FreeBSD 10.3-RELEASE #0 r322073:
acme-client-0.1.16_2
apache24-2.4.29

Things seemed to be going well and then....

# acme-client -mvnNC /usr/local/www/.well-known/acme-challenge/  blackrosetech.com www.blackrosetech.com

acme-client: /usr/local/etc/acme/blackrosetech.com/privkey.pem: account key exists (not creating)

acme-client: /usr/local/etc/ssl/acme/private/blackrosetech.com/privkey.pem: domain key exists (not creating)

acme-client: adding SAN: www.blackrosetech.com

acme-client: https://acme-v01.api.letsencrypt.org/directory: directories

acme-client: acme-v01.api.letsencrypt.org: DNS: 173.223.13.221

acme-client: acme-v01.api.letsencrypt.org: DNS: 2001:418:142b:290::3d5

acme-client: acme-v01.api.letsencrypt.org: DNS: 2001:418:142b:298::3d5

acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: blackrosetech.com

acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: www.blackrosetech.com

acme-client: /usr/local/www/.well-known/acme-challenge
//xFv8GQsOmmH9Xb7ilLbEwm6HdLK2V7r9hN7CehmX88Y: created

acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/h_2462QzmjXdshgAoW9hhEm1BsgdlCblSpuc-_EiuKg/2617044563: challenge

acme-client: /usr/local/www/.well-known/acme-challenge//RLVfYFtDGjmDRtCt5F4jIR7M68ZCHaHND5tOcEWwky0: created

acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/mqIypPPbaC0vQDdzmJYSgOIq4Pl_1SkL2lU-D8bnAq0/2617044643: challenge

acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/h_2462QzmjXdshgAoW9hhEm1BsgdlCblSpuc-_EiuKg/2617044563: status

acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/h_2462QzmjXdshgAoW9hhEm1BsgdlCblSpuc-_EiuKg/2617044563: bad response

acme-client: transfer buffer: [{ "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:unauthorized", "detail": "Invalid response from http://blackrosetech.com/.well-known/acme-challenge/xFv8GQsOmmH9Xb7ilLbEwm6HdLK2V7r9hN7CehmX88Y: \"\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"\n \"http://www.w3.org/TR/xhtml1/D\"", "status": 403 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/h_2462QzmjXdshgAoW9hhEm1BsgdlCblSpuc-_EiuKg/2617044563", "token": "xFv8GQsOmmH9Xb7ilLbEwm6HdLK2V7r9hN7CehmX88Y", "keyAuthorization": "xFv8GQsOmmH9Xb7ilLbEwm6HdLK2V7r9hN7CehmX88Y.avuwT15Qa6f3G4JGQhZwkIQs2eeNN6_EAtalAI2qhtg", "validationRecord": [ { "url": "http://blackrosetech.com/.well-known/acme-challenge/xFv8GQsOmmH9Xb7ilLbEwm6HdLK2V7r9hN7CehmX88Y", "hostname": "blackrosetech.com", "port": "80", "addressesResolved": [ "173.228.36.130" ], "addressUsed": "173.228.36.130", "addressesTried": [] } ] }] (1049 bytes)

acme-client: bad exit: netproc(36406): 1

I'm running it as root, and this is what I get when running it, repeated about a dozen times together with "acme-client: drop privileges".

Shouldn't certs being up to date not be an error? Also, if that is why it's returning 2, then there probably should be a message in verbose mode at the very least.

Output:

May 21 03:41:36 abyss acme-client[6166]: acme-client: acme-client: acme-client: /etc/acme/privkey.pem: loading RSA account key
May 21 03:41:36 abyss acme-client[6166]: /etc/ssl/acme/cert.pem: certificate valid: 89 days left
May 21 03:41:36 abyss acme-client[6166]: /etc/ssl/acme/private/privkey.pem: loading domain key
May 21 03:41:36 abyss acme-client[6166]: acme-client: /etc/ssl/acme/private/privkey.pem: loaded RSA domain key
May 21 03:41:36 abyss acme-client[6166]: acme-client: adding SAN: www.lfcode.ca
May 21 03:41:36 abyss systemd[1]: acme.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Version: 0.1.16 on Arch Linux (AUR package version)

I get a strange error, when I try to run acme-client. I can't be sure if it is a bug or if I'm using it wrang, because I don't understand the error. I'm running freebsd and libressl is installed.

acme-client -vNn sitename.de www.sitename.de
acme-client: /usr/local/etc/ssl/acme/private/privkey.pem: generating RSA domain key
acme-client: /etc/ssl/cert.pem: No such file or directory
acme-client: /usr/local/etc/acme/privkey.pem: generating RSA account key
acme-client: adding SAN: www.sitename.de
acme-client: bad exit: netproc(35417): 1

Thank you for your work!

Hi! I am using 0.17 on OpenBSD 5.9-Stable. I have read that I need to create an account key first using -n. However, all attempts on using -n properly failed:

# letskencrypt -n                                                                                                               
usage: letskencrypt [-Fnrsv] [-C challengedir] [-c certdir] [-f accountkey] [-k domainkey] [-u user] domain [altnames...]
# letskencrypt -n my-domain.com
letskencrypt: /etc/ssl/letsencrypt/private/privkey.pem: -k file must exist

I have read the man page a dozen times and can't figure it out. thanks for your help.

Hi,

What is the equivalent letskencrypt command for the following command line?

$ letsencrypt-auto certonly --standalone -d mydomain.com

I am seeing acme-client from pkg in FreeBSD 11.1-RELEASE hang on trying to create a new certificate.
acme-client-0.1.16_1
I am seeing the same behavior with acme-client-portable compiled from source.

$ acme-client -vNn $MYDOMAIN
acme-client: acme-client: /usr/local/etc/ssl/acme/private/privkey.pem: generating RSA domain key
/usr/local/etc/acme/privkey.pem: generating RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 118.214.136.206
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:140f:5:190::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:140f:5:185::3d5
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: $MYDOMAIN
acme-client: /usr/local/www/acme/pOhU3dDhHYyjyAM4SSkuiivzdhwgP3BnTCgwCofWf5Q: created
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/6vV3EBQCqoq64zla9xtO8GQmoFqXnkPa8X-XaIu8Y-g/2135641107: challenge
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/6vV3EBQCqoq64zla9xtO8GQmoFqXnkPa8X-XaIu8Y-g/2135641107: 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: 124.124.252.172
acme-client: cert.int-x3.letsencrypt.org: DNS: 124.124.252.99
acme-client: cert.int-x3.letsencrypt.org: DNS: 2600:1417:6d::170f:221a
acme-client: cert.int-x3.letsencrypt.org: DNS: 2600:1417:6d::170f:221b

It remains stuck at this point indefinitely until eventually terminating without writing the certificate, chain or fullchain to /usr/local/etc/ssl/acme/. I have tested with the staging servers where acme-client completes successfully without any errors. I have generated many certificates with acme-client, thank you for writing this excellent software! I am unsure why it is failing in this case and I would appreciate any assistance in troubleshooting this matter.

hi.

i think the client is trying to check if file / directory exists but it does not grant execution permission to any of the directory created

acme-client -vv mydomain.com
acme-client: /etc/acme/letsencrypt-privkey.pem: PEM_read_PrivateKeyacme-client: /etc/ssl/private/mydomain.key: loaded RSA domain key
2098358032:error:09FFF06C:PEM routines:CRYPTO_internal:no start line:/usr/src/lib/libcrypto/pem/pem_lib.c:690:Expecting: ANY PRIVATE KEY
acme-client: /etc/ssl/mydomain.crt: certificate valid: 37 days left
acme-client: bad exit: acctproc(63594): 1

This is a machine running obsd 6.1. I have another machine with 6.1 on which I generated the key/crt. I then copied them over to this machine (port 80 is blocked; it only runs https), upgraded it from 6.0 to 6.1 and tried to run acme-client.

1. Can acme-client renew certs if via my server running only on https?
2. Will this error prevent its renewal?
3. How can I eliminate this error?

While trying to fix a bug on my server (or so I think), I tried several times to get certs with the test api.

I finally chose a solution, and run on the prod' api, while changing nothing on the server (I just erased the files created with the test api and suppress the "-s" from my command line).

The certs could not be created anymore.

letskencrypt: transfer buffer: [{ "type": "http-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/qk30yIQMeQ6m-vrDqbsPYF7kS_qvlxjGeWZin7rxpvs/200241337", "token": "8Qk0RMRSHnW7nLzgjSQCi1OUYq3ATqAQ_cpSUpd3_cA", "keyAuthorization": "8Qk0RMRSHnW7nLzgjSQCi1OUYq3ATqAQ_cpSUpd3_cA.L4TPRmCy6xGjPSjU2Xzk1Yq6IDS9Z3hiv2ASxM1z42s" }] (335 bytes) letskencrypt: https://acme-v01.api.letsencrypt.org/acme/challenge/E4c3aP9ie4NCyIXYBg3LomYaNlFF1ycX6c6MJPZnPgQ/200241262: status letskencrypt: acme-v01.api.letsencrypt.org: cached letskencrypt: https://acme-v01.api.letsencrypt.org/acme/challenge/E4c3aP9ie4NCyIXYBg3LomYaNlFF1ycX6c6MJPZnPgQ/200241262: bad response letskencrypt: transfer buffer: [{ "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:unauthorized", "detail": "Invalid response from http://www.22decembre.eu/.well-known/acme-challenge/WscTza4K92kl6v_Ikk87h4KrQ7NCjLltNklx1jPAGvU: \"\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n\u003cmeta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\"/\u003e\n\u003ctitle\u003e404 Not Found\u003c/title\u003e\n\"", "status": 403 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/E4c3aP9ie4NCyIXYBg3LomYaNlFF1ycX6c6MJPZnPgQ/200241262", "token": "WscTza4K92kl6v_Ikk87h4KrQ7NCjLltNklx1jPAGvU", "keyAuthorization": "WscTza4K92kl6v_Ikk87h4KrQ7NCjLltNklx1jPAGvU.L4TPRmCy6xGjPSjU2Xzk1Yq6IDS9Z3hiv2ASxM1z42s", "validationRecord": [ { "url": "http://www.22decembre.eu/.well-known/acme-challenge/WscTza4K92kl6v_Ikk87h4KrQ7NCjLltNklx1jPAGvU", "hostname": "www.22decembre.eu", "port": "80", "addressesResolved": [ "87.63.104.30", "2001:470:2099:e2::2" ], "addressUsed": "87.63.104.30" }, { "url": "https://www.22decembre.eu/.well-known/acme-challenge/WscTza4K92kl6v_Ikk87h4KrQ7NCjLltNklx1jPAGvU", "hostname": "www.22decembre.eu", "port": "443", "addressesResolved": [ "87.63.104.30", "2001:470:2099:e2::2" ], "addressUsed": "87.63.104.30" } ] }] (1406 bytes) letskencrypt: bad exit code: netproc(81652)

All my virtual hosts got their requests pending and the certs were not issued.

I tried once again with the test api. The hosts got their requests successfully valid and the cert was created.

Hey,

I know this setup is probably unsupported, but I'm wondering whether I found a bug:

Just built acme-client from CVS HEAD on OpenBSD 6.0. Whenever I try to request a certificate, the process gets terminated (due to missing pledge priviledges?):

ira ~ # acme-client -vvvAD domain.org
acme-client: /etc/ssl/acme/private/privkey.pem: domain key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: /etc/ssl/acme/private/privkey.pem: loaded RSA domain key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.62.131.169
acme-client: signal: netproc(9472): Abort trap

dmesg lists the following:
acme-client(9472): syscall 5 "rpath"

and a backtrace:

ira ~ # gdb /usr/sbin/acme-client acme-client.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...
Core was generated by `acme-client'.
Program terminated with signal 6, Aborted.
Loaded symbols for /usr/sbin/acme-client
Reading symbols from /usr/lib/libtls.so.11.0...done.
Loaded symbols for /usr/lib/libtls.so.11.0
Reading symbols from /usr/lib/libssl.so.39.0...done.
Loaded symbols for /usr/lib/libssl.so.39.0
Reading symbols from /usr/lib/libcrypto.so.38.0...done.
Loaded symbols for /usr/lib/libcrypto.so.38.0
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x00000b4d84c878ba in _thread_sys_open () at <stdin>:2
2       <stdin>: No such file or directory.
        in <stdin>
(gdb) bt
#0  0x00000b4d84c878ba in _thread_sys_open () at <stdin>:2
#1  0x00000b4d84cf3ec9 in *_libc_open_cancel (path=Variable "path" is not available.
) at /usr/src/lib/libc/sys/w_open.c:36
#2  0x00000b4d84c85dc2 in *_libc_fopen (file=0xb4cf0d08fc0 "/etc/ssl/cert.pem", mode=Variable "mode" is not available.
) at /usr/src/lib/libc/stdio/fopen.c:54
#3  0x00000b4d14df6a8e in BIO_new_file (filename=0xb4cf0d08fc0 "/etc/ssl/cert.pem", mode=0xb4d14f9fc63 "r")
    at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:119
#4  0x00000b4d14e6914f in X509_load_cert_crl_file (ctx=0xb4cd4a84b00, file=Variable "file" is not available.
)
    at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/by_file.c:249
#5  0x00000b4d14e692af in by_file_ctrl (ctx=0xb4cd4a84b00, cmd=Variable "cmd" is not available.
)
    at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/by_file.c:110
#6  0x00000b4d14e094ee in X509_STORE_load_locations (ctx=0xb4d63666e00, file=0xb4cf0d08fc0 "/etc/ssl/cert.pem", path=0x0)
    at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/x509_d2.c:96
#7  0x00000b4d96636739 in tls_configure_ssl_verify (ctx=0xb4da9333680, verify=Variable "verify" is not available.
) at tls.c:348
#8  0x00000b4d96638ac0 in tls_connect_fds (ctx=0xb4da9333680, fd_read=3, fd_write=3, 
    servername=0xb4d3d733960 "acme-v01.api.letsencrypt.org") at tls_client.c:208
#9  0x00000b4ac6e06e1a in http_alloc (addrs=0x7f7ffffed630, addrsz=1, host=0xb4d3ce49f40 "acme-v01.api.letsencrypt.org", port=443, 
    path=0xb4d7e135e10 "/directory") at http.c:325
#10 0x00000b4ac6e07a8e in http_get (addrs=0x7f7ffffed630, addrsz=1, domain=0xb4d3ce49f40 "acme-v01.api.letsencrypt.org", port=443, 
    path=0xb4d7e135e10 "/directory", post=0x0, postsz=0) at http.c:690
#11 0x00000b4ac6e0b6f1 in nreq (c=0x7f7ffffed7a0, addr=0xb4d9b211880 "https://acme-v01.api.letsencrypt.org/directory")
    at netproc.c:199
#12 0x00000b4ac6e0c413 in dodirs (c=0x7f7ffffed7a0, addr=0xb4d9b211880 "https://acme-v01.api.letsencrypt.org/directory", 
    paths=0x7f7ffffed780) at netproc.c:522
#13 0x00000b4ac6e0c81a in netproc (kfd=4, afd=6, Cfd=8, cfd=10, dfd=14, rfd=16, newacct=0, revocate=0, authority=0xb4d8535ba00, 
    alts=0xb4d98e33a40, altsz=8, agreement=0xb4da9333580 "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf")
    at netproc.c:654
#14 0x00000b4ac6e0aadf in main (argc=0, argv=0x7f7ffffeda00) at main.c:262
Current language:  auto; currently asm
(gdb)

hi
where can i see list of netproc errors?

Hi there,

nice work on the privsep. Loving it! The only problem seems to be that your domain_valid function has a funky check that prevents some of our domains to not work (but i have working certs from letsencrypt.sh). My private box for example has an issue with 'el8.nl'.

Checking Let's Encrypt certificate status:
letskencrypt: el8.nl: bad domain syntax
Deploying Let's Encrypt certificates:

i believe the registry made the right choice in reference to the RFC :)

thanks

Current implementation does not generate a new domainkey when a new certificate is requested.

Proposed behaviour on renewal (both TTL < 30days and forced):

1. Rename domainkey (append seconds since epoch?)
2. Move contents of certdir to certdir/secondssinceepoch to allow for revocation after new certs are generated
3. Create new domainkey
4. Generate new cert/chain/fullchain.pem with new domainkey

Subseqently a user may easily revoke without having backed-up the domainkey+cert

Hi,

Any suggestions on how to get letskencrypt going with relayd only on a machine?
There is not really an easy way to point it to the .well-known/acme-challenge/. :(

I have relayd running on one machine and httpd on others. Terminating all SSL centrally on the relayd machine.

Thanx!

Mischa

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

I am having a hard time understanding understanding why acme-client keeps returning a 403 even though SHA356 and base64url encoding has been performed on the keyAuthorization it returns.

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.

I am reading through sections 8.1 - 8.4 of the ietf spec for acme.

• spec says:

A client fulfills this challenge by constructing a key authorization
from the "token" value provided in the challenge and the client's
account key.

acme-client json response contains a keyAuthorization field:

  acme-client: transfer buffer: [
    ...
    "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/LPRoT8sfbwpbQU99UXs10jI1VSn9HyhfIFDcvcDlo9Y/158596424", 
    "token": "2Q_pQKPWiun16FT60BGriRh1Tcb7fXrmOCOLOYXXTPc", 
    "keyAuthorization": "2Q_pQKPWiun16FT60BGriRh1Tcb7fXrmOCOLOYXXTPc.LyF9F8lc51hP9u3aOG7Lwnt-3DnMV2MpLi0RgHGM-VA" 
    }
  ] 

Spec goes on to say:

The client then computes the SHA-256 digest [FIPS180-4] of the key authorization. The record provisioned to the DNS contains the base64url encoding of this digest.

So I do this:

echo mKJ0LZl4leYPbQpTVDGySfbMJygw8cCJZkiAP9r9KY.cB_s97CUBrQMLZTLbiy4U1Mzi2nwBM7ZL6PdELcX1Ls | openssl dgst -sha256 | base64 | tr '+\/' '-_' | tr -d '='

and place the return value of into the TXT field of my provider.

The above steps should cover the 2. The caller performs any tasks to implement the challenge's response.

Then I write to the stand input of acme-client as instructed in 3. The caller writes the same three-field string and the newline to the standard input of acme-client.

And yet, each time the result is a 403 error that looks like this :

{
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Incorrect TXT record \"KHN0ZGluKT0gYmFmOGVkMmIwY2UxZjM1NDk0ODJiZTQ1ZjBlOGQyYmQ0NzgxOTk3YTM2N2FhNjFkNGQzYjUzMjQ4ODY5MDVmZQo\" found at _acme-challenge.manual.uzoagu.com",
    "status": 403
  },
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/zfL7sjh4R0l3UjW-5HuZRDjA0OcbMgIGwEkDd9t1ML0/158926539",
  "token": "mKJ0LZl4leYPbQpTVDGySfbMJygw8cCJZkiAP9r-9KY",
  "keyAuthorization": "mKJ0LZl4leYPbQpTVDGySfbMJygw8cCJZkiAP9r-9KY.cB_s97CUBrQMLZTLbiy4U1Mzi2nwBM7ZL6PdELcX1Ls"
}

I would greatly appreciate it you could let me know if the error is on my end. I can't find information online on how other people use this tool. thanks.

Hi,
Is it the same version that is included in OpenBSD 6.1 ? how to use ECSDA key ?

regards

Thank you for developing letskencrypt, it has become my preferred way of using Let's Encrypt.

However, you might want to consider redesigning the error-behavior of flags such as -n and -N.

Example: if -n and -N did not fail but were a noop if the domain / account key already exists, there would not be a need for special-casing this in automatic deployments (shell scripts, Ansible modules, ...).

Have you considered this aspect already? I would like to know your opinion on this topic.

On Freenas (Freebsd 11.0 - acme version 0.1.16_2 - freebsd port), got "timingsafe_memcmp" (netproc) issue.

Since 0.1.12 main.c fails to compile

FreeBSD 11.0-p2
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)

gmake[2]: Entering directory '/usr/ports/security/acme-client/work/acme-client-portable-0.1.12'
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o acctproc.o acctproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o base64.o base64.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o certproc.o certproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o chngproc.o chngproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o dbg.o dbg.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o dnsproc.o dnsproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o fileproc.o fileproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o http.o http.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o jsmn.o jsmn.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o json.o json.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o keyproc.o keyproc.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o main.o main.c
cc -O2 -fno-strict-aliasing -pipe -march=native  -fstack-protector -g -W -Wall -DHAVE_CONFIG_H -I/usr/local/include   -c -o netproc.o netproc.c
main.c:123:8: error: unknown type name '__dead'
static __dead void
       ^
main.c:123:15: error: expected identifier or '('
static __dead void
              ^
main.c:490:3: warning: implicit declaration of function 'xrun' is invalid in C99 [-Wimplicit-function-declaration]
                xrun(COMP_NET, newargs);
                ^
1 warning and 2 errors generated.
gmake[2]: *** [<builtin>: main.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory '/usr/ports/security/acme-client/work/acme-client-portable-0.1.12'

Hi,

Thanks for your amazing work! We are using your client in mailcow: dockerized. :-)

A feature request: Is it possible to make acme-client filter duplicate domain names? Or print a warning instead of exiting?

Bye
André

acme-client doesn't seem to support ECDSA keys yet (for use in the cert, not as the account key), though Let's Encrypt has added support for them.

It would be very nice to at least support loading an externally-generated key, even if having acme-client generate them is too complicated.

When running acme-client -vvNn mydomain.com sub.mydomain.com, nothing is being written to /var/www/acme. No errors are thrown by acme-client, but obviously the challenges from Let's Encrypt fail because there's nothing to be served to them. I don't have much to go on, I've done everything mentioned in the man page, all communications with the Let's Encrypt servers seem to be working, but nothing gets written.

Key generation can take a long time on slow hardware. With -vNn I would have expected some feedback about what is happening. Perhaps a sequence like this (pseudocode) would be better:

log("%s: generating RSA %s key...", file, keytype);
keygen(file, keytype);
log("done.\n");

Hi,

just a ping that the main project site is down and not responding.

Let's Encrypt now provides an option to use OCSP Must Staple, which enforces the use of OCSP Stapling on certificate level (letsencrypt/boulder#989 (comment)).

Acme-client doesn't provide such option yet.

For various reasons, it can be positive to keep the previous certificates while generating new ones.

For exemple, the new ones could be invalid or buggy, or one want to use DANE, thus needing to wait for DNS propagation.

Currently, letskencrypt store certs at standard place and erase them when generating new ones. There should at least be an option to keep them when creating the new ones.

Hi

I tried to verify the hash of the 0.1.14 release.

The .sha512 file contains this: SHA512(acme-client-0.1.14.tgz)=...

This command tells me the file is not in the checklist:

$ sha512 -C acme-client-0.1.14.sha512 acme-client-0.1.14.tgz 
sha512: acme-client-0.1.14.tgz does not exist in acme-client-0.1.14.sha512

Now if I put whitespaces before and after the braces, it works: SHA512 (acme-client-0.1.14.tgz) =

$ sha512 -C acme-client-0.1.14.sha512 acme-client-0.1.14.tgz 
(SHA512) acme-client-0.1.14.tgz: OK

I'm on OpenBSD 6.0 -stable.

The man page goes into some detail about configuring nginx but it leaves out how to setup the ~/.well-known/ stuff for registration to work. I have tired to get this working myself without much luck.

I have the following in my nginx.conf

server {
  listen 80;
  server_name mydomain.com;
  include /usr/local/etc/nginx/conf/acme.conf;
}

Contents of acme.conf

location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /usr/local/www/acme;
}

location = /.well-known/acme-challenge/ {
    return 404;
}

Registration with acme-client fails every time.

Testing on a domain with staging, say:
# acme-client -mvnsNC /usr/local/www/.well-known/acme-challenge fl4t.us www.fl4t.us

works fine. However, the cert is, unsurprisingly, not recognized (as expected) as it is staging.

Unfortunately
# acme-client -mvnFNC /usr/local/www/.well-known/acme-challenge fl4t.us www.fl4t.us
yields
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "No registration exists matching provided key", "status": 403 }] (120 bytes)

and doesn't fix it - account key exists (not creating), domain key exists (not creating).

Removing the keys manually
# rm /usr/local/etc/acme/fl4t.us/privkey.pem
# rm /usr/local/etc/ssl/acme/private/fl4t.us/privkey.pem

and then

# acme-client -mvnFNC /usr/local/www/.well-known/acme-challenge fl4t.us www.fl4t.us

Does, which is a fine workaround, but doesn't script as easily. It might be nice to have an option, maybe -R, to force regeneration of keys.

First off, I finally found time to test out letskencrypt and I really like it! Awesome work. :)

Some thoughts:
I'd like to have one dedicated openbsd host running letskencrypt and let it handle certificates for all my mail and ubuntu web servers. Since the challenge is directly confirmed to LE as being ready right after it is written to disk, it is currently impossible to scp the challenge files to the ubuntu webhost before LE checks it and fails (although I love -t in the meantime ;)

If it would be possible to run an arbitrary shell command in between or maybe let -C support arguments like ssh://user@webserver:/srv/www/example.com/.well-known/acme-challenge, this setup would be possible. Another route might be to support dns-01.

These are just some first thoughts. I'm new to Let's Encrypt and I'd like to help with a patch if one of these features would make a chance on being incorporated.

Related to #14. (something different)

Since all certificates are issued by a 2048 bit intermediate certificate. Would it make sense to change the key size from 4096 to 2048 bits? Wouldn't this also make the initial handshake a bit faster?

For most web sites, security provided by 2,048-bit RSA keys is
sufficient. The RSA public key algorithm is widely supported, which
makes keys of this type a safe default choice. At 2,048 bits, such
keys provide about 112 bits of security. If you want more security
than this, note that RSA keys don't scale very well. To get 128 bits
of security, you need 3,072-bit RSA keys, which are noticeably slower.
ECDSA keys provide an alternative that offers better security and
better performance. At 256 bits, ECDSA keys provide 128 bits of
security.

From: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#11-use-2048-bit-private-keys

Version 0.1.16 fails to follow the 301 that results from trying to fetch http://cert.stg-int-x1.letsencrypt.org/

I only tried staging. It seems that production also has an http URL.

There is a changelog on the website, but none in the source repo or tarball.

Please add a file containing the changes to every version to the source repo.