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>
Alex Vaghin
Anmol Sethi
Alex Vaghin