gheift / ght-acme.sh Goto Github PK

a linux shell script to sign certifactes by the letsencrypt CA

License: GNU General Public License v2.0

Shell 99.70% PHP 0.30%

ght-acme.sh's Introduction

letsencrypt.sh

This script is used to run the required steps to let letsencrypt sign a server certificate for certain domains.

For the most basic workflow an account key must be created and the private key of the server must be available. The following example is for a nginx server, because it is the easiest to setup.

Create an Account

letsencrypt needs an account key for verification of domains and requesting the signed certificate. If such a key already exists and is registered, the following steps can be skipped.

create an account key:

# umask 0177
# openssl genrsa -out account.key 4096
# umask 0022

# ./letsencrypt.sh register -a account.key -e [email protected]

Setup Challenge Response

To verify a domain the letsencrypt service gives you a challenge, to which a response must be stored under this domain.

The response is a simple concatenation of a challenge token, a dot ".", and the thumbprint of the account with which the verification request was made. This must be stored at a well known location.

The thumbprint of the private account key can be obtained with this command:

# ./letsencrypt.sh thumbprint -a account.key

With this thumbprint nginx can be configured to create a valid response dynamically. The following configuration must be added to the server section of each domain to be validated:

location ~ "^/\.well-known/acme-challenge/([-_a-zA-Z0-9]*)$" {
    default_type text/plain;
    return 200 "$1.ACCOUNT_THUMBPRINT";
}

The string ACCOUNT_THUMBPRINT in the return statement must be replaced by the actual thumbprint of the account key. Please note that the verification service of letsencrypt asks for the response over a HTTP and not over a HTTPS connection. Do not forget to reload the configuration.

Request a Signed Certificate

When every domain for which the certificate should be used is setup, the signing of the certificate can be requested:

# ./letsencrypt.sh sign -a account.key -k server.key -c server.pem www.example.org www1.example.org example.org

If the script runs successfully the signed certificate is stored in the file server.pem and can be used with the server. Please note that the file only contains the signed server certificate and not the complete chain, which might be needed by some servers.

Renew a Certificates

This is done like the first signing request:

# ./letsencrypt.sh sign -a account.key -k server.key -c server.pem www.example.org www1.example.org example.org

ght-acme.sh's People

Stargazers

Watchers

ght-acme.sh's Issues

default nginx HTTP config

here is my snip to catch all http and redirect to https:

server {
    listen 80;
    server_name _;

    location / {
        return 301 https://$host$request_uri;
    }
    location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ {
        default_type text/plain;
        return 200 "$1.ACCOUNT_THUMBPRINT";
        break;
    }
}

Simple man how to use it?

please!
it is not very obvious :)

challenge processing for Apache

I whipped up something similar to your idea from verification.md a couple of days ago, with php:

RewriteEngine on
RewriteRule ^/.well-known/acme-challenge/(.*)$ /acme-challenge.php?challenge=$1&thumbprint=<output of letsencrypt.sh thumbprint> [L,B]

acme-challenge.php:

<?php
print "$_GET[challenge].$_GET[thumbprint]"
?>

500 internal server error when adding key to account

When attempting to register my key with my account I get the following:
HTTP/1.1 100 Continue
Expires: Sat, 13 Feb 2016 15:24:35 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 500 Internal Server Error
Server: nginx
Content-Type: application/problem+json
Content-Length: 53
Replay-Nonce: XXXXX
Expires: Sat, 13 Feb 2016 15:24:36 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sat, 13 Feb 2016 15:24:36 GMT
Connection: close

{"type":"urn:acme:error:serverInternal","status":500}

Any ideas?

shift: can't shift that many

It seems that RESP_BODY content changed.

(Line 310)

DOMAIN_CHALLENGE="sed -e '/"http-01"/ ! d; s/.*{$[^}]*"type":"http-01"[^}]*$}.*/\1/' "$RESP_BODY""

But, if you see the content, there is a space: "type":(HERE)"http-01". The same applies to: DOMAIN_TOKEN and DOMAIN_URI

Which makes the regular expression to fail:

push response for "type":
./letsencrypt.sh: 374: shift: can't shift that many

help text expands empty variable

when executing ./letsencrypt.sh -h, the printed text is based on this line of source code:

