1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
package letsencrypt // import "rsc.io/letsencrypt"
Package letsencrypt obtains TLS certificates from LetsEncrypt.org.
LetsEncrypt.org is a service that issues free SSL/TLS certificates to
servers that can prove control over the given domain's DNS records or the
servers pointed at by those records.
Warning
Like any other random code you find on the internet, this package should not
be relied upon in important, production systems without thorough testing to
ensure that it meets your needs.
In the long term you should be using
https://golang.org/x/crypto/acme/autocert instead of this package. Send
improvements there, not here.
This is a package that I wrote for my own personal web sites (swtch.com,
rsc.io) in a hurry when my paid-for SSL certificate was expiring. It has no
tests, has barely been used, and there is some anecdotal evidence that it
does not properly renew certificates in a timely fashion, so servers that
run for more than 3 months may run into trouble. I don't run this code
anymore: to simplify maintenance, I moved the sites off of Ubuntu VMs and
onto Google App Engine, configured with inexpensive long-term certificates
purchased from cheapsslsecurity.com.
This package was interesting primarily as an example of how simple the API
for using LetsEncrypt.org could be made, in contrast to the low-level
implementations that existed at the time. In that respect, it helped inform
the design of the golang.org/x/crypto/acme/autocert package.
Quick Start
A complete HTTP/HTTPS web server using TLS certificates from
LetsEncrypt.org, redirecting all HTTP access to HTTPS, and maintaining TLS
certificates in a file letsencrypt.cache across server restarts.
package main
import (
"fmt"
"log"
"net/http"
"rsc.io/letsencrypt"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, TLS!\n")
})
var m letsencrypt.Manager
if err := m.CacheFile("letsencrypt.cache"); err != nil {
log.Fatal(err)
}
log.Fatal(m.Serve())
}
Overview
The fundamental type in this package is the Manager, which manages obtaining
and refreshing a collection of TLS certificates, typically for use by an
HTTPS server. The example above shows the most basic use of a Manager. The
use can be customized by calling additional methods of the Manager.
Registration
A Manager m registers anonymously with LetsEncrypt.org, including agreeing
to the letsencrypt.org terms of service, the first time it needs to obtain a
certificate. To register with a particular email address and with the option
of a prompt for agreement with the terms of service, call m.Register.
GetCertificate
The Manager's GetCertificate method returns certificates from the Manager's
cache, filling the cache by requesting certificates from LetsEncrypt.org. In
this way, a server with a tls.Config.GetCertificate set to m.GetCertificate
will demand load a certificate for any host name it serves. To force loading
of certificates ahead of time, install m.GetCertificate as before but then
call m.Cert for each host name.
A Manager can only obtain a certificate for a given host name if it can
prove control of that host name to LetsEncrypt.org. By default it proves
control by answering an HTTPS-based challenge: when the LetsEncrypt.org
servers connect to the named host on port 443 (HTTPS), the TLS SNI handshake
must use m.GetCertificate to obtain a per-host certificate. The most common
way to satisfy this requirement is for the host name to resolve to the IP
address of a (single) computer running m.ServeHTTPS, or at least running a
Go TLS server with tls.Config.GetCertificate set to m.GetCertificate.
However, other configurations are possible. For example, a group of machines
could use an implementation of tls.Config.GetCertificate that cached
certificates but handled cache misses by making RPCs to a Manager m on an
elected leader machine.
In typical usage, then, the setting of tls.Config.GetCertificate to
m.GetCertificate serves two purposes: it provides certificates to the TLS
server for ordinary serving, and it also answers challenges to prove
ownership of the domains in order to obtain those certificates.
To force the loading of a certificate for a given host into the Manager's
cache, use m.Cert.
Persistent Storage
If a server always starts with a zero Manager m, the server effectively
fetches a new certificate for each of its host name from LetsEncrypt.org on
each restart. This is unfortunate both because the server cannot start if
LetsEncrypt.org is unavailable and because LetsEncrypt.org limits how often
it will issue a certificate for a given host name (at time of writing, the
limit is 5 per week for a given host name). To save server state proactively
to a cache file and to reload the server state from that same file when
creating a new manager, call m.CacheFile with the name of the file to use.
For alternate storage uses, m.Marshal returns the current state of the
Manager as an opaque string, m.Unmarshal sets the state of the Manager using
a string previously returned by m.Marshal (usually a different m), and
m.Watch returns a channel that receives notifications about state changes.
Limits
To avoid hitting basic rate limits on LetsEncrypt.org, a given Manager
limits all its interactions to at most one request every minute, with an
initial allowed burst of 20 requests.
By default, if GetCertificate is asked for a certificate it does not have,
it will in turn ask LetsEncrypt.org for that certificate. This opens a
potential attack where attackers connect to a server by IP address and
pretend to be asking for an incorrect host name. Then GetCertificate will
attempt to obtain a certificate for that host, incorrectly, eventually
hitting LetsEncrypt.org's rate limit for certificate requests and making it
impossible to obtain actual certificates. Because servers hold certificates
for months at a time, however, an attack would need to be sustained over a
time period of at least a month in order to cause real problems.
To mitigate this kind of attack, a given Manager limits itself to an average
of one certificate request for a new host every three hours, with an initial
allowed burst of up to 20 requests. Long-running servers will therefore stay
within the LetsEncrypt.org limit of 300 failed requests per month.
Certificate refreshes are not subject to this limit.
To eliminate the attack entirely, call m.SetHosts to enumerate the exact set
of hosts that are allowed in certificate requests.
Web Servers
The basic requirement for use of a Manager is that there be an HTTPS server
running on port 443 and calling m.GetCertificate to obtain TLS certificates.
Using standard primitives, the way to do this is:
srv := &http.Server{
Addr: ":https",
TLSConfig: &tls.Config{
GetCertificate: m.GetCertificate,
},
}
srv.ListenAndServeTLS("", "")
However, this pattern of serving HTTPS with demand-loaded TLS certificates
comes up enough to wrap into a single method m.ServeHTTPS.
Similarly, many HTTPS servers prefer to redirect HTTP clients to the HTTPS
URLs. That functionality is provided by RedirectHTTP.
The combination of serving HTTPS with demand-loaded TLS certificates and
serving HTTPS redirects to HTTP clients is provided by m.Serve, as used in
the original example above.
func RedirectHTTP(w http.ResponseWriter, r *http.Request)
type Manager struct { ... }
|
