acmesh-official/acme.sh

A pure Unix shell script implementing ACME client protocol

An ACME Shell script: acme.sh

• An ACME protocol client written purely in Shell (Unix shell) language.
• Full ACME protocol implementation.
• Support ECDSA certs
• Support SAN and wildcard certs
• Simple, powerful and very easy to use. You only need 3 minutes to learn it.
• Bash, dash and sh compatible.
• Purely written in Shell with no dependencies on python.
• Just one script to issue, renew and install your certificates automatically.
• DOES NOT require root/sudoer access.
• Docker ready
• IPv6 ready
• Cron job notifications for renewal or error etc.

It's probably the easiest & smartest shell script to automatically issue & renew the free certificates.

Wiki: https://github.com/acmesh-official/acme.sh/wiki

For Docker Fans: acme.sh 💕 Docker

Twitter: @neilpangxa

中文说明

Who:

• FreeBSD.org
• ruby-china.org
• Proxmox
• pfsense
• Loadbalancer.org
• discourse.org
• Centminmod
• splynx
• opnsense.org
• CentOS Web Panel
• lnmp.org
• more...

Tested OS

NO	Status	Platform
1		Mac OSX
2		Windows (cygwin with curl, openssl and crontab included)
3		FreeBSD
4		Solaris
5		Ubuntu
6	NA	pfsense
7		OpenBSD
8		NetBSD
9		DragonFlyBSD
10		Omnios
11		Debian
12		CentOS
13		openSUSE
14		Alpine Linux (with curl)
15		Archlinux
16		fedora
17		Kali Linux
18		Oracle Linux
19		Mageia
10		Gentoo Linux
11		ClearLinux
22	-----	Cloud Linux #111
23	-----	OpenWRT: Tested and working. See wiki page
24		Proxmox: See Proxmox VE Wiki. Version 4.x, 5.0, 5.1, version 5.2 and up

Check our testing project:

https://github.com/acmesh-official/acmetest

Supported CA

• ZeroSSL.com CA(default)
• Letsencrypt.org CA
• BuyPass.com CA
• SSL.com CA
• Google.com Public CA
• Pebble strict Mode
• Any other RFC8555-compliant CA

Supported modes

• Webroot mode
• Standalone mode
• Standalone tls-alpn mode
• Apache mode
• Nginx mode
• DNS mode
• DNS alias mode
• Stateless mode

1. How to install

1. Install online

Check this project: https://github.com/acmesh-official/get.acme.sh

curl https://get.acme.sh | sh -s [email protected]

Or:

wget -O -  https://get.acme.sh | sh -s [email protected]

2. Or, Install from git

Clone this project and launch installation:

git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install -m [email protected]

You don't have to be root then, although it is recommended.

Advanced Installation: https://github.com/acmesh-official/acme.sh/wiki/How-to-install

The installer will perform 3 actions:

1. Create and copy acme.sh to your home dir ($HOME): ~/.acme.sh/. All certs will be placed in this folder too.
2. Create alias for: acme.sh=~/.acme.sh/acme.sh.
3. Create daily cron job to check and renew the certs if needed.

Cron entry example:

0 0 * * * "/home/user/.acme.sh"/acme.sh --cron --home "/home/user/.acme.sh" > /dev/null

After the installation, you must close the current terminal and reopen it to make the alias take effect.

Ok, you are ready to issue certs now.

Show help message:

root@v1:~# acme.sh -h

2. Just issue a cert

Example 1: Single domain.

acme.sh --issue -d example.com -w /home/wwwroot/example.com

or:

acme.sh --issue -d example.com -w /home/username/public_html

or:

acme.sh --issue -d example.com -w /var/www/html

Example 2: Multiple domains in the same cert.

acme.sh --issue -d example.com -d www.example.com -d cp.example.com -w /home/wwwroot/example.com

The parameter /home/wwwroot/example.com or /home/username/public_html or /var/www/html is the web root folder where you host your website files. You MUST have write access to this folder.

Second argument "example.com" is the main domain you want to issue the cert for. You must have at least one domain there.

You must point and bind all the domains to the same webroot dir: /home/wwwroot/example.com.

The certs will be placed in ~/.acme.sh/example.com/

The certs will be renewed automatically every 60 days.

More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

3. Install the cert to Apache/Nginx etc.