$DOMAIN will be replaced by the actual domain

but $DOMAIN isn't set to anything, so it prints this:

 will be replaced by the actual domain

pkey: Invalid format "perm" for -inform

there is a typo in the command used to extract the public key from the private account key (used by the register action):

240c240
<     openssl pkey -inform perm -in "$1" -noout -text_pub > "$OPENSSL_OUT" 2> "$OPENSSL_ERR"
---
>     openssl pkey -inform pem -in "$1" -noout -text_pub > "$OPENSSL_OUT" 2> "$OPENSSL_ERR"

Bug: letsencrypt.sh does not produce valid domain validation key files and domains cannot be validated

letsencrypt.sh does not properly produce validation files that can be used to validate domains. The files contain an extra period that prevents them from being considered valid by Let's Encrypt. I tracked this behavior down to this:

a31ae66?diff=split

The change is on line 343.

mktemp on OS X

The mktemp on OS X runs uses a completely different syntax than the one on Ubuntu. Mac's mktemp should be invoked as: mktemp -t temp (to create a temporary file in $TMPDIR of temp.XXXXXXXX).

Possible solutions include:
*Detecting platform, and setting a $mktemp variable with mktemp or mktemp -t temp
*Using an or statement within the variable, like "mktemp || mktemp -t temp"
*Requiring that coreutils be installed on OS X and linking that directly on top of PATH to force standardization (probably not the best approach)

return code of register always 1

It looks like the return code of the register function is always 1:

root@default-ubuntu-1404:/etc/letsencrypt# /usr/local/bin/letsencrypt.sh register -a account.key -e [email protected] ; echo $?
register account
account already exists
1
root@default-ubuntu-1404:/etc/letsencrypt# rm account.key 
root@default-ubuntu-1404:/etc/letsencrypt# /usr/local/bin/letsencrypt.sh register -a account.key -e [email protected] ; echo $?
could not read account key
1
root@default-ubuntu-1404:/etc/letsencrypt# openssl genrsa -out account.key 4096 
Generating RSA private key, 4096 bit long modulus
..........................++
.....++
e is 65537 (0x10001)
root@default-ubuntu-1404:/etc/letsencrypt# /usr/local/bin/letsencrypt.sh register -a account.key -e [email protected] ; echo $?
register account
1
root@default-ubuntu-1404:/etc/letsencrypt#

Please return 0 in case of a success.

cannot register to own boulder

$ ./letsencrypt.sh register -a account.key -e whoami@hostname
register account
unhandled response while registering account

HTTP/1.1 100 Continue

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Replay-Nonce: dDPM-nki1i7RES9qx9bqT6HXQsSgFkrDxkKCCeyQKcI
Date: Fri, 03 Jun 2016 16:03:48 GMT
Content-Length: 98
Proxy-Connection: Keep-Alive
Connection: Keep-Alive

{
"type": "urn:acme:error:malformed",
"detail": "Invalid JWK in JWS header",
"status": 400
}

any idea?

on server:

I152516 boulder-wfe Successful request JSON={"ID":"c-3fcv86FZLlfakUNMFIM6laZCe7ZCORTG-9sz0Pgw","ClientAddr":"10.0.2.2:48858","Endpoint":"/directory","Method":"GET","RequestTime":"2016-06-03T15:25:16.237766088Z","ResponseTime":"2016-06-03T15:25:16.237826151Z","Errors":null,"ResponseNonce":"Prse64YNZu27chCjk5gdby_AcZXuUCrdVaCNMVQt9nE","UserAgent":"Mozilla/4.0 (compatible;)"}
I160348 boulder-wfe Successful request JSON={"ID":"r1cYrtKf-XtyK9OnHzUpStMw2OHPI4aTF9BO07OeFZw","ClientAddr":"10.0.2.2:19664","Endpoint":"/directory","Method":"GET","RequestTime":"2016-06-03T16:03:48.326484253Z","ResponseTime":"2016-06-03T16:03:48.326559876Z","Errors":null,"ResponseNonce":"Nhuib1b96fI-x-ndRuUX9OaJ5YzY9q-QwFJrJ9LQws","UserAgent":"curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5"}
I160348 boulder-wfe Terminated request JSON={"ID":"7Yaa2b0NcSPuebmHuADJfJW6jr5Nw875TDrnrKPAunI","ClientAddr":"10.0.2.2:19664","Endpoint":"/acme/new-reg","Method":"POST","RequestTime":"2016-06-03T16:03:48.464482662Z","ResponseTime":"2016-06-03T16:03:48.495169469Z","Errors":["invalid JWK in JWS signature header in POST body","400 :: urn:acme:error:malformed :: Invalid JWK in JWS header"],"ResponseNonce":"dDPM-nki1i7RES9qx9bqT6HXQsSgFkrDxkKCCeyQKcI","UserAgent":"curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5"}

