Let's Encrypt is defaulting to a longer cross-signed chain on May 4th,
2021 but will offer the ability to download the shorter chain via an
alternate URL via a link header [1]. The shorter chain can be selected
to workaround a validation bug in legacy versions of OpenSSL, GnuTLS,
and LibreSSL. The alternate relation is described in section 7.4.2 of
RFC 8555.
ListCertAlternates should be passed the original certificate chain URL
and will return a list of alternate chain URLs that can be passed to
FetchCert to download.
Fixesgolang/go#42437
[1] https://community.letsencrypt.org/t/production-chain-changes/150739
Change-Id: Iaa32e49cb1322ac79ac1a5b4b7980d5401f4b86e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/277294
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
HMAC-SHA256 is a perfectly fine MAC algorithm, and there is no need to
ask the user to choose one.
This does break compatibility with the previous API, but it had been
live only for a weekend, so hopefully still in a window in which we can
make changes with a limited blast radius.
Updates golang/go#41430
Change-Id: I03741a545b25b9fcc147760cd20e9d7029844a6c
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/279453
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: James Kasten <jdkasten@google.com>
Reviewed-by: Roland Shoemaker <roland@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>
Roland Shoemaker
James Hartig
Filippo Valsorda
James KastenandJames Munnelly
Alex Vaghin