After the cert is generated, you probably want to install/copy the cert to your Apache/Nginx or other servers. You MUST use this command to copy the certs to the target files, DO NOT use the certs files in ~/.acme.sh/ folder, they are for internal use only, the folder structure may change in the future.

Apache example:

acme.sh --install-cert -d example.com \
--cert-file      /path/to/certfile/in/apache/cert.pem  \
--key-file       /path/to/keyfile/in/apache/key.pem  \
--fullchain-file /path/to/fullchain/certfile/apache/fullchain.pem \
--reloadcmd     "service apache2 force-reload"

Nginx example:

acme.sh --install-cert -d example.com \
--key-file       /path/to/keyfile/in/nginx/key.pem  \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd     "service nginx force-reload"

Only the domain is required, all the other parameters are optional.

The ownership and permission info of existing files are preserved. You can pre-create the files to define the ownership and permission.

Install/copy the cert/key to the production Apache or Nginx path.

The cert will be renewed every 60 days by default (which is configurable). Once the cert is renewed, the Apache/Nginx service will be reloaded automatically by the command: service apache2 force-reload or service nginx force-reload.

Please take care: The reloadcmd is very important. The cert can be automatically renewed, but, without a correct 'reloadcmd' the cert may not be flushed to your server(like nginx or apache), then your website will not be able to show renewed cert in 60 days.

4. Use Standalone server to issue cert

(requires you to be root/sudoer or have permission to listen on port 80 (TCP))

Port 80 (TCP) MUST be free to listen on, otherwise you will be prompted to free it and try again.

acme.sh --issue --standalone -d example.com -d www.example.com -d cp.example.com

More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

5. Use Standalone ssl server to issue cert

(requires you to be root/sudoer or have permission to listen on port 443 (TCP))

Port 443 (TCP) MUST be free to listen on, otherwise you will be prompted to free it and try again.

acme.sh --issue --alpn -d example.com -d www.example.com -d cp.example.com

More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

6. Use Apache mode

(requires you to be root/sudoer, since it is required to interact with Apache server)

If you are running a web server, it is recommended to use the Webroot mode.

Particularly, if you are running an Apache server, you can use Apache mode instead. This mode doesn't write any files to your web root folder.

Just set string "apache" as the second argument and it will force use of apache plugin automatically.

acme.sh --issue --apache -d example.com -d www.example.com -d cp.example.com

This apache mode is only to issue the cert, it will not change your apache config files. You will need to configure your website config files to use the cert by yourself. We don't want to mess with your apache server, don't worry.

More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

7. Use Nginx mode

(requires you to be root/sudoer, since it is required to interact with Nginx server)

If you are running a web server, it is recommended to use the Webroot mode.

Particularly, if you are running an nginx server, you can use nginx mode instead. This mode doesn't write any files to your web root folder.

Just set string "nginx" as the second argument.

It will configure nginx server automatically to verify the domain and then restore the nginx config to the original version.

So, the config is not changed.

acme.sh --issue --nginx -d example.com -d www.example.com -d cp.example.com

This nginx mode is only to issue the cert, it will not change your nginx config files. You will need to configure your website config files to use the cert by yourself. We don't want to mess with your nginx server, don't worry.

More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

8. Automatic DNS API integration

If your DNS provider supports API access, we can use that API to automatically issue the certs.

You don't have to do anything manually!

Currently acme.sh supports most of the dns providers:

https://github.com/acmesh-official/acme.sh/wiki/dnsapi

9. Use DNS manual mode:

See: https://github.com/acmesh-official/acme.sh/wiki/dns-manual-mode first.

If your dns provider doesn't support any api access, you can add the txt record by hand.

acme.sh --issue --dns -d example.com -d www.example.com -d cp.example.com

You should get an output like below:

Add the following txt record:
Domain:_acme-challenge.example.com
Txt value:9ihDbjYfTExAYeDs4DBUeuTo18KBzwvTEjUnSwd32-c

Add the following txt record:
Domain:_acme-challenge.www.example.com
Txt value:9ihDbjxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Please add those txt records to the domains. Waiting for the dns to take effect.

Then just rerun with renew argument:

acme.sh --renew -d example.com

Ok, it's done.

Take care, this is dns manual mode, it can not be renewed automatically. you will have to add a new txt record to your domain by your hand when you renew your cert.

Please use dns api mode instead.

