ietf-wg-acme / acme Goto Github PK

The spec indicates that it’s possible to request certificates of types other than DER; however, there is no indication of what those MIME types are.

PEM would be a very useful format; would it be useful to indicate in here what that MIME type is, or at least where to find a list of MIME types that would work here?

As discussed in the thread about Karthik's analysis, we can have a fairly clean recovery story (assuming a MAC key can be provisioned. As a first step, we should reverse the order of the signatures in the roll-over request object.

OLD: Sign(K_old_priv, Sign(K_new_priv, Fingerprint(K_old_pub)))
NEW: Sign(K_new_priv, Sign(K_old_priv, Fingerprint(K_new_pub)))

SimpleHTTP is currently defined to use a path that ends in the token value from the challenge, e.g. .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA. Challenge responses are also required to have an empty Content-Type or 'application/jose+json`.

Since web servers commonly select a Content-Type based on file extension, and may set a default Content-Type for files with no extension, if would be useful to define an extension for the purpose. For instance, we could define the path to end in .jose.

Copied from: letsencrypt/acme-spec#242

As you (LE) seem to be strongly concerned over adding the option to adding the possibility to do the challange over alternate ports (some of which I are valid, but all of which can be handled in a secure way nonetheless - such as using a DNS record and other solutions to address have been already stated in here), I propose to add at least an alternate hostname for the http challange.

This would enable us to add a specific virtual host, answering to *.acme.invalid and redirect that to a specific wwhost, which can be used by the certbot to place the necessary files to complete the challange.

