Subject Issuer Mismatch Bug!!

[Daniel Marschall]

Hello.

I have a problem with verification of certificates.

My command line is:

openssl verify -verbose -issuer_checks -crl_check_all -CAfile
tmp_cachain.pem daniel-marschall.crt

The tmp_cachain.pem file is a conclusion of all root and intermediate
certificates + their CRLs. (Mh... the trick with the CRL-appending was
never written in the manual, so I was thinking the certificates are
validated by downloading the CRL from the Internet)

The result is:

daniel-marschall.crt:
/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Developers/CN=Daniel
Marschall/emailAddress=info@...
error 29 at 0 depth lookup:subject issuer mismatch

/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Developers/CN=Daniel
Marschall/emailAddress=info@...
error 29 at 0 depth lookup:subject issuer mismatch

/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Developers/CN=Daniel
Marschall/emailAddress=info@...
error 29 at 0 depth lookup:subject issuer mismatch

/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Intermediate
Client Certificate Authority/CN=ViaThinkSoft Intermediate Client
Certificate Authority/emailAddress=certmaster@...
error 29 at 0 depth lookup:subject issuer mismatch

I noticed that I have the same problems as descripted here:
http://www.mail-archive.com/openssl-users@.../msg30729.html .

My commands for checking are:

openssl x509 -in ca_root/certs/cacert.crt -issuer -noout
openssl crl -in ca_root/crl/ca.pem -issuer -noout

The result is:

issuer= /C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Root
Certificate Signing Authority/CN=ViaThinkSoft Root Certificate Signing
Authority/emailAddress=certmaster@...

issuer=/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Root
Certificate Signing Authority/CN=ViaThinkSoft Root Certificate Signing
Authority/emailAddress=certmaster@...

Since the certificates are self-made, I am sure that there is no whitespace.

You can download the certificates and test it by your own here:

CRT: http://www.viathinksoft.de/ca/crt/root.crt
CRL: http://www.viathinksoft.de/ca/crl/root.crl

What can I do? I do want to have these subject tests too.

My OpenSSL version is OpenSSL 0.9.8c 05 Sep 2006.

Alas, I CANNOT change the openssl version since I already use the
latest stable of my debian system. The system administrator does not
allow me to enforce an update to an unstable version.

This bug with the whitespace also happens with Win32 OpenSSL OpenSSL
0.9.8h 28 May 2008. (the latest one I could find for Windows)

Regards
Daniel Marschall

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Sun, Oct 25, 2009, Daniel Marschall wrote:

> Hello.
>
> I have a problem with verification of certificates.
>
> My command line is:
>
> openssl verify -verbose -issuer_checks -crl_check_all -CAfile
> tmp_cachain.pem daniel-marschall.crt
>

Do you get an error without -issuer_checks? As the manual indicates that is a
debugging option that logs the verification process and for perfectly valid
chains you will get notifications of mismatches as candidate certificates are
discarded.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Daniel Marschall]

2009/10/25, Dr. Stephen Henson <steve@...>:

> On Sun, Oct 25, 2009, Daniel Marschall wrote:
>
> > Hello.
> >
> > I have a problem with verification of certificates.
> >
> > My command line is:
> >
> > openssl verify -verbose -issuer_checks -crl_check_all -CAfile
> > tmp_cachain.pem daniel-marschall.crt
> >
>
> Do you get an error without -issuer_checks? As the manual indicates that is a
> debugging option that logs the verification process and for perfectly valid
> chains you will get notifications of mismatches as candidate certificates are
> discarded.

Hello.

Thank you for your answer.

Yes, without that flag, the certificate is valid ("OK"). I know, that
the issuer-name-errors are actually not really errors, but warnings.
But I want to have a script which checks the certificate for
absolutely correctness, so I also want to check if the issuer names
are matching (without any manual checking). But because of this bug,
firstly noticed 2003, the strings of CRL issuer and Cert-PEM issuer
are not equal because OpenSSL adds a whitespace before /C= in the
issuername of the Cert-PEM. I wonder how to solve this bug. It was
found in 2003 or earlier and my 2006/2008 versions did also include
the same bug. Is it really not fixed until yet or am I wrong?

If you want, you can check my personal CRT/CRL's to validate the bug
(links in the inital mail). At both OpenSSL versions I use (0.9.8c and
0.9.8h) the whitespace is added.

