Re: Verify intermediate certificate
Hi Johannes Bauer If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is av self-signed certificate. If you donot mind would you please mention what are the Openssl commands you used to create this chain ? Please help me on this. Thanks in advance. Best Regards, S S Rout -- View this message in context: http://old.nabble.com/Verify-intermediate-certificate-tp33129488p33479981.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Re: Verify intermediate certificate
-Original Message- From: Steffen DETTMER * Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? [yes, it is not possible by default] Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. If I remember correctly, there is work going on to enable such functionality in an upcoming release. Perhaps Steve can shed some light on its status. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re: Verify intermediate certificate
On Mon, Jan 16, 2012, Eisenacher, Patrick wrote: -Original Message- From: Steffen DETTMER * Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? [yes, it is not possible by default] Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. If I remember correctly, there is work going on to enable such functionality in an upcoming release. Perhaps Steve can shed some light on its status. There is experimental support for this in HEAD only. You need to set an explicit trust option on the intermediate CA and it should verify OK even if the root is absent. 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: Verify intermediate certificate
On 2012-01-13 15:38 +0100 (Fri), Johannes Bauer wrote: Ah, good, then I explained it well enough :-) Do you have a solution for your scenario? Do you manually check certificates? Or is there some workaround? I described my situation in a little more detail in this message: http://www.mail-archive.com/openssl-users@openssl.org/msg65890.html My current plan, unless I get further advice otherwise, is to add some custom fields to the certs I use within this system and then to use custom validation functions to determine whether, for any particular cert, it is required to be signed by the master CA rather than a client CA. cjs -- Curt Sampson c...@cynic.net +81 90 7737 2974 http://www.starling-software.com/ I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 12.01.2012 19:05, Kenneth Goldman wrote: I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It's more than valid. I think it's essential that the server omit the root. If the server supplied the entire chain, they could create the entire chain, and thus could claim to be anyone. Hmm - I disagree with that assessment. The client has to check that the root (that the server may provide or may omit) is inside the trusted certificate store of the client -- regardless of the client provides it or not. And clients (and probably therefore OpenSSL) do that, too: When I for testing purposes create and send a complete certificate path for a SSL webserver, Firefox still rejects it as it should, because no certificate is in the truststore. The root must be delivered out of band, trusted by other means. Correct. The question is just: can this root of trust be an intermediate certificate or must it be a self-signed certificate? Is this one of the checks that occurs within the OpenSSL client? To clarify what I mean, please consider the tiny picture at http://pastebin.ca/2102780 Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D certificate and have in my clients only one certificate in the certificate store: B. The clients cannot connect (cannot verify peer), because in the client's certificate store, A is missing (deliberately!). The reason why it is missing is the following: If I put A into the store of the clients, A might have issued a sub-CA certificate to my opponent C (which I do not have control over). C would sign a certificate for Eve which contains my server's DNS name as CN. Then when Eve would make a man-in-the-middle attack with it's fake webserver, my clients would still connect, since they can construct a path to the root A (E - C - A). I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 12.01.2012 19:23, Michael S. Zick wrote: On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It is a third party verification system that is used. How could you trust the server to tell you itself who it is? I can trust the webserver because the signature of it's certificate was verifiably created by the intermediate CA (which I trust and who's certificate the client has in its trust store). Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Well, the thing is: Having them self-signed is not necessary for security purposes. It apparently is what OpenSSL requires. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Well, I'm just part of the big picture ;-) Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 01:02, Dave Thompson wrote: The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Yes. Or rather the libcrypto routine X509_verify_cert, used by the 'verify' utility and also the SSL handshake logic and also other applications if they wish, insists on reaching a root. Ah, I figured I'd have to go there. The reason why I was hoping to get around this is that the OpenSSL code is properly reviewed and auditted -- I would rather not write code which could have serious sercurity implications if it's broken (especially since it's not properly reviewed). Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Not in OpenSSL, unless you change the verify logic, or replace or override it with your own (which AFAICS could be done, with some effort, using the optional verify callback). It's not clear to me this is the best policy choice; IE (or I believe actually some Windows feature IE uses) and Firefox and Java (JSSE) all allow you to establish a non-root as a trust anchor. But it's what OpenSSL does, and has for a long time. Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). I'll have a look into the custom verify-peer-callback and see how difficult it is and how easily it can be used. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 10:15, Curt Sampson wrote: On 2012-01-13 09:54 +0100 (Fri), Johannes Bauer wrote: Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D I think you meant, B there. Ah, yes. I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. I think understand exactly what you are doing and why you want to do it. (I have similar issues within a system in which I'm working.) Ah, good, then I explained it well enough :-) Do you have a solution for your scenario? Do you manually check certificates? Or is there some workaround? Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re: Verify intermediate certificate
* Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? [yes, it is not possible by default] Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. Only point to require root-CA is to check if it still is valid and require it in order to be able to check it's CRL for the sub-CA being included. Personally, I still wonder why I should be stopped from trusting a sub-CA even if the root-CA revoked it when I explicitely configure it to do so, but anyway usually OS or browser vendors seem to decide for the users whom to trust ;-) In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). Certify the identity to be authentic, that means that the name given in the certificate is authentic. This is like an ID card or passport. From this it cannot be concluded whether the authentic name owner is authorized for communication (or whatever). For this, some list of allowed names is needed. This is like a guest list. Unfortunately it seems to happen from time to time to meet some projects/installations that check only whether a peer is authentic but not it authorized (like: anyone with a valid password can use the VIP entry, because no guest list check is performed). For example, in a typical webbrowser I think you cannot configure NOT to communicate with authentic badguy.malware.com; if TLS makes it absolutely sure that you really communicate with `badguy', you will get a green security symbol :-) oki, Steffen -- End of message. My personal opinion only etc. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify intermediate certificate
Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It is a third party verification system that is used. How could you trust the server to tell you itself who it is? Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Mike Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Verify intermediate certificate
From: owner-openssl-us...@openssl.org On Behalf Of Michael S. Zick Sent: Thursday, 12 January, 2012 13:24 On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain: Root - A - B - Leaf [...] is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? [...] It is a third party verification system that is used. How could you trust the server to tell you itself who it is? Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. Exactly. Which in OpenSSL is usually 'CAfile' or 'CApath'. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Nit: not necessarily in the 'business' of being trusted. Just some party which IS trusted. For example some part(s?) of the US DoD issue certs for employees and contractors. The DoD's 'business' is preparing to do and doing military actions directed by the elected government (which should do so in the interests of the country, but that's a different issue and offtopic here). Issuing certs is a minor sideline. Most(?) of the well-known public CAs were created solely to be CAs, but many(?) of them have been acquired by businesses which have other functions as well. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Exactly. This is similarly a sideline. Mike Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Yes. Or rather the libcrypto routine X509_verify_cert, used by the 'verify' utility and also the SSL handshake logic and also other applications if they wish, insists on reaching a root. Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Not in OpenSSL, unless you change the verify logic, or replace or override it with your own (which AFAICS could be done, with some effort, using the optional verify callback). It's not clear to me this is the best policy choice; IE (or I believe actually some Windows feature IE uses) and Firefox and Java (JSSE) all allow you to establish a non-root as a trust anchor. But it's what OpenSSL does, and has for a long time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
