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>
Enables HTTP/2 on any servers used with the autocert listener
by setting "h2" in NextProtos of the listener *tls.Config.
Also adds a warning to the listener documentation that it
enables HTTP/2.
Fixesgolang/go#20572
Change-Id: If7c0f5722f0b1781789219fc4e84da3f19a89ab7
Reviewed-on: https://go-review.googlesource.com/45630
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change makes the Manager try creating a certificate
again, after a previously unsuccessful attempt.
The implementation is based on a timer, to prevent hitting
an ACME CA with too high QPS when under a heavy load.
The timer is hardcoded to 1 minute.
Fixesgolang/go#17740.
Change-Id: I46a49201cf423be3360633a89209d7b2bccc1d76
Reviewed-on: https://go-review.googlesource.com/41694
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A cached cert data may be corrupted or simply contain an expired
certificate, which results in GetCertificate returning an error.
This change makes the Manager ignore those invalid and expired
cache entries, treating them as nonexistent.
Fixesgolang/go#20035.
Change-Id: I5345291ecb1aab1cf19671cf0a383135c7102038
Reviewed-on: https://go-review.googlesource.com/41690
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>