"At Let's Encrypt, we are seeing clients in the wild that continue
polling their challenges long after those challenges have expired and
started serving 404."
The 4xx response code errors are client errors and should not be
retried.
Fixesgolang/go#24145
Change-Id: I012c584fc4defd3a0d64a653860c35705c5c6653
Reviewed-on: https://go-review.googlesource.com/97695
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is purely for debugging purposes, where an external system
may have a lookup mechanism based on Common Name.
Change-Id: I50b64ccf82e67fe8a0074a6f9b57e8cf102f1bb3
Reviewed-on: https://go-review.googlesource.com/71130
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@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>
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>
Alex Vaghin
Kevin Burke
namusyaka
Joe Kyo
James Hartig
Brad Fitzpatrick
Filippo Valsorda