On Fri May 29 05:40:51 2015, raysat...@yahoo.com wrote:
> On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
> > On Wed May 27 06:41:51 2015, raysat...@yahoo.com wrote:
> >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
> >>> Thank you very much for your work on this issue!
> >>> In my testing so fa
On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
> On Wed May 27 06:41:51 2015, raysat...@yahoo.com wrote:
>> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
>>> Thank you very much for your work on this issue!
>>> In my testing so far, it works as requested.
>>>
>>> I noticed the code changes in x5
On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
On Wed May 27 06:41:51 2015, raysat...@yahoo.com wrote:
On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
Thank you very much for your work on this issue!
In my testing so far, it works as requested.
I noticed the code changes in x509_vfy.c apply f
On Wed May 27 06:41:51 2015, raysat...@yahoo.com wrote:
> On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
> > Thank you very much for your work on this issue!
> > In my testing so far, it works as requested.
> >
> > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
> > stable b
On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
> Thank you very much for your work on this issue!
> In my testing so far, it works as requested.
>
> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
> stable branch, and the test suite succeeeds.
>
> Will you consider to add th
On 3/16/2015 5:45 AM, Kai Engert via RT wrote:
Thank you very much for your work on this issue!
In my testing so far, it works as requested.
I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
stable branch, and the test suite succeeeds.
Will you consider to add this enhance
On 16/03/15 09:45, Kai Engert via RT wrote:
> Thank you very much for your work on this issue!
> In my testing so far, it works as requested.
>
> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
> stable branch, and the test suite succeeeds.
>
> Will you consider to add t
Thank you very much for your work on this issue!
In my testing so far, it works as requested.
I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2
stable branch, and the test suite succeeeds.
Will you consider to add this enhancement in a feature release on the
1.0.2 branch?
R
Please see the following commits to master in relation to this issue:
da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b
The behaviour is now that openssl will attempt to build a trust chain as it did
previously. If that fails, it will then look to see if there is an alternative
chain that can be constr
On Tue, Dec 16, 2014 at 03:02:22PM +0100, Hubert Kario wrote:
> > DANE TLSA PKIX-TA(0) records can designate the digest of a trust
> > anchor selected by the server operator. When TLS server transmits
> > a corresponding certificate chain it may not be safe to replace
> > that chain with a shorte
As a warning, the Equifax root expires in August 2018 and hopefully will
removed from Mozilla soon. Right now GeoTrust is still promoting the use of
their GeoTrust to Equifax cross-certificate, and they do issue four year
certificates.
On Monday 15 December 2014 16:32:42 Viktor Dukhovni wrote:
> On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote:
> > > This can break DANE TLSA verification, because the site's designated
> > > trust anchor might no longer be in the shorter constructed chain.
> > >
> > > [Postfix not affec
On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote:
> > This can break DANE TLSA verification, because the site's designated
> > trust anchor might no longer be in the shorter constructed chain.
> >
> > [Postfix not affected]
>
> Please enlighten me how this case could be broken by this ch
On Po, 2014-12-15 at 14:48 +, Viktor Dukhovni wrote:
> On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote:
>
> > > For what it's worth, I have tested the Alexa top 1 million servers with
> > > the -
> > > trusted_first option and haven't found a single server that looses its
> > > tr
On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote:
> > For what it's worth, I have tested the Alexa top 1 million servers with the
> > -
> > trusted_first option and haven't found a single server that looses its
> > trusted
> > status, on the other hand, good few percent of servers do g
> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.
It's worth a great deal. Thanks! I love fact-based analysis. :)
> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.
It's worth a great deal. Thanks! I love fact-based analysis. :)
_
On Friday 05 December 2014 15:18:30 you wrote:
> When discussing this issue, my colleague Hubert Kario made me aware of a
> flag offered by e.g. the openssl s_client utility: "-trusted_first".
> When using -trusted_first, the server verification works successfully in
> the above scenario.
>
> Give
18 matches
Mail list logo
