[Acme] Mail regarding draft-ietf-acme-tls-alpn
Hi there, Having read through the draft spec, I have a concern over certificate renewals. As I read it, the server would have to temporarily use a customized self-signed certificate while the check is pending. Won't this mean any regular user connecting to that server over TLS at the time be presented with the self-signed certificate? This would manifest as downtime for the service. Is there a provision for renewal using this method? Thanks, Ben ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn
* As I read it, the server would have to temporarily use a customized self-signed certificate while the check is pending. If you renew before the current cert expires, that’s not an issue, right? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn
On Fri, May 25, 2018 at 08:09:01AM -0700, Ben Sykes wrote: > Hi there, > > Having read through the draft spec, I have a concern over certificate > renewals. > As I read it, the server would have to temporarily use a customized > self-signed certificate while the check is pending. Won't this mean any > regular user connecting to that server over TLS at the time be presented > with the self-signed certificate? This would manifest as downtime for the > service. > Is there a provision for renewal using this method? AFAIK, there is no way to construct a validation method that is all of: - Can be used by "public" CAs. - TLS-level. - Operates on port 443. - No downtime. - No special application or TLS library support required. TLS-ALPN fails the last line (if you do not have special application or TLS library support, you take downtime). I have cooked an experimental version of TLS library I have written, with the needed support to answer the validation queries with no downtime (also internally generating the needed certificate from name -> key authorization mapping). -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn
The validation certificate should only ever be served for requests that negotiate the amce-tls/1 application protocol, which browsers or equivalent user software should never do. This allows the server (or load balancer) to continue serving normal traffic to users while also serving validation traffic to the ACME server. > On May 25, 2018, at 8:09 AM, Ben Sykes > wrote: > > Hi there, > > Having read through the draft spec, I have a concern over certificate > renewals. > As I read it, the server would have to temporarily use a customized > self-signed certificate while the check is pending.. Won't this mean any > regular user connecting to that server over TLS at the time be presented with > the self-signed certificate? This would manifest as downtime for the service. > Is there a provision for renewal using this method? > > Thanks, > Ben > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-acme-12
On Fri, May 25, 2018 at 12:08 PM, Eric Rescorla wrote: > > > > IMPORTANT > > > S 6.2. > > > > algorithm in its "alg" field > > > > > > > > o The JWS Payload MUST NOT be detached > > > > o The JWS Protected Header MUST include the following fields: > > > > > > > > * "alg" (Algorithm) > > > > > > Do you want to specify a set of acceptable signature algorithms here? > > > > I am inclined not to. We have already forbidden "none" and MAC. We > > shouldn't specify "MUST"s here, because CABF sets their own list of > > required algorithms, and we don't want to conflict. I guess you > > could specify some MUST NOTs pretty safely, but given that they're > > already forbidden by CABF, it seems kind of duplicative. > > This is about the signatures that ACME accepts, not the signatures > in certs. Does CABF have a position on what signature algorithms > that ACME uses? > The Baseline Requirements do not establish any policies here regarding proof of key possession (which is not required, strictly speaking) or domain name validation methods, or on the authentication channel between the Applicant and CA. For example, 3.2.2.4.6 of the BRs (at time of writing, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf ) allow the use of MD2 or MD4 as part of their request token construction or within the use of CSRs. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-acme-12
On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara wrote: > On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote: > > [ Adding the mailing list ] > > > > > S 6.6. > > > > | > > | | > > > > | serverInternal | The server experienced an > > internal | > > > > | | > > error | > > > > | > > | | > > > > | tls | The server received a TLS error > > during | > > > > | | > > validation | > > > > > > Can you expand on what this means? Suppose instead I got a 500 during > > > validation? > > > > [[ EDIT - 272c754 ]] > > > > I think this goes back to when the TLS-SNI challenge. It's no longer > > relevant here, so I've removed it. The new TLS-based challenge can > re-add > > it if they need it. > > This is incorrect. It is neeed by HTTP-01 already, because that can > redirect to https://, which then tries to set up TLS, which can fail > even when the TCP connection succeeded. And given flakyness of > validation in general, one does not want misleading errors to make > things even harder. > Good point. I've backed out this change in my working copy. --Richard > > One of the more creative ones I have heard about is misconfigured > servers that interpret the TLS ClientHello as malformed HTTP request > and sends back HTTP 400 Bad Request, which the TLS client then tries > to parse as ServerHello and obviously chokes. This issue is apparently > not that rare, in fact, Let's Encrypt specifically checks for TLS > ServerHellos that look like HTTP replies. > > > -Ilari > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn
Ah ok. Got it. That's good. On Fri, May 25, 2018 at 11:07 AM Roland Shoemaker wrote: > The validation certificate should only ever be served for requests that > negotiate the amce-tls/1 application protocol, which browsers or equivalent > user software should never do. This allows the server (or load balancer) to > continue serving normal traffic to users while also serving validation > traffic to the ACME server. > > > On May 25, 2018, at 8:09 AM, Ben Sykes 40bensykes@dmarc.ietf.org> wrote: > > > > Hi there, > > > > Having read through the draft spec, I have a concern over certificate > renewals. > > As I read it, the server would have to temporarily use a customized > self-signed certificate while the check is pending.. Won't this mean any > regular user connecting to that server over TLS at the time be presented > with the self-signed certificate? This would manifest as downtime for the > service. > > Is there a provision for renewal using this method? > > > > Thanks, > > Ben > > ___ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme