Re: Subject Issuer Mismatch Bug!!
2009/10/29 David Schwartz dav...@webmaster.com: 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@openssl.org/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-us...@openssl.org Automated List Manager majord...@openssl.org -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
2009/10/30 Dr. Stephen Henson st...@openssl.org: 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-us...@openssl.org Automated List Manager majord...@openssl.org -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
On Fri, Oct 30, 2009, Daniel Marschall wrote: 2009/10/30 Dr. Stephen Henson st...@openssl.org: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
On Fri, Oct 30, 2009, Dr. Stephen Henson wrote: On Fri, Oct 30, 2009, Daniel Marschall wrote: 2009/10/30 Dr. Stephen Henson st...@openssl.org: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
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 dav...@webmaster.com: 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-us...@openssl.org Automated List Manager majord...@openssl.org -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
Any idea? This problem exists since 2003 and noone found an answer - this is unbelievable. 2009/10/26 Daniel Marschall i...@daniel-marschall.de: 2009/10/25, Dr. Stephen Henson st...@openssl.org: 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-us...@openssl.org Automated List Manager majord...@openssl.org -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Subject Issuer Mismatch Bug!!
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=i...@daniel-marschall.de error 29 at 0 depth lookup:subject issuer mismatch /C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Developers/CN=Daniel Marschall/emailaddress=i...@daniel-marschall.de error 29 at 0 depth lookup:subject issuer mismatch /C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Developers/CN=Daniel Marschall/emailaddress=i...@daniel-marschall.de 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=certmas...@viathinksoft.de 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@openssl.org/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=certmas...@viathinksoft.de issuer=/C=DE/ST=Baden-Wuerttemberg/L=Bammental/O=ViaThinkSoft/OU=Root Certificate Signing Authority/CN=ViaThinkSoft Root Certificate Signing Authority/emailaddress=certmas...@viathinksoft.de 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 +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Issuer Mismatch Bug!!
2009/10/25, Dr. Stephen Henson st...@openssl.org: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Daniel Marschall www.daniel-marschall.de +49 6223 488840 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
