The Manager now uses RFC 8555 implementation of Let's Encrypt by default.
Existing users need not do any manual upgrades. If you vendor
acme/autocert, it is enough to just rebuild your binaries at this CL.
If there's an account key stored in Manager's cache which has been used
with an earlier Let's Encrypt implementation (aka v1 or draft-02),
it will be automatically re-registered with the new endpoint.
One notable change is the CAServer from internal/acmetest was amended
to simulate a CA implementing RFC 8555, replacing draft-02.
Support for both RFC and draft-02 seemed too complicated and not worth
the benefits: the old pre-RFC bits will be removed from both acme and
acme/autocert packages at some point.
Fixesgolang/go#21081
Change-Id: Id530758ac612b1c20f9df51c4d10f770e5f41ecf
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/199520
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Client's FetchCert now requires to do the discovery before
fetching a cert from RFC 8555 compliant CA using POST-as-GET
requests.
Some tests initialized the client without providing a directory
metadata, making it do network roundtrips to the default CA.
This CL sets a non-nil directory metadata to prevent unnecessary
network roundtrips to an actual CA during tests.
Change-Id: Icaa6c2c2fd25ae8e5b1b44c6c3dafa246e6bdbb0
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/200637
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
While working on the RFC 8555 implementation for golang/go#21081,
I've been also manually verifying the functionality against
various CAs both draft-02 and RFC versions.
This does not of course replace automated tests
yet it might be useful to others.
It is not a _test.go file because the program may require
interactive user input for dns-01 challenge types and needs
to flush logs to stderr during its run.
Change-Id: Ia324b08b30308441cc0705648e30c0112b0fa0c8
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/194681
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>
The order based issuance flow is different from pre-authorization
in that users tell upfront which identifiers they want a future
certificate to contain and the CA responds with a set of authorizations
to satisfy.
Similar to pre-authorization where users start with Client's
Authorize method, fulfill challenges and then call GetAuthorization
or WaitAuthorization, the order based flow starts with AuthorizeOrder
and then GetOrder or WaitOrder.
Once all order authorizations are satisfied, users can call
CreateOrderCert, as opposed to the old CreateCert, and FetchCert as before.
The new method implementation and updates to the existing methods
is in golang.org/cl/194379.
More on order based flow can be found in
https://tools.ietf.org/html/rfc8555#section-7.4.
Updates golang/go#21081
Change-Id: I37c37203b50785d7681f65f815d7b19d9c15b96d
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/192779
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Previously, nonce values were fetched from Directory URL.
RFC8555 and some recent drafts provide specific URL to fetch
new nonce values from.
This CL makes the client always use new nonce URL when available
and fall back to the previous behavior otherwise.
Updates golang/go#21081
Change-Id: I6442004b01d46aa015c193ca4c80daa712b78790
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191603
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL is part of many to extend existing acme package
functionality to support RFC8555 without breaking existing users
of both this client package and CA implementations which haven't
caught up to the RFC spec.
Updates golang/go#21081
Change-Id: I20eb339ede019930c3482286cd13a3ba6f2b3cd6
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/182937
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
According to the [RFC 5280, section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6):
> ...
> When the subjectAltName extension contains a domain name system
> label, the domain name MUST be stored in the dNSName (an IA5String).
> The name MUST be in the "preferred name syntax", as specified by
> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
> [RFC1123]. Note that while uppercase and lowercase letters are
> allowed in domain names, no significance is attached to the case.
> ...
And the [RFC 1034, section 3.5](https://tools.ietf.org/html/rfc1034#section-3.5):
> ...
> Note that while upper and lower case letters are allowed in domain
> names, no significance is attached to the case. That is, two names with
> the same spelling but different case are to be treated as if identical.
> ...
We should return the same TLS certificate for both `example.com` and `EXAMPLE.COM`. But the `autocert.Manager.GetCertificate` treats the two as totally different, it signs and returns two different TLS certificates.
Moreover, now the `autocert.Manager.GetCertificate` and the `autocert.HostWhitelist` can only handle Punycode IDN. If the client sends a Unicode IDN to `autocert.Manager.GetCertificate` (cURL is doing this), the "Invalid character in DNS name" error will be triggered.
This PR corrects these problems by converting the host of the TLS certificate to be obtained to Punycode via `idna.Lookup.ToASCII`.
Change-Id: I993821b3a6ae532a53772e2db00524479ef111af
GitHub-Last-Rev: 6c12694574b6ac71a920da8a8bdb130c0b6e0272
GitHub-Pull-Request: golang/crypto#85
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/171997
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The change should reduce resource quota consumed by the client overall.
Instead of sending HEAD to an ACME resource URL to get a new nonce,
the Client will now try to fetch it from the Directory URL first
and only then from the ACME resource URL if the former fails.
This builds up on an abandoned https://golang.org/cl/34623,
only this time with a fallback to the original behaviour.
Change-Id: I6e75c0e524c4bc751f3a651b290c0ac2493e0628
Reviewed-on: https://go-review.googlesource.com/c/162057
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, only rsa.PrivateKey and ecdsa.PrivateKey are supported
when creating JWS signatures. However, it is unnecessarily limiting
because any crypto.Signer implementation can sign a digest
in the appropriate format.
This change uses key.Public() instead of type-asserting the private
key which allows for a custom crypto.Signer implementation.
For instance, a key stored in a hardware module where the latter
does the actual signing without the key ever leaving its boundaries.
Change-Id: Ie7930ea2ba8c49dde7107ff074ae34abec05bdb9
Reviewed-on: https://go-review.googlesource.com/c/145137
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
More informative error message enables HTTPS server configuration mistakes to be corrected quickly, since log files will now include the rejected hostname. If the hostname should be accepted, it can be added to the HostWhitelist Policy.
Fixesgolang/go#28345
Change-Id: I801c82f0d3b19bc34592c9cd0bce77f1b284d19d
GitHub-Last-Rev: 5dfe731d732d693f9bdd79c8a74efd30a2f56d0b
GitHub-Pull-Request: golang/crypto#63
Reviewed-on: https://go-review.googlesource.com/c/144337
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The timeNow package variable doesn't work well here: since the renewal
functionality spawns goroutines that invoke timeNow, once a test has
caused such goroutines to exist, another test can't fiddle with it
without the race detector triggering.
Instead, have a private member of Manager that the tests can set if they
need.
Change-Id: Iaf1a68d8efb84c9c5e2804aeb9cc6b2d3f3fef43
Reviewed-on: https://go-review.googlesource.com/128655
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Because tls.Config now requires more fields to be set
in order for tls-alpn to work, Manager provides a new
TLSConfig method for easier setup.
This CL also adds a new internal package for end-to-end tests.
The package implements a simple ACME CA server.
Fixesgolang/go#25013Fixesgolang/go#25901
Updates golang/go#17251
Change-Id: I2687ea8d5c445ddafad5ea2cdd36cd4e7d10bc86
Reviewed-on: https://go-review.googlesource.com/125495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ACME draft specifies the CA servers should respond
with 201 Created status code but Let's Encrypt
responds with 202 Accepted when creating a new account.
This change adds 202 Accepted as a valid response.
Otherwise, the Client hangs while doing retries,
discarding 202 responses as invalid.
Tests are not updated intentionally
due to this being non-conformant with the spec.
Fixesgolang/go#26251
Change-Id: I2918fce3873592c02e96f4118c4d1ecb42da3c4f
Reviewed-on: https://go-review.googlesource.com/125415
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>
To comply with the specification the value of the extension should be a ASN.1
OCTET STRING rather than a raw SHA 256 hash. This change uses asn1.Marshal to
wrap the hash before putting it in the extension.
Change-Id: I4ebe88a00238c6f928555d605e4b5dd98aad8128
Reviewed-on: https://go-review.googlesource.com/118696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A var isn't needed and a const is what the upstream (Go 1.10+) version
it's copying is.
Change-Id: I335270be3b3d09ac3c22cf6fb889a74ac39b8f1d
Reviewed-on: https://go-review.googlesource.com/116379
Reviewed-by: Filippo Valsorda <filippo@golang.org>
GetCertificate has all the information it needs to know if a client
supports ECDSA in ClientHelloInfo. Deprecate and ignore ForceRSA, and
just obtain a RSA certificate on the fly when a client that doesn't
support ECDSA connects.
This changes the cache key format to have a "+rsa" suffix for RSA
certificates. The default (ForceRSA = false) cache key is unchanged,
so most DirCache instances will still be valid. Caches created with
ForceRSA set will be silently ignored and certificates reissued.
The cache keys for HTTP tokens and the account key are changed to be
guaranteed not to overlap with valid domain names as well.
Note that ECDSA support detection is more strict in following RFC 5246
than crypto/tls, which ignores signature_algorithms.
Fixesgolang/go#22066
Change-Id: I70227747b563d6849cb693f83a950d57040b3f39
Reviewed-on: https://go-review.googlesource.com/114501
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
Fixes a bug introduced in golang.org/cl/100078 where incorrect
ACME client was used, causing nil pointer dereference.
The change also improves related tests,
removing code paths diverging in testing.
Fixesgolang/go#25581
Change-Id: I8c5531fcc5814a5a64f14911c0ad86c476a76d2f
Reviewed-on: https://go-review.googlesource.com/114817
Reviewed-by: Filippo Valsorda <filippo@golang.org>
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.
Fixesgolang/go#23426
Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Currently, the renewal flow will check the cache before renewing to make
sure it is actually necessary. This change modifies this flow to update
the local state so the cached cert is actually used by the manager.
Fixesgolang/go#22960
Change-Id: I16668e8098616190938ee52858294b59bc1a5160
Reviewed-on: https://go-review.googlesource.com/89995
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
"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>
The Manager now loops through known challenge types,
trying to fulfill one at a time until it succeeds or runs out
of supported challenges.
The provisioning of "http-01" challenges can be done
using the new Manager.HTTPHandler method.
It requires listening on unencrypted port 80.
Fixesgolang/go#21890
Change-Id: I55de9501f0069a9f460fedd8b5b0a09b94f9ef05
Reviewed-on: https://go-review.googlesource.com/87201
Run-TryBot: Alex Vaghin <ddos@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Per the description, the "-s" file issues slight simplifications to
the source code.
Change-Id: I77395d763f5eafb48653902dcedfa56b150b2d67
Reviewed-on: https://go-review.googlesource.com/80138
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>
If you don't use a cache you're just begging for Let's Encrypt
to ban you for a week due to duplicate certificate requests.
Don't encourage users to get banned.
Change-Id: Icf999c7f28817990bb45931d30692d4040c0ed71
Reviewed-on: https://go-review.googlesource.com/66550
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
Alex Vaghin
yuanhh
Filippo Valsorda
Aofei Sheng
Alex Vaghin
David Jones
David Ndungu
Adam Langley
Roland Shoemaker
Maciej Dębski
Brad Fitzpatrick
Leo Antunes
Brad Morgan
Jake Burkhead
Ingo Gottwald
Kevin Burke
Russ Cox
namusyaka
Joe Kyo