Without this, autocert will panic with an unhelpful nil pointer inside
the acme client.
Reorganized the test suite's ACME server stub creation, as I needed to
be able to stand up a test where GetCertificate was expected to fail.
Change-Id: Ie5e19c6e7766b4578c9b3c16789d7b27bd3be163
Reviewed-on: https://go-review.googlesource.com/40951
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
After receiving a badNonce error, the call can be safely retried. Nonce
errors can happen unexpectedly based on an unknown expiration date or
server-side changes. Rather than force the caller handle these errors,
retryPostJWS will keep retrying until success or a different error.
According to the spec, the error returned should be
"urn:ietf:params:acme:error:badNonce", but the error that Let's Encrypt
returns is "urn:acme:error:badNonce" so we just check the suffix.
Fixesgolang/go#19703
Change-Id: Id15012dff91e51d28ed8bc54f13a6212186cb7df
Reviewed-on: https://go-review.googlesource.com/40130
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
The ctxhttp package used to be big and gross before net/http supported
contexts natively. Nowadays it barely does anything. Stop using it,
because it just pulls in the old context package anyway. (We can't
really clean up the ctxhttp package until Go 1.9)
Change-Id: I48b11f2f483783a32cbaa75e244301148a304c08
Reviewed-on: https://go-review.googlesource.com/40110
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
A certificate must have the Server Auth Extended Key Usage to be used
for TLS, and an ECDSA certificate must have the Digital Signature Key
Usage to be used at all (you can't encrypt to an ECDSA key).
crypto/tls ignores (E)KUs when serving certificates, and most browsers
do as well, so it works, but OpenSSL would refuse to serve these
certificates, and clients would be allowed to reject them.
Change-Id: I699e58e613f01077e6b67fdb9e789d46e1672112
Reviewed-on: https://go-review.googlesource.com/39913
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
The standard library context package has been available since Go 1.7,
and the Go build dashboard (build.golang.org) only tests master and
the past two releases.
Also, the acme package makes no backwards compatibility guarantees,
not that I expect this to influence many people.
Change-Id: Ia1a294212e1e531f28f53cd954d4743a64611cab
Reviewed-on: https://go-review.googlesource.com/39272
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before this change, every JWS-signed request was preceded
by a HEAD request to fetch a fresh nonce.
The Client is now able to collect nonce values
from server responses and use them for future requests.
Additionally, this change also makes sure the client propagates
any error encountered during a fresh nonce fetch.
Fixesgolang/go#18428.
Change-Id: I33d21b450351cf4d98e72ee6c8fa654e9554bf92
Reviewed-on: https://go-review.googlesource.com/36514
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, autocert.Manager always generates EC-based certificates.
This change adds an optional field forcing the Manager to use RSA
instead.
An alternative idea, a "double" certificate, where the Manager
presents either RSA or EC certificate based on client's compatibility,
doesn't seem to be worth the implementation time given the constant
increase in Elliptic Curve cryptography.
Fixesgolang/go#17744
Change-Id: Idc68abfc698bcff4aad99715baefc06f8fae50ad
Reviewed-on: https://go-review.googlesource.com/34570
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If no key is provided in the *acme.Client, one is generated, but it
is not cached. This means that every restart of the server process
will use a new account.
This change caches the account key, if one is generated, so that
restarts of the server process use the same key.
Change-Id: I80f127b2cc79745a854b220b8918724ca228e87a
Reviewed-on: https://go-review.googlesource.com/28980
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
This change also gets the Manager closer to being able
to cleanup in short-lived HTTP servers running in a long-lived binary.
Change-Id: I49db36156896acc76d4757146c26b99e1665423b
Reviewed-on: https://go-review.googlesource.com/28491
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As with other methods of the Client, this is an implementation
for the v2 version of the spec.
Change-Id: I7fa7e0b700212992125de32524801048b56ac5d0
Reviewed-on: https://go-review.googlesource.com/28593
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The package was incorrectly importing both, x/net/context
and the new context packages.
This change makes autocert use only x/net/context to provide
compatibility with the older versions of Go.
Change-Id: I520efcaab9cbe919159e4671cee62335a6e107d9
Reviewed-on: https://go-review.googlesource.com/28299
Reviewed-by: Alex Vaghin <ddos@google.com>
A cert renewal loop is started when a certificate is fetched
from cache for the first time or a new one is created.
At most one renew loop is running per domain.
Closes#16851
Change-Id: I3d5821d8d76e9f2d9b551d0976ebc4cf91647092
Reviewed-on: https://go-review.googlesource.com/27611
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some systems can only operate with a certain key type, for instance RSA,
which makes it impossible for them to use Client provided certificates
to fulfill tls-sni-x challenges since TLSSNIxChallengeCert methods
of the Client always generate ECDSA-based certificates.
At the same time we want to keep using ECDSA-based certificates
in autocert.Manager.
This change allows for a user supplied key when generating tls-sni-x
challenge certficates.
Change-Id: I04f617ff99794a71ef23ad259cb333839f13ae1c
Reviewed-on: https://go-review.googlesource.com/27750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is quite often the case users need to poll an authorization until it
reaches a final state.
This change adds a handy method to do exactly that,
as well as updating autocert.Manager to use the new method.
Change-Id: I4d25e4ee751731815b77980caab6da98d3440b5d
Reviewed-on: https://go-review.googlesource.com/27431
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change improves tests speed further by switching to EC keys where
possible.
We are also switching to EC-based token certs for TLS-SNI-x challenges
in this change. I've confirmed it works with Let's Encrypt production
servers as well, by fulfilling TLS-SNI-01 challenge for a test domain
using autocert.Manager.
Change-Id: I07c532d535ba413af97463dd97cca3d650dfccee
Reviewed-on: https://go-review.googlesource.com/27439
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A previous change, https://go-review.googlesource.com/25462, added
support only for encoding JWK with a public ECDSA key.
Client users weren't actually able to make any request
using a EC key because of invalid JWS header and signature.
This change adds EC-based header and signature, which makes the Client
to have full support for ECDSA keys now.
Change-Id: Ia88f08465ce941f72d2001019f5aa47441a17d6e
Reviewed-on: https://go-review.googlesource.com/27438
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sanjay came up with this idea of a more flexible way
to place restrictions on the Manager using a HostPolicy hook
instead of the static DNSNames field.
HostPolicy allows for user-made custom policies,
as well as makes it possible to change the set of host names
dynamically, without restarting the Manager.
Change-Id: Ib7c6b047469edc6856b59c5e8365690e66f2a3a4
Reviewed-on: https://go-review.googlesource.com/27251
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes the tests run considerably faster on GOARCH=386
by reducing test RSA keys to 512-bit size.
It also increases GetCertificate test timeout to allow for slower
computations.
Change-Id: I7a27ffa5130f9ba08ee2069dad29aed74fa8c521
Reviewed-on: https://go-review.googlesource.com/27094
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes http-01 handling more consistent with tls-sni-* methods
and, hopefully, future implementation such as dns-01 and oob-01.
Change-Id: If1a4a47ee8528ef19960fee4e6860392c1813fe6
Reviewed-on: https://go-review.googlesource.com/27011
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Package autocert provides automatic access to certificates
from Let's Encrypt and any other ACME-based CA.
It is heavily based on the ideas from rsc.io/letsencrypt.
Change-Id: I62021452a918cd49093162f3d6c74e9d7f452fb8
Reviewed-on: https://go-review.googlesource.com/23970
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds a context to all exported methods of Client
which may perform network requests, to allow for easier control
over request timeouts and cancellation.
Change-Id: I635a4d7ad39a63ed9e6823b1af12fbb201c19647
Reviewed-on: https://go-review.googlesource.com/27091
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The latest ACME spec (v3) changed the wording to:
... the server MUST send one or more link relation header
fields [RFC5988] with relation "up", each indicating a single
certificate resource for the issuer of this certificate. The server
MAY also include the "up" links from these resources to enable the
client to build a full certificate chain.
See https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-6.3.1.
Before this change, Client was fetching only the first "up" link, but never
checked to follow the chain further. To my knowledge, Let's Encrypt never
provided a chain longer than 1, this is just to make the Client future proof.
Also fixesgoogle/acme#26.
Change-Id: I35cf5f1997b21a0b2a2d0a732043a7e04b7f1c45
Reviewed-on: https://go-review.googlesource.com/26693
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- move required fields before optional in the Client struct
- prefix all errors with "acme: "
- rename tos to tosURL (Terms of Service)
Change-Id: I6914b7e75d1e0559ff8303d390238c2a27145c8e
Reviewed-on: https://go-review.googlesource.com/27010
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Let's Encrypt has always provided Account URI in a response
to any registration request (new, get and update) in the Location
header, up until recently (?).
Today, LE's servers provide Account URI only for new-reg requests.
In fact, the spec does not say anything about Account URI and Location
header for "get" and "update" requests.
This change preserves Account URI in return values for "get" and "update"
requests, which is already provided by the caller anyway.
Change-Id: I8b1112d7443935715e9184a511b5e30a27008e8c
Reviewed-on: https://go-review.googlesource.com/26931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There's no need to PEM-encode key/cert pair to create a tls.Certificate.
All tls.X509KeyPair does is decode back to DER and verify that the
key corresponds to the cert. But we already know it does.
Change-Id: Icccdaf7fd86317147476fb03cbc71ee7b4a06edb
Reviewed-on: https://go-review.googlesource.com/26694
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Current and N-1 versions of the spec adopted TLS-SNI-02, but Let's
Encrypt seems to support TLS-SNI-01, devised in v1 of the spec.
This change implements both, older 01 and current 02 versions of TLS-SNI
challenges.
Change-Id: I2bb76ad852e105098f703cb6113d3996c0e0b118
Reviewed-on: https://go-review.googlesource.com/25450
Reviewed-by: Alex Vaghin <ddos@google.com>
The WG has recently published v3 of the spec.
The package implementation is still at v2. So is Let's Encrypt, to be
honest.
Regardless, I think it makes sense to point to the exact version
the package is compatible with.
Change-Id: Ibb3fc51aae363d72f67f7e876ef46c4f51c8da0b
Reviewed-on: https://go-review.googlesource.com/25451
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add Directory to the Client fields. This removes ACME resource URL
argument from almost all of the Client methods and makes it easier to
use.
Change-Id: I245c975fda914d50fe62ebbec55a4fcf34cb57f2
Reviewed-on: https://go-review.googlesource.com/23972
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Alex Vaghin
Ross Light
James Hartig
Brad Fitzpatrick
Filippo Valsorda
Heschi Kreinick
Andrew Gerrand
Jonathan Rudenberg
Anmol Sethi
Alex Vaghin