"push response for "http-01"

./letsencrypt.sh sign -a account.key -k test.kbdnb.ru.key -c test.kbdnb.ru.pem test.kbdnb.ru www.test.kbdnb.ru

I get an endless output
push response for "http-01"
push response for "http-01"
push response for "http-01"
push response for "http-01"
and so on...

outdated agreement file

286c286
<     NEW_REG='{"resource":"new-reg","contact":["mailto:'"$ACCOUNT_EMAIL"'"],"agreement":"https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf"}'
---
>     NEW_REG='{"resource":"new-reg","contact":["mailto:'"$ACCOUNT_EMAIL"'"],"agreement":"https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"}'

Please rename project as it violates ISRG trademark

We (ISRG / Let's Encrypt) do not allow clients to use our service's name in their client name. We recommend you use the term "ACME" instead, in reference to the protocol. This is better because there are no trademark issues and the protocol is not specific to our CA so your client should work with other ACME-enabled CAs in the future.

I know this can be a pain but we have to insist that the name change. Thanks for understanding.

BUG# letsencrypt.sh register

Issue while registering account ike documented.
Output:

register account
unhandled response while registering account

HTTP/1.1 100 Continue
Expires: Thu, 02 Jun 2016 14:36:12 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 98
Replay-Nonce: 7FWDn2F7tB393-7umusDLD0VObciMtO6FjUUL2Rk8zE
Expires: Thu, 02 Jun 2016 14:36:12 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 02 Jun 2016 14:36:12 GMT
Connection: close

{
  "type": "urn:acme:error:malformed",
  "detail": "Invalid JWK in JWS header",
  "status": 400
}

I run thoose commands:

umask 0177
openssl genrsa -out account.key 4096
umask 0022

./letsencrypt.sh register -a account.key -e [email protected]

Any Ideas what could I change?

Thanks for your work an regards
Christian

Ways to get the server.key.

There is no introduction about the server.key mentioned in this script.

BUG: can't register account

./letsencrypt.sh register -a account.key -e [email protected]
register account
unhandled response while registering account

HTTP/1.1 100 Continue
Expires: Wed, 13 Jan 2016 17:08:15 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 500 Internal Server Error
Server: nginx
Content-Type: application/problem+json
Content-Length: 53
Replay-Nonce: utzWC8QTfMvi4dKG7KEgoQ-fq6DU7UuaA1tb-LtzI5U
Expires: Wed, 13 Jan 2016 17:08:15 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 13 Jan 2016 17:08:15 GMT
Connection: close

{"type":"urn:acme:error:serverInternal","status":500}

Autocreate chains?

or just write in readme where to get it.

nginx needs it.

Error at register

I try to run: ./letsencrypt.sh register -a account.key -e [email protected]

register account
unhandled response while registering account


HTTP/1.1 100 Continue
Expires: Fri, 03 Mar 2017 09:43:11 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 265
Boulder-Request-Id: G2ElsXVHE43YCI0wpYEEMjZDTTo37iYojAXWB-tjvNY
Replay-Nonce: IaWYF3D7FzSPwUFVQD6JwC40_UWZictg0T6YDx0Mj-8
Expires: Fri, 03 Mar 2017 09:43:11 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Fri, 03 Mar 2017 09:43:11 GMT
Connection: close

{
  "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
}

what should I do?

Signing error: "shift: can't shift that many"

# ./letsencrypt.sh sign -a account.key -k server.key -c server.pem example.com
generate certificate request
request challenge for example.com
push response for example.com
push response for "type":
push response for "type":
./letsencrypt.sh: 374: shift: can't shift that many