But maybe my Root CA is wrong instead? Maybe my certificates are
'special' ;-) I cannot say because I only trust the "-issuer -noout"
output at the moment. The Root CA was also created with OpenSSL 0.9.8c
and in my CSR there was no whitespace before /C= (I made the request
via the paramters -batch and -subj '/C=DE/L=...' and not via manual
input)

CRT: http://www.viathinksoft.de/ca/crt/root.crt (issuer name has
whitespace before first "/")
CRL: http://www.viathinksoft.de/ca/crl/root.crl (issuer name is OK)

Do you know what's the reason (issuer-detection/verify or RootCA
fault?) for the bug and a workaround?

Regards
Daniel Marschall

>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Daniel Marschall]

Any idea? This problem exists since 2003 and noone found an answer -
this is unbelievable.

2009/10/26 Daniel Marschall <info@...>:

> 2009/10/25, Dr. Stephen Henson <steve@...>:
>> On Sun, Oct 25, 2009, Daniel Marschall wrote:
>>
>> > Hello.
>> >
>> > I have a problem with verification of certificates.
>> >
>> > My command line is:
>> >
>> > openssl verify -verbose -issuer_checks -crl_check_all -CAfile
>> > tmp_cachain.pem daniel-marschall.crt
>> >
>>
>> Do you get an error without -issuer_checks? As the manual indicates that is a
>> debugging option that logs the verification process and for perfectly valid
>> chains you will get notifications of mismatches as candidate certificates are
>> discarded.
>
>
> Hello.
>
> Thank you for your answer.
>
> Yes, without that flag, the certificate is valid ("OK"). I know, that
> the issuer-name-errors are actually not really errors, but warnings.
> But I want to have a script which checks the certificate for
> absolutely correctness, so I also want to check if the issuer names
> are matching (without any manual checking). But because of this bug,
> firstly noticed 2003, the strings of CRL issuer and Cert-PEM issuer
> are not equal because OpenSSL adds a whitespace before /C= in the
> issuername of the Cert-PEM. I wonder how to solve this bug. It was
> found in 2003 or earlier and my 2006/2008 versions did also include
> the same bug. Is it really not fixed until yet or am I wrong?
>
> If you want, you can check my personal CRT/CRL's to validate the bug
> (links in the inital mail). At both OpenSSL versions I use (0.9.8c and
> 0.9.8h) the whitespace is added.
>
> But maybe my Root CA is wrong instead? Maybe my certificates are
> 'special' ;-) I cannot say because I only trust the "-issuer -noout"
> output at the moment. The Root CA was also created with OpenSSL 0.9.8c
> and in my CSR there was no whitespace before /C= (I made the request
> via the paramters -batch and -subj '/C=DE/L=...' and not via manual
> input)
>
> CRT: http://www.viathinksoft.de/ca/crt/root.crt (issuer name has
> whitespace before first "/")
> CRL: http://www.viathinksoft.de/ca/crl/root.crl (issuer name is OK)
>
> Do you know what's the reason (issuer-detection/verify or RootCA
> fault?) for the bug and a workaround?
>
> Regards
> Daniel Marschall
>
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    openssl-users@...
>> Automated List Manager                           majordomo@...
>>
>
>
> --
> Daniel Marschall
> www.daniel-marschall.de
> [phone]
>

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Tue, Oct 27, 2009, Daniel Marschall wrote:

> Any idea? This problem exists since 2003 and noone found an answer -
> this is unbelievable.
>
> >
> > Yes, without that flag, the certificate is valid ("OK"). I know, that
> > the issuer-name-errors are actually not really errors, but warnings.
> > But I want to have a script which checks the certificate for
> > absolutely correctness, so I also want to check if the issuer names
> > are matching (without any manual checking). But because of this bug,
> > firstly noticed 2003, the strings of CRL issuer and Cert-PEM issuer
> > are not equal because OpenSSL adds a whitespace before /C= in the
> > issuername of the Cert-PEM. I wonder how to solve this bug. It was
> > found in 2003 or earlier and my 2006/2008 versions did also include
> > the same bug. Is it really not fixed until yet or am I wrong?
> >

They are not even warnings. They are notifications of how the verification
process is proceeding it is quite normal for a chain that is perfectly valid
in every way to output those notifications.

The textual output of the utilities was intended to be a human readable string
only and not used for actual comparison.  That "traditional" format is only
retained for compatibility and can produce both false positives and negatives.
Some other version such as he "oneline" form are better but not still don't
match the internal name comparison.