It is currently not possible to add global aliases in nginx for example, so this way it would be possible to issue certificates without having to either have certbot modify the nginx config (yes, it's possible to do that in a zero-downtime way, but it makes my sysadmin inner self scream - my software reconfiguring my other software...), or have to add the location redirect to all vhosts, which is not as easy as it sounds when they get generated by different software components.

If we'd say that the challange has to respond for the Host header of example.com.acme.invalid OR example.com (current) that would make all our lives easier, while maintaining a) backward compatibility b) ease of use for the average joe.

Not as easy as with a custom port, but still a lot more easy to automate.

Additional info:

kelunik commented 4 hours ago
@axos88 You can redirect /.well-known/acme-challenge/* to another (virtual) host at any time. The validation authority will follow any redirects. You could also use includes to define a common web root just for /.well-known/acme-challenge, that's what I usually do.

axos88 commented 2 hours ago • edited
As stated, this is not that easy to do when the server configuration is generated by different software components (chef cookbooks) that one does not have control over. Unfortunately there are no global aliases / redirects in nginx, only per server.

This would also mean that in order to use letsencrypt, one has to MODIFY the current configuration,

rather than ADD a new virtualhost declaration. Modifying something generated by some other actor is always a bad idea (this is one of the reasons conf.d directories exist btw).

axos88 commented 2 hours ago
For example: I have an automated installer for an web application, running over let's say ruby on rails. The application is obviously unaware, and should NEVER be aware how it's exposed to the internet. Thus it is unaware of how its SSL certificate is obtained and installed (normally it wouldn't even run on https, but would rely on a forward proxy to terminate the ssl connection, and forward it using http, but that's another matter).

Now my automated installer installs this software, and also installs and configures nginx for forward proxying. It will configure the nginx vhost, and other things that are needed. I don't know that LE exists, my installer just asks for the path to a certificate and a key.

Now I sell my software to a third party, who uses my installer (chef cookbook) to install my software on THEIR infrastructure. THEY are smarter then me, and know that LE exists, and want to use it to create the certs.

Current options:

They start hacking around the nginx configuration generated by my installer and add the alias - not good, the next update will overwrite their changes, and they won't be able to renew
They stop nginx every time they need to upgrade the certs for the duration of the verification - unacceptable
They use dns challenge if they can - usually it cannot be automated, or is a great effort to add dns records automatically.
They use the tls challenge (although it doesn't supprot nginx yet), and they modify its configuration during every verification, reloading its configuration, etc. Can easily create problems if someone is maintaining the server at the same time, etc.
OR: They also create a virtualhost accepting connections for *.acme.invalid once during installation, redirect it to a webroot, and have the verification client drop files into that webroot. Configure it once, and it works. Unnecessary to modify configuration files generated by other installers, unnecessary to keep reloading the nginx configuration all the time, less possibility for failure.

axos88 commented an hour ago
And let's face it, validation requests to a vhost have NOTHING to do with the software who serves the content on that server. They are intended for a totally different actor (certbot), thus they should be routed to a different vhost, not be mingled into all the other ones as locations and aliases, and such.

kelunik commented an hour ago
unnecessary to keep reloading the nginx configuration all the time
You have to do that anyway for Nginx to use the new certificate instead of the old one.

Anyway, this is something that should be in the official repository instead and on the ACME mailing list.

axos88 commented 3 minutes ago
unnecessary to keep reloading the nginx configuration all the time
You have to do that anyway for Nginx to use the new certificate instead of the old one.
True true, but at least you are not modifying configuration.

• The format should be specified more clearly, by reference to a couple of RFCs
• The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like github.com/letsencrypt/boulder), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.

Since we did not get consensus around #4, we should be explicit that HTTP is TCP port 80, and HTTPS is TCP port 443, and that holds for redirects as well.

The is pretty much a minor wording change only.

We need to clarify when an ACME server can ignore attributes in a request that it doesn't like, and when it should ignore them and proceed. For example, if a requested validity date is longer than the policy, should it error back or just ignore that attribute and issue a cert good for as long as it wants? That seems okay. But what about an unsupported request for issuance in the future? Ignoring that seems wrong, and risky.

We removed recovery in #108. If we refactor roll-over as proposed in #113, however, recovery can be done much more simply, at least if you assume the client is provisioned with a MAC key (possibly out of band).

NEW: Sign(K_new_priv, MAC(K_recovery, Fingerprint(K_new_pub)))

The idea here is that if the CA opts not to log the precertificates it has a mechanism for publishing the proofs that are associated with a cert.

At IETF 95, issue came up that supporting pre-ACME CAs would likely involve the need for payment. This is a stub issue to start discussion of how ACME might respond.

1. All of the Base64 strings are actually Base64 URL encoded
2. In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec.
3. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.

We need a challenge type to cover types of validation that can't be done automatically, in band to ACME. For example, a CA doing OV or EV validation might need the applicant to upload some documents through a web form. We should add a generic "out-of-band" challenge type that has a URL for a web site where the applicant gan go for instructions. I think the challenge object would look something like:

{
  "type": "out-of-band",
  "url": "https://example.com/papers-please"
}

There would be no response object; you just click the link, and when you complete the instructions there, the CA reflects this in the "status" field of the challenge object.

one of the problems of dns-01 is that it's hard to automate without giving up the complete control over the DNS to the LE server, meaning that important data like the password (or in case of "smarter" DNS solutions, an API key, which still has a lot of access) and especially in cases with strict security you might not want to automate everything because it's more transparent when you do the stuff yourself.
well let's cut the preamble and get to the point.
omne of the key annoyances (aside from using random challenges (see #88) is that you have to add a record for each and every domain, which means that e.g. for a 100 name SAN cert which are all under 1 domain you have to add and/or change a whole 100 records (and sign the whole stuff when using DNSSec)
aside from being annoying this the inefficient, seriously.
my idea would be (based on the currect TXT record structure:

_acme-challenge.x.y.example.com 120 IN TXT "9C0DqKC_4MkowIFByHhFaP8u0Zv4z7Wz2IHM91lTKec"

that the following will be used instead:

_acme-challenge.example.com 120 IN TXT "delegate 9C0DqKC_4MkowIFByHhFaP8u0Zv4z7Wz2IHM91lTKec"

combining this with #88 results in

_acme-challenge.example.com 120 IN TXT "delegate key h53FF1QB43DZTQleR4VQQCxl7UQu1AgNAErm791z3DO3lrNMqfbLWsLw80RLHximiAFyY+i8nySyo7LJsbjpaw"

with the order of the flags not mattering (key delegate and delegate key being treated as the same)
and when checking for example for x.y.example.com
it goes the follwing way:
check the challenge records for x.y.example.com, if a valid one is found, stop and mark as complete, if not continue
check the challenge records for y.example.com for delegation flagged ones, if valid, mark as complete, if not continue.
check exmaple.com for valid delegation challenges, if valid, mark as complete, if not STOP, because com is on PSL.

It seem like the only way to retrieve an existing registration object for a given key is to provoke an error by attempting to register again with the same key and read the Location from it.

If the server already has a registration object with the provided account key, then it MUST return a 409 (Conflict) response and provide the URI of that registration in a Location header field. This allows a client that has an account key but not the corresponding registration URI to recover the registration URI.

As a client library implementor, I would expect to 40x and 50x to not be recoverable. I think its strange that the only way to recover the registration object is by triggering an error.

Would it make sense to add an extra endpoint to simply retrieve the registration object?

Alternatively, I don't see any reason for the endpoint not to return 200 when already registered (instead of 201 when it create the registration) as opposed to a 409.

Also, the returned error type in boulder is Malformed, which does not make much sense to me since the request was not malformed. If its an expected behaviour to provoke an error to recover data from the response, the error type should be specify into the spec and unique so its can be recovered from easily.

Implementation in boulder here and initial discussion in the ruby acme-client.

See letsencrypt/acme-spec#33.

Webservers are already running on 443.

If the validation also requires using 443 that means that the admin has to take down their webserver to make port 443 available for the validation and then has to put their webserver back up.

Alternatively they could use something like HAProxy, but this puts more administrative burden on the user. (I consider myself a fairly knowledgable guy and it took me a few hours of experimentation to arrive at a working solution)

Also note that there are a number of ports available for IANA registration:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

It looks like port 4 is ripe for an RFC. And 6,8,10,12,14,16,26,28,30,32,34,36,40,60.

One of the available ports could be used in place of 443 for validation.

Or, to make it super simple, the client could request any port below 1024 (or even above it!) to be used for validation / registration.

https://ietf-wg-acme.github.io/acme/#account-key-roll-over does not detail what status code should be returned. I assume it should be a 202, in line with Registration update, but it needs specifying IMO.

See https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#identifier-authorization.

Is that example just bogus or what's the , 2 for? There are only two challenges, so it can't be an index there.

Using common load-balance / proxy software it isn't possible to complete the challenge.

Here's the use case:

Proxy / Frontend Server (running haproxy in this case) is not handling TLS itself, but fronting connection.

The box behind it begins the challenge process.

The challenge comes in as abc.xyz.acme.invalid

There's no way to tell to which server the challenge was intended to go, it goes to the default server, which cannot complete the challenge.

If the challenge is changed to the format abc.xyz.example.com.acme.invalid the proxy could match explicitly against *.example.com and *.example.com.acme.invalid and forward the request to the correct machine.

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#identifier-authorization

The challenge answer example is wrong, there has to be a keyAuthorization key and value, see HTTP challenge spec at the end of that document.

The documentation seems unclear as to how certificate “up” links are to handle the case of multiple intermediate certificates between root and the issued certificate. Are both certificates part of the payload of the “up” link? Does each “up” link whose payload is not a root certificate (or “last-before-root”) have its own “up” link?

Thank you!

As PHB noted in his presentation at IETF 95, the examples in the doc should indicate clearly the start and end of payload of the JWS object, e.g.:

OLD:
{
  "resource": "new-authz", 
  "identifier": { "type": "dns", "value": "example.org" }
} 
/* Signed as JWS */

NEW:
/* --- begin JWS-signed data --- */
{
  "resource": "new-authz", 
  "identifier": { "type": "dns", "value": "example.org" }
} 
/* --- end JWS-signed data --- */

I proposed on the mailing list to remove implicit renewal some time ago, and it received some support. Creating this issue to track it.

All discussion should be done on the mailing list.

Hi,

It would be highly helpful for to have an up-to-date rendering of branch master available as https://ietf-wg-acme.github.io/acme, especially since it is linked from README.md.

Since the Makefile template used has support for pushing to gh-pages, it should be enough (for instance) to:

1. generate a GitHub token with privilege to push to this specific repo;
2. encrypt GH_TOKEN=<the actual token> to travis' public key;
3. include the encrypted blob in .travis.yml, under env.secure;
4. sign this repository up with Travis CI for automated builds.

NOTE: This technically give Travis CI the ability to push to this repository, should they be dishonest.
NOTE: Using Travis CI is not a requirement, but it would probably be the easiest to setup.

The new-certificate transaction should allow the client to request a specific lifetime for a certificate. There is no mechanism in PKCS#10 for this, so it will probably have to be JSON in the message body.

There are a number of outstanding issues and activity on the official repository.

Rather than duplicating a new repository, it would serve the community well to have the ownership changed so that the ongoing discussion continues without any manual comment migration, double posting, and linking back and forth to hold a conversation.

See letsencrypt/acme-spec#33 (comment)

We need an issues list, labels, documents, etc :)

