Disclaimer
The Let's Encrypt Client is BETA SOFTWARE. It contains plenty of bugs and rough edges, and should be tested thoroughly in staging environments before use on production systems.
For more information regarding the status of the project, please see https://letsencrypt.org. Be sure to checkout theFrequently Asked Questions (FAQ).
About the Let's Encrypt Client
The Let's Encrypt Client is a fully-featured, extensible client for the Let's Encrypt CA (or any other CA that speaks the ACMEprotocol) that can automate the tasks of obtaining certificates and configuring webservers to use them.
Installation
If
letsencrypt is packaged for your OS, you can install it from there, and run it by typing letsencrypt. Because not all operating systems have packages yet, we provide a temporary solution via the letsencrypt-auto wrapper script, which obtains some dependencies from your OS and puts others in a python virtual environment:user@webserver:~$ git clone https://github.com/letsencrypt/letsencrypt user@webserver:~$ cd letsencrypt user@webserver:~/letsencrypt$ ./letsencrypt-auto --help
Or for full command line help, type:
./letsencrypt-auto --help all
letsencrypt-auto updates to the latest client release automatically. And since letsencrypt-auto is a wrapper to letsencrypt, it accepts exactly the same command line flags and arguments. More details about this script and other installation methods can be found in the User Guide.How to run the client
In many cases, you can just run
letsencrypt-auto or letsencrypt, and the client will guide you through the process of obtaining and installing certs interactively.
You can also tell it exactly what you want it to do from the command line. For instance, if you want to obtain a cert for
thing.com, www.thing.com, and otherthing.net, using the Apache plugin to both obtain and install the certs, you could do this:./letsencrypt-auto --apache -d thing.com -d www.thing.com -d otherthing.net
(The first time you run the command, it will make an account, and ask for an email and agreement to the Let's Encrypt Subscriber Agreement; you can automate those with
--email and --agree-tos)
If you want to use a webserver that doesn't have full plugin support yet, you can still use "standalone" or "webroot" plugins to obtain a certificate:
./letsencrypt-auto certonly --standalone --email admin@thing.com -d thing.com -d www.thing.com -d otherthing.net
Understanding the client in more depth
To understand what the client is doing in detail, it's important to understand the way it uses plugins. Please see the explanation of plugins in the User Guide.
Links
Documentation: https://letsencrypt.readthedocs.org
Software project: https://github.com/letsencrypt/letsencrypt
Notes for developers: https://letsencrypt.readthedocs.org/en/latest/contributing.html
Main Website: https://letsencrypt.org/
IRC Channel: #letsencrypt on Freenode
Community: https://community.letsencrypt.org
Mailing list: client-dev (to subscribe without a Google account, send an email to client-dev+subscribe@letsencrypt.org)
System Requirements
The Let's Encrypt Client presently only runs on Unix-ish OSes that include Python 2.6 or 2.7; Python 3.x support will be added after the Public Beta launch. The client requires root access in order to write to
/etc/letsencrypt, /var/log/letsencrypt, /var/lib/letsencrypt; to bind to ports 80 and 443 (if you use the standalone plugin) and to read and modify webserver configurations (if you use the apache or nginx plugins). If none of these apply to you, it is theoretically possible to run without root privileges, but for most users who want to avoid running an ACME client as root, either letsencrypt-nosudo or simp_le are more appropriate choices.
The Apache plugin currently requires a Debian-based OS with augeas version 1.0; this includes Ubuntu 12.04+ and Debian 7+.
Current Features
- Supports multiple web servers:
- apache/2.x (working on Debian 8+ and Ubuntu 12.04+)
- standalone (runs its own simple webserver to prove you control a domain)
- webroot (adds files to webroot directories in order to prove control of domains and obtain certs)
- nginx/0.8.48+ (highly experimental, not included in letsencrypt-auto)
- The private key is generated locally on your system.
- Can talk to the Let's Encrypt CA or optionally to other ACME compliant services.
- Can get domain-validated (DV) certificates.
- Can revoke certificates.
- Adjustable RSA key bit-length (2048 (default), 4096, ...).
- Can optionally install a http -> https redirect, so your site effectively runs https only (Apache only)
- Fully automated.
- Configuration changes are logged and can be reverted.
- Supports ncurses and text (-t) UI, or can be driven entirely from the command line.
- Free and Open Source Software, made with Python.
from https://github.com/letsencrypt/letsencrypt
---------
此外还要验证域名所属，这一部分和传统的签发机构是一样的，不过传统的签发机构还允许我们使用域名whois中填写的邮箱来验证，而Letsencrypt貌似只能通过http challenge的方式来验证。即和验证服务器约定一个uri和随机字符串，验证服务器请求这一uri，如果得到的内容和约定的随机字符串相同，则验证通过。
这意味着我们得在每台部署https的前端的负载均衡服务器上都装一个letencrypt工具。有没有什么集中化管理的办法的呢？
实际上，由于challenge的uri的有规律，我们可以将前端服务器收到的这类请求代理到同一台专门用来签发、更新证书的服务器上.
当在服务器B上发起域名a.example.com新的签发请求后，Let’s Encrypt的签发服务器返回一个challange uri (8303)和response (ed98)。
服务器B使用webroot插件将这个uri和response写入本地磁盘上对应的文件。
Let’s Encrypt的签发服务器为了验证example.com的所属，查询到example.com指向前端服务器A，于是发送一个HTTP请求/.well-known/acme-challenge/8303到服务器A
服务器A反代这一请求到服务器B
B读取刚才第二步时写入到response，返回到A；A返回到Let’s Encrypt的签发服务器
验证成功，发证！
然后，我们只要从服务器A上取回存储在B上到证书就可以了。可以在B上做一个RESTful的api。注意要配置allow和deny。
A服务器（前端）的nginx配置如下：
server {
# 其他的location
# location { ..... }
location ~ /.well-known {
proxy_pass http://B.example.com:23333;
}
}
B服务器的nginx配置如下：
server {
listen 23333;
server_name B.example.com;
location ~ /.well-known {
root /tmp/letsencrypt;
allow IP-OF-A;
deny all;
}
}
然后在B上运行：
./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;
---------
Let’s Encrypt的集中化管理
Let’s Encrypt的证书签发原理实际上和传统的PKI一样，只不过自动化完成了生成CSR和私钥、提交CSR、取回证书的过程。此外还要验证域名所属，这一部分和传统的签发机构是一样的，不过传统的签发机构还允许我们使用域名whois中填写的邮箱来验证，而Letsencrypt貌似只能通过http challenge的方式来验证。即和验证服务器约定一个uri和随机字符串，验证服务器请求这一uri，如果得到的内容和约定的随机字符串相同，则验证通过。
这意味着我们得在每台部署https的前端的负载均衡服务器上都装一个letencrypt工具。有没有什么集中化管理的办法的呢？
实际上，由于challenge的uri的有规律，我们可以将前端服务器收到的这类请求代理到同一台专门用来签发、更新证书的服务器上.
当在服务器B上发起域名a.example.com新的签发请求后，Let’s Encrypt的签发服务器返回一个challange uri (8303)和response (ed98)。
服务器B使用webroot插件将这个uri和response写入本地磁盘上对应的文件。
Let’s Encrypt的签发服务器为了验证example.com的所属，查询到example.com指向前端服务器A，于是发送一个HTTP请求/.well-known/acme-challenge/8303到服务器A
服务器A反代这一请求到服务器B
B读取刚才第二步时写入到response，返回到A；A返回到Let’s Encrypt的签发服务器
验证成功，发证！
然后，我们只要从服务器A上取回存储在B上到证书就可以了。可以在B上做一个RESTful的api。注意要配置allow和deny。
A服务器（前端）的nginx配置如下：
server {
# 其他的location
# location { ..... }
location ~ /.well-known {
proxy_pass http://B.example.com:23333;
}
}
B服务器的nginx配置如下：
server {
listen 23333;
server_name B.example.com;
location ~ /.well-known {
root /tmp/letsencrypt;
allow IP-OF-A;
deny all;
}
}
然后在B上运行：
./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;