OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test
certificate and its CA cert that illustrate the problem are attached, as well
as the patch/workaround).
Here’s how the problem manifests itself:
$ openssl version -f
compiler: -I. -I.. -I../include -fPIC -fno-common
On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote:
OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test
certificate and its CA cert that illustrate the problem are attached, as well
as the patch/workaround).
Here’s how the problem manifests itself:
$
On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote:
OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test
certificate and its CA cert that illustrate the problem are attached, as well
as the patch/workaround).
Here’s how the problem manifests itself:
$
On Sun, Jan 18, 2015 at 04:08:38PM +0100, Daniel Kahn Gillmor via RT wrote:
this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l.
I haven't tested those version yet.
The change in behaviour seems to be this commit:
commit a8565530e27718760220df469f0a071c85b9e731
Author: Dr.
On Sun Jan 18 12:58:26 2015, u...@mit.edu wrote:
Probable cause: certificate decoder either fails to encode ASN.1 NULL
for signature algorithm parameters” when it should, or encodes an
explicit ASN.1 NULL when it shouldn’t. As a result, the comparison
code ASN1_TYPE_cmp in
I think it is not a regression, because the reported problem existed for as
long as crypto/asn1/a_type.c has been around in its current shape. This commit
in the 1.0.1k patch manifested (exposed) this problem, possibly for the first
time.
Yes I think Kurt is perfectly correct pointing at the
In the example you gave the signature and signatureAlgorithm fields in the
certificate don't match.
Well, technically you’re correct - but from semantic point of view, how
different is an empty list, and a list presented as ASN.1 NULL? Don’t we have
an empty list in both cases? And aren’t