Hi,
In "Proof of Possession of a Prior Key" mode, how many prior keys do we need to remember to pass challenge? Is it enough to just remember the last key?

Thanks.

Authorization expiry should be a timestamp not a date, to allow for authorizations with very short expiry times.

All discussion should be done on the mailing list.

Contact information may have been misspelled during registration. Contact information such as phone numbers may also change.

https://acme-staging.api.letsencrypt.org/directory exposes only the new-reg endpoint and that endpoint doesn't accept updates, because it has to respond with 409 Conflict for already existing keys.

There should be a way to update that information.

See also https://community.letsencrypt.org/t/clarify-the-email-flag-requirements/2603/8?u=kelunik.

As far as I am aware there has been no explicit use case for this and Boulder explicitly disallows tel: URIs to be used.

mailto should be the only explicitly supported URI type in the spec and others should be left up to implementing CAs to document.

Within CA policy limits, of course.

The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects).

Terminology

"Since JSON is a text-based format, binary fields are Base64-encoded. For Base64 encoding, we use the variant defined in {{RFC7515}}. The important features of this encoding are (1) that it uses the URL-safe character set, and (2) that "=" padding characters are stripped."

DNS challenge

"The record provisioned to the DNS is the base64url encoding of this digest."

To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec.

Reference: letsencrypt/boulder#1295

