When an order finalization response is not immediately valid,
Client.CreateOrderCert depends on the ACME server returning a Location
header. The header value is used as the URL for polling the updated
order status. RFC 8555 does not require this header, so CreateOrderCert
does not interoperate with ACME servers that omit it (e.g. Pebble
v2.9.0+).
This commit adds Client.CreateCertFromOrder, which accepts an *Order and
uses its URI for polling instead of relying on the finalization
response's Location header. It also updates existing callers and
documentation to use the new method and updates the integration tests to
Pebble v2.10.1 (the latest available version), which omits the
finalization Location header.
Fixesgolang/go#77704
Change-Id: I0852f19c5d18d6debc9c9686fa2c14a2e39663c2
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/817000
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@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>
Some systems can only operate with a certain key type, for instance RSA,
which makes it impossible for them to use Client provided certificates
to fulfill tls-sni-x challenges since TLSSNIxChallengeCert methods
of the Client always generate ECDSA-based certificates.
At the same time we want to keep using ECDSA-based certificates
in autocert.Manager.
This change allows for a user supplied key when generating tls-sni-x
challenge certficates.
Change-Id: I04f617ff99794a71ef23ad259cb333839f13ae1c
Reviewed-on: https://go-review.googlesource.com/27750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is quite often the case users need to poll an authorization until it
reaches a final state.
This change adds a handy method to do exactly that,
as well as updating autocert.Manager to use the new method.
Change-Id: I4d25e4ee751731815b77980caab6da98d3440b5d
Reviewed-on: https://go-review.googlesource.com/27431
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change improves tests speed further by switching to EC keys where
possible.
We are also switching to EC-based token certs for TLS-SNI-x challenges
in this change. I've confirmed it works with Let's Encrypt production
servers as well, by fulfilling TLS-SNI-01 challenge for a test domain
using autocert.Manager.
Change-Id: I07c532d535ba413af97463dd97cca3d650dfccee
Reviewed-on: https://go-review.googlesource.com/27439
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A previous change, https://go-review.googlesource.com/25462, added
support only for encoding JWK with a public ECDSA key.
Client users weren't actually able to make any request
using a EC key because of invalid JWS header and signature.
This change adds EC-based header and signature, which makes the Client
to have full support for ECDSA keys now.
Change-Id: Ia88f08465ce941f72d2001019f5aa47441a17d6e
Reviewed-on: https://go-review.googlesource.com/27438
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes http-01 handling more consistent with tls-sni-* methods
and, hopefully, future implementation such as dns-01 and oob-01.
Change-Id: If1a4a47ee8528ef19960fee4e6860392c1813fe6
Reviewed-on: https://go-review.googlesource.com/27011
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds a context to all exported methods of Client
which may perform network requests, to allow for easier control
over request timeouts and cancellation.
Change-Id: I635a4d7ad39a63ed9e6823b1af12fbb201c19647
Reviewed-on: https://go-review.googlesource.com/27091
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The latest ACME spec (v3) changed the wording to:
... the server MUST send one or more link relation header
fields [RFC5988] with relation "up", each indicating a single
certificate resource for the issuer of this certificate. The server
MAY also include the "up" links from these resources to enable the
client to build a full certificate chain.
See https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-6.3.1.
Before this change, Client was fetching only the first "up" link, but never
checked to follow the chain further. To my knowledge, Let's Encrypt never
provided a chain longer than 1, this is just to make the Client future proof.
Also fixesgoogle/acme#26.
Change-Id: I35cf5f1997b21a0b2a2d0a732043a7e04b7f1c45
Reviewed-on: https://go-review.googlesource.com/26693
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- move required fields before optional in the Client struct
- prefix all errors with "acme: "
- rename tos to tosURL (Terms of Service)
Change-Id: I6914b7e75d1e0559ff8303d390238c2a27145c8e
Reviewed-on: https://go-review.googlesource.com/27010
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Let's Encrypt has always provided Account URI in a response
to any registration request (new, get and update) in the Location
header, up until recently (?).
Today, LE's servers provide Account URI only for new-reg requests.
In fact, the spec does not say anything about Account URI and Location
header for "get" and "update" requests.
This change preserves Account URI in return values for "get" and "update"
requests, which is already provided by the caller anyway.
Change-Id: I8b1112d7443935715e9184a511b5e30a27008e8c
Reviewed-on: https://go-review.googlesource.com/26931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There's no need to PEM-encode key/cert pair to create a tls.Certificate.
All tls.X509KeyPair does is decode back to DER and verify that the
key corresponds to the cert. But we already know it does.
Change-Id: Icccdaf7fd86317147476fb03cbc71ee7b4a06edb
Reviewed-on: https://go-review.googlesource.com/26694
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Current and N-1 versions of the spec adopted TLS-SNI-02, but Let's
Encrypt seems to support TLS-SNI-01, devised in v1 of the spec.
This change implements both, older 01 and current 02 versions of TLS-SNI
challenges.
Change-Id: I2bb76ad852e105098f703cb6113d3996c0e0b118
Reviewed-on: https://go-review.googlesource.com/25450
Reviewed-by: Alex Vaghin <ddos@google.com>
The WG has recently published v3 of the spec.
The package implementation is still at v2. So is Let's Encrypt, to be
honest.
Regardless, I think it makes sense to point to the exact version
the package is compatible with.
Change-Id: Ibb3fc51aae363d72f67f7e876ef46c4f51c8da0b
Reviewed-on: https://go-review.googlesource.com/25451
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add Directory to the Client fields. This removes ACME resource URL
argument from almost all of the Client methods and makes it easier to
use.
Change-Id: I245c975fda914d50fe62ebbec55a4fcf34cb57f2
Reviewed-on: https://go-review.googlesource.com/23972
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Originated from github.com/google/goacme.
This does not include goacme command line program
github.com/google/goacme/cmd/goacme. It will probably live somewhere
else.
Change-Id: I852d55c1a3673fab208e6e2aa19d22be42b8719f
Reviewed-on: https://go-review.googlesource.com/20837
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Daniel McCarney
Russ Cox
Ben BurkertandBrad Fitzpatrick
Lars Lehtonen
Alex Vaghin
Alex Vaghin
Anmol Sethi
Alex Vaghin