The actual name matching while important is nowhere near as important as the
cryptographic signature tests.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[JoelKatz]

Daniel Marschall wrote:

> Any idea? This problem exists since 2003 and noone found an answer -
> this is unbelievable.

If you're waiting for somebody else to find a bug in *your* code, you're
going to be waiting a long time.

Comparing the text strings for literal equality makes no logical sense
whatsoever and is unlikely to ever give a sensible result.

If you want to compare two things for "equality", you need to define
precisely what you mean by equality and implement a test for that exact
definition. The method you are using will never work right. Consider if one
certificate is issued to "Jack Smith\0 Jones" (where \0 is an embedded zero
byte). How can you possibly compare that to anything sensibly with a text
string compare?

You are expecting somebody else to magically make your senseless code work.
That's just not going to happen. You have to write sensible code.

Go back to the drawing board. Define *precisely* what you mean by equality.
And implement a test for exactly that.

DS



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Daniel Marschall]

Hello.

I am not searching bugs in my code. I have a certificate and a CRL.
And the functionality -issuer_checks is buggy. My cert and CRL have
exactky the same DN as issuer.

2009/10/28 David Schwartz <davids@...>:

> Daniel Marschall wrote:
>
>> Any idea? This problem exists since 2003 and noone found an answer -
>> this is unbelievable.
>
> If you're waiting for somebody else to find a bug in *your* code, you're
> going to be waiting a long time.
>
> Comparing the text strings for literal equality makes no logical sense
> whatsoever and is unlikely to ever give a sensible result.
>
> If you want to compare two things for "equality", you need to define
> precisely what you mean by equality and implement a test for that exact
> definition. The method you are using will never work right. Consider if one
> certificate is issued to "Jack Smith\0 Jones" (where \0 is an embedded zero
> byte). How can you possibly compare that to anything sensibly with a text
> string compare?
>
> You are expecting somebody else to magically make your senseless code work.
> That's just not going to happen. You have to write sensible code.
>
> Go back to the drawing board. Define *precisely* what you mean by equality.
> And implement a test for exactly that.
>
> DS
>
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[JoelKatz]

Daniel Marschall:

> Hello.
>
> I am not searching bugs in my code. I have a certificate and a CRL.
> And the functionality -issuer_checks is buggy. My cert and CRL have
> exactky the same DN as issuer.

What is the bug then? All you've reported so far is:

1) When you compare using exact string compares, you get nonsensical
results.

2) When you enable informational messages, you get accurate informational
messages.

DS



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Daniel Marschall]

2009/10/29 David Schwartz <davids@...>:

>
> Daniel Marschall:
>
>> Hello.
>>
>> I am not searching bugs in my code. I have a certificate and a CRL.
>> And the functionality -issuer_checks is buggy. My cert and CRL have
>> exactky the same DN as issuer.
>
> What is the bug then? All you've reported so far is:

Hello David,

>
> 1) When you compare using exact string compares, you get nonsensical
> results.

The string compare was just a manual check as desciped by Dr. Stephen
Henson in http://www.mail-archive.com/openssl-users@.../msg30722.html
. It actually isn't important if there is a whitespace or not, but I
personally think that might be the internal bug in -issuer_checks .

>
> 2) When you enable informational messages, you get accurate informational
> messages.

Please tell me, why it isn't a bug! I don't understand it. In my case
and also in the uncleared case of Helga Krause, the CRL was issued by
Person X and the CRT was also issued by Person X. "-issuer_checks"
should output nothing. But instead, it does tell me that the issuers
are different. But they are equal. So, it is a bug, isn't it?

>
> DS
>
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Fri, Oct 30, 2009, Daniel Marschall wrote:

>
> >
> > 2) When you enable informational messages, you get accurate informational
> > messages.
>
> Please tell me, why it isn't a bug! I don't understand it. In my case
> and also in the uncleared case of Helga Krause, the CRL was issued by
> Person X and the CRT was also issued by Person X. "-issuer_checks"
> should output nothing. But instead, it does tell me that the issuers
> are different. But they are equal. So, it is a bug, isn't it?
>

As I mentioned it is a diagnostic output. Let me give a simplified example.
Imagine you have a certificate x and three certificates which might be the
issuer A, B and C. Suppose C is the actual issuer.

Various checks are performed during the verification process.

Normally this will happen:

It will look at A and discard it for some reason.

It will look at B and discard it for some reason.

It will look at C, accept it and carry on.