Right now, in order to discover the CA's subscriber agreement, you have to create a new registration and get it back in a Link header. Since this is a static property of the CA, it should be possible to get it without taking any action. The directory is the natural place for it.

Looking at the current key-change mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now:

• It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key.
• Both signatures have to include the "nonce" parameter, so this request burns two nonces unnecessarily
• The server's JWS checking code now has to switch between validating one signature and two
• Lots of JWS implementations don't support multiple signatures
• If not for this, we could require the flattened JSON serialization
• You need a lot of duplication to deal with the copy/paste attacks (cf. #149).

(On the other hand, I like that both signatures cover the "url" parameter; reduces replayability.)

I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.

OLD:

{
  "payload": base64url({
    "key": /* New key in JWK form */
  }),
  "signatures": [{
    "protected": base64url({
      "alg": "ES256",
      "jwk": /* old key */,
      "nonce": "pq00v-D1KB0sReG4jFfqVg",
      "url": "https://example.com/acme/key-change"
    }),
    "signature": "XFvVbo9diBlIBvhE...UI62sNT6MZsCJpQo"
  }, {
    "protected": base64url({
      "alg": "ES256",
      "jwk": /* new key */,
      "nonce": "vYjyueEYhMjpVQHe_unw4g",
      "url": "https://example.com/acme/key-change"
    }),
    "signature": "q20gG1f1r9cD6tBM...a48h0CkP11tl5Doo"
  }]
}


NEW:

{
  "protected": base64url({
    "alg": "ES256",
    "jwk": /* old key in JWK form */,
    "nonce": "pq00v-D1KB0sReG4jFfqVg",
    "url": "https://example.com/acme/key-change"
  }),
  "payload": base64({
    "protected": base64url({
      "alg": "ES256",
      "jwk": /* new key in JWK form */,
      "url": "https://example.com/acme/key-change"
    }),
    "payload": base64url({
      "oldKey": /* old key in JWK form */
    }),
    "signature": "q20gG1f1r9cD6tBM...a48h0CkP11tl5Doo"
  }),
  "signature": "XFvVbo9diBlIBvhE...UI62sNT6MZsCJpQo"
}

It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).

Since the rest of the spec and protocol makes extensive use of JSON, when I was reading the spec the first time, I didn't know if the link relations were supposed to be JSON link relations like HAL or LinkedData.

The spec mentions "link relation" 6 times, but only one of them (the 2nd-to-last) makes explicit reference to RFC 5988 for web linking via HTTP Link header.

I see nothing in the spec about versioning the protocol.

Should there be information about this in the /directory endpoint, or perhaps a separate endpoint?

I've been curious what the Environment in "Automatic Certificate Management Environment" meant since the LE project first kicked off, and while I can come up with a few ideas, I wonder if it makes more sense to have the acronym stand for Automated Certificate Management and Exchange?

I'm sure I'm not the first one to suggest this, but I didn't see it in any of the comments or tickets, and I just wanted to throw it out there before the spec is finalized and ratified by the IETF.

Any reason for the inconsistent naming of the challenge types?

Specifically tls-sni-01 vs proofOfPossession-01

Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent.

I would personally avoid camelcase in that context since there is already a lot acronyms.

The current key-change mechanism has a potential copy/paste vulnerability. Karthik proposed on the list:

The safest design would be to have the JSON object include
the thumbprints of both the old and new keys and then sign it
with both the new and old keys.

That is, you need the full matrix of "X signs over Y" -- "new/old", "new/new", "old/old", "old/new" -- so that both sides explicitly agree to the (old, new) pair.

