On Mon, Jun 07, 2010 at 03:03:28PM +0100, David Woodhouse wrote:
> On Thu, 2010-06-03 at 21:35 -0400, Victor Duchovni wrote:
> > The problem is that only the application knows which names are those of
> > the peer it tried to reach.
>
> True, but the app could easily provide that information to
On Thu, 2010-06-03 at 21:35 -0400, Victor Duchovni wrote:
> The problem is that only the application knows which names are those of
> the peer it tried to reach.
True, but the app could easily provide that information to a library
function.
If you look at the 250 lines of code I referenced, almo
On Sat, Jun 05, 2010, jeff wrote:
> I did a little debugging and managed to fix on my end.
> The issue is now resolved. There's nothing wrong with OpenSSL1.0.0's
> handling of nameConstraints. It just Rocks!
>
Thank you for the update. When I wrote it it was checked against the RFC3280
complianc
I did a little debugging and managed to fix on my end.
The issue is now resolved. There's nothing wrong with OpenSSL1.0.0's
handling of nameConstraints. It just Rocks!
For those who might run into the same problem i'll explain more.
Debugging revealed the problem to be in the following area:
I tested this openssl 1.0.0. Error 34 is gone now but now error 47 shows
up which shows the name constraint is being applied. However, it's being
applied or verified in a way that I don't understand.
To show you I have simplified the test. Generating only one end
certificate and specifying one very
On Fri, Jun 04, 2010 at 03:50:21PM -0400, jeff wrote:
> yes it's 0.9.8
> I'll do a test with 1.0 before Monday and i'll let everyone know
The fact that 0.9.8 does NOT support checking name constraints was
mentioned multiple times in this thread. It is not polite to waste
list members' time in thi
yes it's 0.98
I'll do a test with 1.0 before Monday and i'll let everyone know
This email contains Morega Systems Inc. Privileged and Confidential information.
__
OpenSSL Project http://www.openss
On Fri, Jun 04, 2010, jeff wrote:
> I tried the following and it created more interesting results.
> It now fails on the good certificate -- the one that matches the
> nameConstraint.
> The error it returns is:
> error 34 at 1 depth lookup:unhandled critical extension
>
Are you using Open
On Fri, Jun 04, 2010 at 01:04:42PM -0400, jeff wrote:
> I tried the following and it created more interesting results.
> It now fails on the good certificate -- the one that matches the
> nameConstraint.
> The error it returns is:
> error 34 at 1 depth lookup:unhandled critical extension
>
I tried the following and it created more interesting results.
It now fails on the good certificate -- the one that matches the
nameConstraint.
The error it returns is:
error 34 at 1 depth lookup:unhandled critical extension
I revised the cnf file to make sure it didn't include the name
c
On Fri, Jun 04, 2010, Peter Sylvester wrote:
> On 06/03/2010 06:11 PM, Dr. Stephen Henson wrote:
>> On Thu, Jun 03, 2010, jeff wrote:
>>
>>
>>> I have an example, detailed below, that specifies permitted and excluded
>>> subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate
On 06/03/2010 06:11 PM, Dr. Stephen Henson wrote:
On Thu, Jun 03, 2010, jeff wrote:
I have an example, detailed below, that specifies permitted and excluded
subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate
requests adhering to and violating the name constraints both,
On Thu, Jun 03, 2010, jeff wrote:
> I will try to include complete attachments with examples.
>
> In the mean time I had to say that I was also told (aside from the one
> of the replies on this thread) that the enforcement of the constraints
> would be at the time of verification.
> Therefore I t
I will try to include complete attachments with examples.
In the mean time I had to say that I was also told (aside from the one
of the replies on this thread) that the enforcement of the constraints
would be at the time of verification.
Therefore I took the following steps to "verify" the produce
On Fri, Jun 04, 2010 at 01:19:52AM +0100, David Woodhouse wrote:
> On Thu, 2010-06-03 at 13:47 -0400, Victor Duchovni wrote:
> > Generally, OpenSSL does not verify peer names, only the certificate
> > trust chain, and peername checks are left up to applications.
>
> Which is a shame... I'm far to
On Thu, 2010-06-03 at 13:47 -0400, Victor Duchovni wrote:
> Generally, OpenSSL does not verify peer names, only the certificate
> trust chain, and peername checks are left up to applications.
Which is a shame... I'm far too stupid to be writing code like
http://git.infradead.org/users/dwmw2/openco
On Thu, Jun 03, 2010, Victor Duchovni wrote:
>
> Generally, OpenSSL does not verify peer names, only the certificate
> trust chain, and peername checks are left up to applications. Does
> OpenSSL trust chain validation include any checks on name constraints?
>
OpenSSL 1.0.0 does, sufficient to
On Thu, Jun 03, 2010 at 09:36:56AM -0400, jeff wrote:
> I have an example, detailed below, that specifies permitted and excluded
> subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate
> requests adhering to and violating the name constraints both, even
> though the nameConstrai
On Thu, Jun 03, 2010, jeff wrote:
> I have an example, detailed below, that specifies permitted and excluded
> subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate
> requests adhering to and violating the name constraints both, even
> though the nameConstraints are marked as cr
I have an example, detailed below, that specifies permitted and excluded
subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate
requests adhering to and violating the name constraints both, even
though the nameConstraints are marked as critical.
Is this OpenSSL misbehaving or did
20 matches
Mail list logo