This is just an example, it might see C first and never touch A and B.

Normally all this is invisible to the user and this output is never presented:
that's why the option is disabled by default.

Now imagine a second scenario where A, B and C are rejected. OpenSSL would
by default under these circumstances produce an error saying that the issuer
could not be found. This could be because it never looked up C or it saw C and
rejected it but with no indication why.

That's why the diagnostic option is there. If you enable it it will indicate
which certificates are examined and why they are rejected. So in the case of
an error it will say whether it saw C and why it didn't consider it to be a
valid issuer. It can't just output any reason why C is rejected because it
doesn't know that C is supposed to be the valid issuer so it indicates why all
candidate issuers are rejected.

So basically it's like this. If you don't include -issuer_checks and you get
OK then everything is fine. If you don't get OK and you think you should
because you feel a valid issuer should be visible the -issuer_checks might
be useful to see why it is failing.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Daniel Marschall]

2009/10/30 Dr. Stephen Henson <steve@...>:

> On Fri, Oct 30, 2009, Daniel Marschall wrote:
>
>>
>> >
>> > 2) When you enable informational messages, you get accurate informational
>> > messages.
>>
>> Please tell me, why it isn't a bug! I don't understand it. In my case
>> and also in the uncleared case of Helga Krause, the CRL was issued by
>> Person X and the CRT was also issued by Person X. "-issuer_checks"
>> should output nothing. But instead, it does tell me that the issuers
>> are different. But they are equal. So, it is a bug, isn't it?
>>
>
> As I mentioned it is a diagnostic output. Let me give a simplified example.
> Imagine you have a certificate x and three certificates which might be the
> issuer A, B and C. Suppose C is the actual issuer.
>
> Various checks are performed during the verification process.
>
> Normally this will happen:
>
> It will look at A and discard it for some reason.
>
> It will look at B and discard it for some reason.
>
> It will look at C, accept it and carry on.
>
> This is just an example, it might see C first and never touch A and B.
>
> Normally all this is invisible to the user and this output is never presented:
> that's why the option is disabled by default.
>
> Now imagine a second scenario where A, B and C are rejected. OpenSSL would
> by default under these circumstances produce an error saying that the issuer
> could not be found. This could be because it never looked up C or it saw C and
> rejected it but with no indication why.

Hello Steve.

Thank you for the detailed example, but I fear you missed the point. I
do not get an message that issuer C was not found or rejected. I get
the message "error 29 at 0 depth lookup:subject issuer mismatch"
without any other information:

"29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH: subject issuer mismatch - The
current candidate issuer certificate was rejected because its subject
name did not match the issuer name of the current certificate. Only
displayed when the -issuer_checks option is set."

I do not get the a message that the issuer could not be found or were
discarded/rejected/ignored.

My guess is that something like this happens: DN(Root-CRL) !=
DN(Root-CRT) => Error. But DN(Root-CRL) is not as it should be
(whitespace?). I don't know. Or is there another scenario why this
message should be shown if everything with the DN is made correctly?

>
> That's why the diagnostic option is there. If you enable it it will indicate
> which certificates are examined and why they are rejected. So in the case of
> an error it will say whether it saw C and why it didn't consider it to be a
> valid issuer. It can't just output any reason why C is rejected because it
> doesn't know that C is supposed to be the valid issuer so it indicates why all
> candidate issuers are rejected.
>
> So basically it's like this. If you don't include -issuer_checks and you get
> OK then everything is fine. If you don't get OK and you think you should
> because you feel a valid issuer should be visible the -issuer_checks might
> be useful to see why it is failing.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>

--
Daniel Marschall
www.daniel-marschall.de
[phone]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Fri, Oct 30, 2009, Daniel Marschall wrote:

> 2009/10/30 Dr. Stephen Henson <steve@...>:
> > On Fri, Oct 30, 2009, Daniel Marschall wrote:
> >
> >>
> >> >
> >> > 2) When you enable informational messages, you get accurate informational
> >> > messages.
> >>
> >> Please tell me, why it isn't a bug! I don't understand it. In my case
> >> and also in the uncleared case of Helga Krause, the CRL was issued by
> >> Person X and the CRT was also issued by Person X. "-issuer_checks"
> >> should output nothing. But instead, it does tell me that the issuers
> >> are different. But they are equal. So, it is a bug, isn't it?
> >>
> >
> > As I mentioned it is a diagnostic output. Let me give a simplified example.
> > Imagine you have a certificate x and three certificates which might be the
> > issuer A, B and C. Suppose C is the actual issuer.
> >
> > Various checks are performed during the verification process.
> >
> > Normally this will happen:
> >
> > It will look at A and discard it for some reason.
> >
> > It will look at B and discard it for some reason.
> >
> > It will look at C, accept it and carry on.
> >
> > This is just an example, it might see C first and never touch A and B.
> >
> > Normally all this is invisible to the user and this output is never presented:
> > that's why the option is disabled by default.
> >
> > Now imagine a second scenario where A, B and C are rejected. OpenSSL would
> > by default under these circumstances produce an error saying that the issuer
> > could not be found. This could be because it never looked up C or it saw C and
> > rejected it but with no indication why.
>
> Hello Steve.
>
> Thank you for the detailed example, but I fear you missed the point. I
> do not get an message that issuer C was not found or rejected. I get
> the message "error 29 at 0 depth lookup:subject issuer mismatch"
> without any other information:
>

Perhaps I should have expanded a little more. If you consider the first
example again:

It will look at A and discard it for some reason.

It will look at B and discard it for some reason.

It will look at C, accept it and carry on.

Now you don't get any error here and verification is fine. If however you set
-issuer_checks you get diagnostics relating to the rejection of A and B. The
verification still succeeds because C is later accepted but the verification
process doesn't know that at the time A and B are being tested.
 
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Fri, Oct 30, 2009, Dr. Stephen Henson wrote:

> On Fri, Oct 30, 2009, Daniel Marschall wrote:
>
> > 2009/10/30 Dr. Stephen Henson <steve@...>:
> > > On Fri, Oct 30, 2009, Daniel Marschall wrote:
> > >
> > >>
> > >> >
> > >> > 2) When you enable informational messages, you get accurate informational
> > >> > messages.
> > >>
> > >> Please tell me, why it isn't a bug! I don't understand it. In my case
> > >> and also in the uncleared case of Helga Krause, the CRL was issued by
> > >> Person X and the CRT was also issued by Person X. "-issuer_checks"
> > >> should output nothing. But instead, it does tell me that the issuers
> > >> are different. But they are equal. So, it is a bug, isn't it?
> > >>
> > >
> > > As I mentioned it is a diagnostic output. Let me give a simplified example.
> > > Imagine you have a certificate x and three certificates which might be the
> > > issuer A, B and C. Suppose C is the actual issuer.
> > >
> > > Various checks are performed during the verification process.
> > >
> > > Normally this will happen:
> > >
> > > It will look at A and discard it for some reason.
> > >
> > > It will look at B and discard it for some reason.
> > >
> > > It will look at C, accept it and carry on.
> > >
> > > This is just an example, it might see C first and never touch A and B.
> > >
> > > Normally all this is invisible to the user and this output is never presented:
> > > that's why the option is disabled by default.
> > >
> > > Now imagine a second scenario where A, B and C are rejected. OpenSSL would
> > > by default under these circumstances produce an error saying that the issuer
> > > could not be found. This could be because it never looked up C or it saw C and
> > > rejected it but with no indication why.
> >
> > Hello Steve.
> >
> > Thank you for the detailed example, but I fear you missed the point. I
> > do not get an message that issuer C was not found or rejected. I get
> > the message "error 29 at 0 depth lookup:subject issuer mismatch"
> > without any other information:
> >
>
> Perhaps I should have expanded a little more. If you consider the first
> example again:
>
> It will look at A and discard it for some reason.
>
> It will look at B and discard it for some reason.
>
> It will look at C, accept it and carry on.
>
> Now you don't get any error here and verification is fine. If however you set
> -issuer_checks you get diagnostics relating to the rejection of A and B. The
> verification still succeeds because C is later accepted but the verification
> process doesn't know that at the time A and B are being tested.
>  

Though looking at the callback code it would be better if it outputted details
of the candidate issuer certificates in that case as well so it was clearer
what it was doing. I'll add something to do that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Peter Sylvester-3]

We have in apps/

in x509.c

                print_name(STDout, "issuer= ",
                    X509_get_issuer_name(x), nmflag);

in crl.c

                print_name(bio_out, "issuer=", X509_CRL_get_issuer(x),
nmflag);

In order to make a fair change that will potentially hurt everyone, I
propose
to remove one space and add a blank before the =  and change "issuer"
to some parameter value but take it into account only when there
is an eclipse of the moon visible from the South pole on Earth.

 



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...