But the current design has only has "old/new" and "new/new". That raises a risk that if you got an "old/new" signature, you could copy/paste the "new/new" signature and get a valid key-change request.

As long as we have parallel signatures (cf. #148), we need to have both the old and new keys in the payloads.

Server side request forgery (SSRF) is possible through ACME when using http-01 because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL. Additionally, Boulder helpfully includes (part) of the HTTP body in the detail field of Unauthorized errors.

In theory, an HTTP GET of any URL is idempotent and won't actually affect anything. But, if the ACME server returns any part of the HTTP body in error messages (like Boulder does), an attacker could potentially read sensitive data from internal servers.

Typical targets for SSRF would be metadata services (like 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP interface of the server's stack (like the HTTP API of the RabbitMQ management plugin), or any other internal HTTP server on the server's private network.

Perhaps the IETF ACME protocol spec should acknowledge SSRF in its Security Considerations? One recommendation could be to not allow connections to internal network addresses. However, if someone wanted to use ACME for a private intranet CA, correct firewalling like that is much harder. The spec could also discourage including the HTTP body in an Unauthorized error's detail field. Or at least don't include the HTTP body if a redirect was followed.

Also, this is mostly mitigated by the actual implementation of Let's Encrypt and Boulder. Notably, only 128 characters (maxResponseSize) of the HTTP body are returned by Boulder. And it doesn't seem possible to get Let's Encrypt to access HTTP servers on any port other than 80 or 443, even with a port number specified in the redirect URL, which limits what an attacker could access.

(I reported this privately to [email protected] before creating this GitHub issue. This is not an issue for Let's Encrypt.)

Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account.

Something liike:

Post: /rotate-key
{
"key": { /* JWK key */ }
}

Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.

StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the StartSSL.com account that send this token to the email address used in the registration.
At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level.
After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL.
please add this a parameter to the ACME protocol, thanks.

We currently have two levels of out-of-band in the spec:

• Out-of-band requirements in the application object
• Out-of-band challenges

Should we get rid of the latter? Or is it useful to let CAs migrate their authorization tracking to ACME but not their domain validation?

As Karthik Bhargavan pointed out, there is a risk of requests being redirected to unexpected servers unless the client's request is somehow bound to the server. As discussed on the list, we should add the full URL for the request to the request object, not just the resource class.

OLD: { "resource": "new-authz", ... }
NEW: { "url": "https://example.com/acme/new-authz", ... }

Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

vs.

1. Dereference the URI using an HTTP or HTTPS GET request. If using HTTPS, the ACME server MUST ignore the certificate provided by the HTTPS server.

The HTTP spec doesn't seem to be consistent. And why does it have to be completed with HTTP? I honestly don't understand that.

It would be nice if it could be clarified whether "--agree-tos"-like switches that don't require the user to whitelist specific TOS versions are acceptable in ACME clients.

certbot has one.

On the other hand, the author of acmetool refuses to implement "--agree-tos"-like functionality without clarification in the spec, making it impossible to completely automate renewal with certbot. (hlandau/acmetool#200).

If it isn't acceptable then we have the absurd situation of the de-facto official client being out of spec.

(Note: I accidentally opened the issue against the wrong repo first (letsencrypt/acme-spec#241).)

it's a bit frustrating when you cannot properly automate the challenges for whatever reason, and when having to do a large SAN cert it gets even more annoying (e.g. having 14 SANs and then having to copypaste 14 file names AND contents from SSH to the text editor and saving each file just so you can get your cert.
my Idea would be to make an authorised_keys style file (e.g. .well-known/acme-challenge/le-keys.txt) which contains the authorised lets encrypt accounts for http-01 and

adding the key hashes to TXT records like
_acme-challenge.example.com 120 IN TXT "key h53FF1QB43DZTQleR4VQQCxl7UQu1AgNAErm791z3DO3lrNMqfbLWsLw80RLHximiAFyY+i8nySyo7LJsbjpaw"
making a SHA512 in base64 takes up 86 characters, so you could make the record start with
key and a space before the hash, so it would be able to recognize old and new hashes alike.

(you could also, for lower data consumption add the key hashes to the key-file instead of the whole keys).

I would say that Sha512 should be used for generating the keys. in General SHA2 is a good hash family and longer sizes makes finding collisions harder.

The main point of this challenge is that you can just copypaste the same file to all the webroots, which also makes it easier on the LE side since it doesnt have to generate challenges since all API requests have to be signed with the account key anyway. verify those with the key file/records and finish.

this issue can be combined with #89 for DNS-01 as described there.