When methods that use POSTs are called on a acme.Client which has a
nil Key field it will cause a deadlock due to an infinite loop in
the code that looks up the account KID. This change adds a check for
the key being nil, and errors out if that is the case. Also adds a
test for this behavior.
Fixesgolang/go#38790
Change-Id: I65ff6bbbade7ed2d85306895904a976089730bbf
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/233164
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds RFC support to the existing methods which,
in conjunction with the new order based methods
implemented in golang.org/cl/192779, completes a Client
capable of obtaining certificates from RFC compliant CAs.
Updates golang/go#21081
Change-Id: I3aabc50928d3e4e49ee202eb6695135d5ad86821
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/194379
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Most important change in this CL is that Client is now able
to correctly format and sign requests in KID form with a valid
"kid" value.
According to the RFC, most requests must include KID field
in the protected head of JWS requests. The KID value is the account
identity provided by the CA during registration.
The KID value is also the Account URL. Hence, the CL is tied to
account management.
Updates golang/go#21081
Change-Id: I13f51e1fc52db7596eb933b47fa2014beb93c1ab
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191602
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC8555 requires that most requests contain "kid" field in the
protected header. The JWK version is still used for new account
creation and certificate revocation requests. Previously,
in earlier drafts JWK variant was used exclusively.
While JWK is computed based off the account public key,
the new "kid" field takes literal value of the Account URL
provided by the CA during a new registration. The actual support
for KID-based JWS requests in Client will be added in a follow up CL.
For what concerns the existing behaviour of JWS requests,
a new field "url" is added to the protected header.
Before:
{"alg":"...", "jwk":"...", "nonce":"..."}
After:
{"alg":"...", "jwk":"...", "nonce":"...", "url":"..."}
where the new field takes a value of the target request URL.
This still works for CAs supporting pre-RFC protocol versions.
Updates golang/go#21081
Change-Id: I460cfcd3dfdfe7fe3009a92a0a8a709fa07d0e7a
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191601
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The retry logic returns an "acme: no more retries for ..." error
in some cases, while *Error type in others.
This change makes retries always return the last error as received
from the CA server, if available. No change in returned values
of successful requests.
Change-Id: I3df2cb332a3e2739bba457c0ee50d7ca5bd836d9
Reviewed-on: https://go-review.googlesource.com/119975
Reviewed-by: Maciej Dębski <maciejd@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There's been some confusion about failed request retries.
Rightfully so: some requests are retried, others are not.
This change attempts to clarify the issue and unify backoff
usage in all Client's methods by introducing a new exported
optional field RetryBackoff and adding retry logic where missing.
Also, updates golang/go#22457.
Change-Id: Ied434edf998d52925a48b6b3b2407d45a6e9d2ee
Reviewed-on: https://go-review.googlesource.com/109615
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cuishuang
Filippo Valsorda
Axel Wagner
Roland Shoemaker
Alex Vaghin
Alex Vaghin