On 12.01.18 04:06, Roland Bracewell Shoemaker wrote:
> I'm actually going to roll back my thoughts on the SNI value. Thinking
> about this more I think it does actually make sense to revert to using
> the actual host name here.
>
> In the initial design of the TLS-SNI challenge the
On 7/6/17 10:40 AM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> You think there should be a proprietary plug-in for any combination of
> DNS-provider <-> ACME-client?
The best case would be RFC 2138, but that's not something that can be
enforced.
> Creating DNS challenges on the fly makes
On 23/12/2016 19:20, DaKnOb wrote:
> Hello, this is my first e-mail in this list and after spending around
> 30 minutes in the archives I could not find this issue discussed
> previously. Excuse me if this is a double-post, and if it is, can you
> kindly help me find it in the archives?
This was
I wrote together some thoughts on this proposal here[1]. In short, I think it's
vulnerable to the default vhost attack that caused simpleHTTP to be dropped, and
it's not compatible with the "Agreed-Upon Change to Website" method described
in the BRs, which would prevent adoption by any
I have two concerns about this proposal.
First, there's a good chance that the vulnerability that caused SimpleHTTP to be
deprecated[1] would work. In short, if a multi-tenant hosting environment does
not set a default virtual host explicitly, commonly-used web server software
would pick the
On 14/10/16 18:53, Alan Doherty wrote:
> btw in http-01 the acme client can specify to the server whether to
> use http://www.domain1.com/.well-known/acme-challenge/ or
> https://www.domain1.com/.well-known/acme-challenge/ directly
>
> "The client’s response to this challenge indicates whether
On 26/07/16 23:03, Richard Barnes wrote:
> Option 2: copy/paste the "new-authz" flow back into the spec.
> However, that's a lot of spec machinery to re-import, and it doesn't
> allow the CA to express any sort of simplification due to multiple
> domain names, such as the "just validate the
On 26/07/16 18:00, Peter Bowen wrote:
> I don't see anything in the ACME specification that disallows this
> at the protocol level. I think a CA could request you validate a
> DNS identifier of 'example.com', then accept that authorization for
> the issuance of 'ship.example.com'. Conversely,
On 25/07/16 23:42, Alan Doherty wrote:
> its the sort of thing i think is not a case for acme having normal
> or short term certs but for acme to allow CA to provide fixed term
> certs
>
> provider/CA X can decide themselves to profit from your
> use-scenario by offering normal user acme api
It's worth pointing out that the latest draft of the domain validation
ballot[1] written by the CA/B Forum Validation WG set the authorization
lifetime at 39 months:
> Completed confirmations of Applicant authority may be valid for the
> issuance of multiple certificates over time. In all cases,
On 18/04/16 19:14, Albert ARIBAUD wrote:
> In the spec above, apparently nothing prevents the attacker from rolling
> over and over again, and the server will only be able to handle a
> finite number of keys before it either misfunctions or decides to drop
> the newest or oldest keys.
This can be
11 matches
Mail list logo