10. Issue ECC certificates

Just set the keylength parameter with a prefix ec-.

For example:

Single domain ECC certificate

acme.sh --issue -w /home/wwwroot/example.com -d example.com --keylength ec-256

SAN multi domain ECC certificate

acme.sh --issue -w /home/wwwroot/example.com -d example.com -d www.example.com --keylength ec-256

Please look at the keylength parameter above.

Valid values are:

1. ec-256 (prime256v1, "ECDSA P-256", which is the default key type)
2. ec-384 (secp384r1, "ECDSA P-384")
3. ec-521 (secp521r1, "ECDSA P-521", which is not supported by Let's Encrypt yet.)
4. 2048 (RSA2048)
5. 3072 (RSA3072)
6. 4096 (RSA4096)

11. Issue Wildcard certificates

It's simple, just give a wildcard domain as the -d parameter.

acme.sh  --issue -d example.com  -d '*.example.com'  --dns dns_cf

12. How to renew the certs

No, you don't need to renew the certs manually. All the certs will be renewed automatically every 60 days.

However, you can also force to renew a cert:

acme.sh --renew -d example.com --force

or, for ECC cert:

acme.sh --renew -d example.com --force --ecc

13. How to stop cert renewal

To stop renewal of a cert, you can execute the following to remove the cert from the renewal list:

acme.sh --remove -d example.com [--ecc]

The cert/key file is not removed from the disk.

You can remove the respective directory (e.g. ~/.acme.sh/example.com) by yourself.

14. How to upgrade acme.sh

acme.sh is in constant development, so it's strongly recommended to use the latest code.

You can update acme.sh to the latest code:

acme.sh --upgrade

You can also enable auto upgrade:

acme.sh --upgrade --auto-upgrade

Then acme.sh will be kept up to date automatically.

Disable auto upgrade:

acme.sh --upgrade --auto-upgrade 0

15. Issue a cert from an existing CSR

https://github.com/acmesh-official/acme.sh/wiki/Issue-a-cert-from-existing-CSR

16. Send notifications in cronjob

https://github.com/acmesh-official/acme.sh/wiki/notify

17. Under the Hood

Speak ACME language using shell, directly to "Let's Encrypt".

TODO:

18. Acknowledgments

1. Acme-tiny: https://github.com/diafygi/acme-tiny
2. ACME protocol: https://github.com/ietf-wg-acme/acme

Contributors

Code Contributors

This project exists thanks to all the people who contribute.

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

19. License & Others

License is GPLv3

Please Star and Fork me.

Issues and pull requests are welcome.

20. Donate

Your donation makes acme.sh better:

1. PayPal/Alipay(支付宝)/Wechat(微信): https://donate.acme.sh/

Donate List

acme.sh's Issues

Implement account registration update

as the default configuration of le.sh no email adress is used, some users might want to add/change their email later on to receive expiration notifications from let's encrypt. the ACME protocol allows updating the email adress assigned to the account. there's a post on let's encrypt's community which explains how updating an existing account would be done:

However, there's another good reason you might want to change the email address on an account: So that you get expiration emails. This is supported in the ACME protocol and in the Boulder software: POST a signed update to your account object (aka registration object) with a new value for the Contacts field. However, unfortunately this is not yet implemented in the Python client. We have an open issue for it: certbot/certbot#1215

maybe le.sh could provide an "updateAccount" function that takes the current ACCOUNT_EMAIL value and POSTs it to LE?

Centos

[root@s2 le]# le issue /data/wwwroot/xxxxx.com xxxxx.com www.xxxxx.com
Use default length 2048
Generating RSA private key, 2048 bit long modulus
................................................................................................................................+++
.........................................................................................+++
e is 65537 (0x10001)
Use default length 2048
Generating RSA private key, 2048 bit long modulus
.........................+++
......................................+++
e is 65537 (0x10001)
multi domain DNS:www.xxxxx.com
cat: /etc/ssl/openssl.cnf: No such file or directory
unable to find 'distinguished_name' in config
problems making Certificate Request
140032319231816:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=req name=distinguished_name
Registering account
Registered
verify each domain
Verifing domain xxxxx.com
verify error:xxxxx.com

---

[root@s2 le]# lsb_release -a
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.6 (Final)
Release: 6.6
Codename: Final

installcert() does not install cert

From reading the code, it looks like installcert() installs the CA and the key but not the cert file itself. Is it expected?

Standalone mode, nc -q 1 : bad argument

Hi,
I just tested the script in standalone mode and I encounter an error on line 227 and 229.
man nc (-q arg does not exist)
I removed it and the script works.

Add support for --user-agent flag

Possible to add support for the official client's --user-agent= ?

Check remaining validity before renewing

Scott posted this today, seems like it could be relevant to this : https://github.com/ScottHelme/Lets-Encrypt-Smart-Renew

setting Le_ReloadCmd

Hi just need some clarification of how to populate and set the Le_ReloadCmd flag from the below code

does that mean to set flag to say /usr/bin/ngxreload I would need use command for subdomain sub.a.com

le issue /path/to/webroot sub.a.com no 4096 no no no /usr/bin/ngxreload

??

issue() {
  if [ -z "$2" ] ; then
    _err "Usage: le  issue  webroot|no|apache|dns   a.com  [www.a.com,b.com,c.com]|no   [key-length]|no"
    return 1
  fi
  Le_Webroot="$1"
  Le_Domain="$2"
  Le_Alt="$3"
  Le_Keylength="$4"
  Le_RealCertPath="$5"
  Le_RealKeyPath="$6"
  Le_RealCACertPath="$7"
  Le_ReloadCmd="$8"

  _initpath $Le_Domain

  if [ -f "$DOMAIN_CONF" ] ; then
    Le_NextRenewTime=$(grep "^Le_NextRenewTime=" "$DOMAIN_CONF" | cut -d '=' -f 2)
    if [ -z "$FORCE" ] && [ "$Le_NextRenewTime" ] && [ "$(date -u "+%s" )" -lt "$Le_NextRenewTime" ] ; then 
      _info "Skip, Next renewal time is: $(grep "^Le_NextRenewTimeStr" "$DOMAIN_CONF" | cut -d '=' -f 2)"
      return 2
    fi
  fi

  if [ "$Le_Alt" == "no" ] ; then
    Le_Alt=""
  fi
  if [ "$Le_Keylength" == "no" ] ; then
    Le_Keylength=""
  fi
  if [ "$Le_RealCertPath" == "no" ] ; then
    Le_RealCertPath=""
  fi
  if [ "$Le_RealKeyPath" == "no" ] ; then
    Le_RealKeyPath=""
  fi
  if [ "$Le_RealCACertPath" == "no" ] ; then
    Le_RealCACertPath=""
  fi
  if [ "$Le_ReloadCmd" == "no" ] ; then
    Le_ReloadCmd=""
  fi

Certificate revocation should be supported

Thanks for this tool. I'm just testing it and found out there is no support for revoking certificates. I think something like that should be added.

I can't issue single domain ECC certificate

If i trying to create single domain certificate with ecc algorithm,
le issue /usr/share/nginx/html domain.tld ec-384
using this command, le sets ec-384 as a alternative name.
So it makes error.
How can I issue it?

Multi-domain doesn't seem to work anymore

I noticed that I could not get a certificate with aliases for a new domain as the verification fails with a 404 (it looks like the wrong file is requested, no corresponding file exists in the file system), while without aliases everything went fine.

In order to check if it could be repeated, I tried to force a renewal on another system for an existing certificate which also has an alias (www.rfc1149.net) in addition to the domain name (rfc1149.net). The original multi-domain certificate was acquired through le.sh on January 13:

% FORCE=1 ./le.sh renewAll
renewAll
renew rfc1149.net
Account key exists, skip
Generating RSA private key, 2048 bit long modulus
...........................................................+++
...............................................................................+++
e is 65537 (0x10001)
Multi domain=DNS:www.rfc1149.net
Registering account
Already registered
Verify each domain
Geting token for domain=rfc1149.net
Geting token for domain=www.rfc1149.net
Verifying:rfc1149.net
rfc1149.net:Verify error:Invalid response from http://rfc1149.net/.well-known/acme-challenge/NbFnzhCqKPH64xDvAlAM69p_udAz6sFy5wLMaCnDuTo [195.154.227.159]: 404

When I check, indeed, no file with this name is present, another one is:

% ls -l $SITEROOT/.well-known/acme-challenge/
-rw------- 1 sam users 87 Jan 22 19:15 A-xLbrJyK-Zq8cIHa2iMFYXUzj4QxS9L_AphO7UeErA

Is the multi-domain certificate acquisition broken?

In addition, the umask has been honoured, which is probably not a good idea, I'll open another issue for that.

签发失败

ew-authz error: {"type":"urn:acme:error:malformed","detail":"Error creating new authz :: DNS name does not have enough labels","status":400}
这个是什么原因导致的呢? 真心解决不了了. 还请帮忙解答, 非常感谢

Small change required to work with nc on CentOS 5

On Line 333, I had to make some small adjustments to the nc command so it would work with the native netcat on CentOS 5, basically just removing the -p and making sure _NC was set to "nc". It was an easy fix though, and thanks for such a handy utility.

333d332
< _NC="nc"
336c335
< echo -e -n "HTTP/1.1 200 OK\r\n\r\n$content" | $_NC -l $Le_HTTPPort -v
---
> echo -e -n "HTTP/1.1 200 OK\r\n\r\n$content" | $_NC -l -p $Le_HTTPPort -vv
338c337
< echo -e -n "HTTP/1.1 200 OK\r\n\r\n$content" | $_NC -l $Le_HTTPPort > /dev/null
---
> echo -e -n "HTTP/1.1 200 OK\r\n\r\n$content" | $_NC -l -p $Le_HTTPPort > /dev/null

Just want to say thanks

Sadly Github as far as I know has no way (other than giving you a star) of saying thanks!

We as a hosting company implemented Let's Encrypt using the official client, not only it has too many dependencies, but they basically removed some functionality that made it almost impossible to issue certificates for our customers.

Saw your script, gave it a test - works like charm! So I just wanted to say thanks on behalf of our company.

That also means we might actually be able to contribute! One nice feature (That I really like from the official client) is that you can define multiple web-roots - also if you want to create a SAN certificate this would be a great feature in this script, but I'll see if I can come up with a way to do it, and submit a pull request!

Command flag to switch between staging and live API servers?

Is the a command flag on le to switch between staging and live API servers ?

maybe support the --test-cert equivalent flag from letsencrypt official client ?

How to generate fullchain.pem in webroot mode?

DEBUG不要写到脚本里面好吧

现在 DEBUG 直接写在脚本里了，想这样：

DEBUG=1 le issue abc.com

都不行，还要每次去改脚本

nginx: [emerg] cannot get certificate

重启nginx的时候提示这个，是什么引起的？ 环境是 oneinstack 安装的
nginx: [emerg] cannot get certificate (SSL: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:Type=X509)
configuration file /usr/local/tengine/conf/nginx.conf test failed

下面是配置文件内容

server {
listen 443 ssl spdy;
ssl_certificate /root/.le/www.xxxxx.com/www.xxxxx.com.cer;
ssl_certificate_key /root/.le/www.xxxxx.com/www.xxxxx.com.key;
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!DSS:!PKS;
ssl_session_cache builtin:1000 shared:SSL:10m;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
server_name www.xxxxx.com xxxxx.com;
access_log /data/wwwlogs/www.xxxxx.com_nginx.log combined;
index index.html index.htm index.php;
root /data/wwwroot/www.xxxxx.com;
if ($host != www.xxxxx.com) {
rewrite ^/(.*)$ $scheme://www.xxxxx.com/$1 permanent;
}

location / {
try_files $uri @apache;
}
location @apache {
proxy_pass http://127.0.0.1:88;
include proxy.conf;
}
location ~ ..(php|php5|cgi|pl)?$ {
proxy_pass http://127.0.0.1:88;
include proxy.conf;
}
location ~ ..(gif|jpg|jpeg|png|bmp|swf|flv|ico)$ {
expires 30d;
access_log off;
}
location ~ .*.(js|css)?$ {
expires 7d;
access_log off;
}
}

Write default account.conf sample

Write a sample ~/.le/account.conf file when installed for the first time.

Write all the supported macros in it.
such as:

STAGE
DEBUG
FORCE
ACCOUNT_EMAIL
Le_RenewalDays
ACME_DIR
...

le issue fails unless there is service on port 80?

USAGE: ./le issue /var/www/hostname.sld.tld/htdocs hostname.sld.tld

Requires that I enable a Virtualhost listening on port 80 for hostname.sld.tld.

Must I have port 80 open and listening for that host or is there a way to allow everything to work on a server that is only serving over port 443?

If I use apache mode instead can I do this without having to expose port 80 and just listen on 443?

Also, I keep my certs in /etc/httpd/ssl/hostname.sld.tld/ and create symlinks to /root/.le/hostname.sld.tld/ for the certs and key, so can I just issue the following which installs the cronjob to renew by default every 80 days?:

le installcert hostname.sld.tld /root/.le/hostname.sld.tld/hostname.sld.tld.cer /root/.le/hostname.sld.tld/hostname.sld.tld.key /root/.le/hostname.sld.tld/ca.cer "/etc/rc.d/rc.httpd reload"

This would install the cronjob which renews and overwrites the /root/.le/hostname.sld.tld/hostname.sld.tld.cer - right?

If so, I'm thinking to add functionality for 'le issue...' or le issue apache...' to create the symlinks in the respective subdirectory under /etc/httpd/ssl// for the .key, ca.cer, and .cer files.

nginx reload not parsed correctly

I used this command to set everything up:

le issue /srv/acme domain.com www.domain.com 2048 /srv/domain.com/ssl/domain.com.chained.crt /srv/somain.com/ssl/domain.com.key "sudo /usr/sbin/service nginx reload"

/usr/sbin/service is set up for this user to be run with sudo without password.

However in the .le/domain.com/domain.com.conf file the following is set up:

Le_RealCACertPath="sudo"
Le_ReloadCmd="/usr/sbin/service"

The rest looks ok and i fixed these entries manually, so it is not a big deal for me, but maybe something that can be resolved in an update.

Also thank you for the work, this was the only solution i got working automated :D

ECDSA account key support

According to letsencrypt/boulder#1357, LE support ECDSA account key now, will you change to ECDSA ?

Should not skip regenerating CSR if SubjectAltNames have changed

First try with this script, I typoed a subdomain. I re-ran le issue blah and and it failed to regenerate the CSR, using the same typoed subdomain.

In fact, looking at the code it looks like even if you do FORCE=true le issue it won't regenerate the CSR, making it impossible to add SubjectAltNames to a certificate at a later date, which is something I do regularly with the official client.

I suggest either modifying the current $FORCE logic to force regenerating the entire configuration, or perhaps adding $REGEN_CSR and $REGEN_KEY flags to force regeneration of CSRs and keys. Either way, you have to modify the code in issue() to not clobber the provided arguments with those from $DOMAIN_CONF — or else require the use of le createCSR and le createDomainKey for regeneration, but that seems overly cumbersome.

FYI, pfsense doesn't work

[2.2.6-RELEASE][[email protected]]/root/le: bash ./le.sh issue /root/certs/ example.com o.example,e.example.com,s.example.com,j.example.com
Use default length 2048
Generating RSA private key, 2048 bit long modulus
................................+++
....+++
e is 65537 (0x10001)
Use default length 2048
Generating RSA private key, 2048 bit long modulus
.............................................+++
.........................................................................................+++
e is 65537 (0x10001)
Multi domain=DNS:o.example.com,DNS:e.example.com,DNS:s.example.com,DNS:j.example.com
error on line -1 of /dev/fd/63
675592508:error:02001002:system library:fopen:No such file or directory:/usr/pfSensesrc/src.RELENG_2_2/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:169:fopen('/dev/fd/63','rb')
675592508:error:2006D080:BIO routines:BIO_new_file:no such file:/usr/pfSensesrc/src.RELENG_2_2/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:172:
675592508:error:0E078072:configuration file routines:DEF_LOAD:no such file:/usr/pfSensesrc/src.RELENG_2_2/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_def.c:197:
Create CSR error.

Is there a rationale behind using "cp -p" instead of "mv"

in installcert? On some filesystems this return errors like
cp: preserving permissions for ‘/etc/pve/local/pve-ssl.pem.bak’: Function not implemented

no harm done and permissions are in fact preserved, but we all don't like error messages, are we?

I would wait with a PR after decision on #84 so there won't be merge conflicts

Apache 2.4 compatibility

You provide the option for apache integration, but you did a small but integral mistake which I was not aware too. The Apache 2.4 handles the permissions different.

Order allow,deny
Allow from all

Needs to been replaced by

Require all granted

Credits

Use openssl dgst -sha256 instead of openssl sha

Please use openssl dgst -sha256 instead of openssl sha.

openssl sha breaks support for libressl.

ACCOUNT_EMAIL ?

From looking at the code in le, to register an email address just do

only once at install ?
[email protected] le.sh install

or everytime when issuing a cert ?
[email protected] le issue

Add concatenation of site and CA certs for nginx

Hi!

As nginx requires that CA certificate should be concatenated with site ceritificate, please consider to change installcert to something like that:

  if [ "$Le_RealCertPath" ] ; then
    if [ -f "$Le_RealCertPath" ] ; then
      cp -p "$Le_RealCertPath" "$Le_RealCertPath".bak
    fi
    cat "$CERT_PATH" > "$Le_RealCertPath"
    if [[ "$Le_ReloadCmd" =~ "nginx" ]] ; then
      cat "$CA_CERT_PATH" >> "$Le_RealCertPath"
    fi
  fi

Not working on alpine linux

I just tried to run this on alpine linux, and I get the following error:

egrep: bad regex '{[^{]*"type":"http-01"[^}]*': Invalid contents of {}

用了cloudxns 的api ，结果并不能自动添加TXT记录。

Add the following TXT record:
Domain: _acme-challenge.xxx.com
TXT value: wP-0cCLJ2SKkhUdG2CVlR-GrX1hUKj3cK5EWxXbw2KA
Please be aware that you prepend _acme-challenge. before your domain
so the resulting subdomain will be: _acme-challenge.xxx.com
Please add the TXT records to the domains, and retry again.

.well-known/ removed after success?

Just throwing ideas:

I guess the .well-known/ should be deleted after a success validation, just to respect the original content.

Btw, I love this implementation! is the simplest and easiest from all that I checked.

cronjob typo ?

is this a typo ?

0 0 * * *  WORKING_DIR="/root/.le" "/root/.le"/le.sh cron > /dev/null

should be ?

0 0 * * *  WORKING_DIR="/root/.le" /root/.le/le.sh cron > /dev/null

Add support for tls-sni-01

I found some documentation for how us the tls-sni-01 challenge support to a client:

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md

In general simply changing the VTYPE_HTTP to "tls-sni-01" does all the proper steps but fails to verify with a poorly worded error. My understanding is that if the script where to add the proper subjectAlternativeName to a self signed cert and asking the user to install it before proceeding then it SHOULD world.

Support for AWS Route 53?

I wanted to check to see what your thoughts are in regards to the dnsapi plugins. I wrote a AWS Route 53 API plugin but it uses the python awscli tool and jq to parse JSON and I wasn't sure if you had strict requirements for using only bash or if 3rd party libraries could be a requirement. This probably needs some additional error checking but it's worked decently for me so far: https://gist.github.com/mbentley/d5da0bf962f050dd07ec

renew does not return correct error code

the return code of the issue function call within renew() is not caught, renewalways returns 0 even when an error during renewal happens (f.e. when signing fails due to hitting certs per domain & week limit).

Verify error:Error parsing key authorization file: Invalid key authorization: malformed token

Hi, I've posted my problem here:
https://community.letsencrypt.org/t/revoking-a-certificate-stupid-version/12305

Basically, I have the following error:
Verify error:Error parsing key authorization file: Invalid key authorization: malformed token

I'm using an url of type 123.456.789.123.xip.io

Do you know what's a token? Why is it malformed? How can I fix it?

Here is an excerpt of my (without DEBUG flag) output:

root@somewhere:~# le issue /home/path/www 123.456.789.123.xip.io www.123.456.789.123.xip.io 4096
Creating account key
Account key exists, skip
Creating domain key
Use length 4096
Creating csr
Multi domain=DNS:www.123.456.789.123.xip.io
Registering account
Already registered
Verify each domain
Getting token for domain=123.456.789.123.xip.io
Getting token for domain=www.123.456.789.123.xip.io
Verifying:123.456.789.123.xip.io
213.165.71.244.xip.io:Verify error:Error parsing key authorization file: Invalid key authorization: malformed token

Support Certificate Transparency

I'm thinking about if there is a way for us to submit the Certificate Transparency.

Private key file should not be readable for anyone

www-data@my-host:~/.le/my.host.com$ ls -lh
total 20K
-rw-r--r-- 1 www-data www-data 1.7K Jan 27 17:30 ca.cer
-rw-r--r-- 1 www-data www-data 2.1K Jan 27 17:30 my.host.com.cer
-rw-r--r-- 1 www-data www-data  487 Jan 27 17:30 my.host.com.conf
-rw-r--r-- 1 www-data www-data 1.6K Jan 27 17:30 my.host.com.csr
-rw-r--r-- 1 www-data www-data 3.2K Jan 27 17:30 my.host.com.key
    ^^^^^^ WTFFFFFF

Generated private key can be read by any user on this machine which is not secure.

Unclear commandline options

In the readme you explain the options:

[key-length]|no [cert-file-path]|no [key-file-path]|no

It seems they are optional. What happens if I write no ?? Are the certs not issued? Where are they saved?

Hardcoded command line order vs. getopts

I feel like we're getting to the limits of harcoded arguments (with no meaning default) vs. optional arguments. Wouldn't it be easier to give "-c certfile", "-C cafile", etc.? Especially when bash has a builtin getopts.

_initpath() calls sudo...

The _initpath() function calls sudo despite the "Do NOT require to be root/sudoer." comment on the 4th line of README.md.

This leads to spurious errors from cron jobs being sent to system administrators.

add dns-XXX-rm in dnsapi

Hi,

Would it be possible to add support to remove "_acme-challenge" TXT records after validation via DNSAPI?

Regrads
Frank

Support Godaddy domain api

Can anyone do me a favor to lend me a domain at godaddy ?

I don't have a domain there for testing.

distinguish ECC key based certificates from RSA certificates

currently when issuing a ECC key based certificate le.sh uses the same directory as for RSA key based certificates. as such it is not possible to issue both a RSA and a (separate) ECC cert for the same domain. maybe suffixing the key type to the directory for non-RSA certificates would be a futureproof fix for this:

RSA key certificate for example.com: $LE_WORKING_DIR/example.com/example.com.cer
ECC key certificate for example.com: $LE_WORKING_DIR/example.com-ecc/example.com.cer

Automatic CloudFlare DNS fails for Free plans?

Hey there!
I've been trying to automatize the process of renewing my certificates with le using the automatic CloudFlare API integration, I've tried with all my domains on my account, all of them are "Free plan" except for one that is "Pro plan", somehow it only works for the "Pro plan" one and the others end up in an Error without number.

Error
Error add txt for domain:_acme-challenge.example.com

The v4 API documentation states that creating and updating DNS records into a zone is available for all plans.
Did anyone experience something similar with Free plans?
I opened a support ticket with CloudFlare explaining the problem and I'll post the answer in here when I get one
.
Cheers!

Error message when hitting rate limit

when hitting the rate limits for certificates per domain & week, letsencrypt.org returns a 429 response. le.sh should handle it and inform the user. currently there's just an empty error message outputted:

...
Verifying:my.domain.org
Success
Verify finished, start to sign.
Sign failed:

the contents of curl.header is

HTTP/1.1 100 Continue
Expires: Fri, 05 Feb 2016 18:18:17 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 429 Unknown
Server: nginx
Content-Type: application/problem+json
Content-Length: 142
Replay-Nonce: LzW9_1jn3SFxJ7ypBRKdmVkn3M0ZW5dG1EVQZU_viD0
Expires: Fri, 05 Feb 2016 18:18:17 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Fri, 05 Feb 2016 18:18:17 GMT
Connection: close

the json body payload would contain the exact error message but is not shown:
{"type":"urn:acme:error:rateLimited","detail":"Error creating new cert :: Too many certificates already issued for: domain.org","status":429}

Support for Multiple Webroots

I currently run a letsencrypt-auto command like:

$ /opt/letsencrypt/letsencrypt-auto certonly \
--webroot --agree-tos --keep-until-expiring --rsa-key-size 4096 \
-w /srv/www/domain.com/public -d domain.com -d www.domain.com \
-w /srv/www/subdomain.domain.com/public -d subdomain.domain.com

It would be great to be able to request a single webroot cert for multiple webroots and groups of domain names.

Support Windows with cygwin

I just tested le on Windows.

It worked.

Make sure cygwin with openssl, curl and crontab installed.

Support ECDSA certificate

Support ECDSA certificate

ECDSA is in staging. We will support it soon.

Remove dependency to openssl

Yes, openssl is not reliable everywhere.

We should think about using other ssl implementations. Such as : GnuTls