Verify intermediate certificate

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Verify intermediate certificate

Johannes Bauer
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Michael S. Zick-4
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 List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Verify intermediate certificate

Dave Thompson-5
> From: [hidden email] 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Johannes Bauer
In reply to this post by Johannes Bauer
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Johannes Bauer
In reply to this post by Michael S. Zick-4
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Johannes Bauer
In reply to this post by Dave Thompson-5
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Johannes Bauer
In reply to this post by Johannes Bauer
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Verify intermediate certificate

Steffen DETTMER
In reply to this post by Johannes Bauer
* 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Curt Sampson
In reply to this post by Johannes Bauer
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@.../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         <[hidden email]>         +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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Re: Verify intermediate certificate

Eisenacher, Patrick
In reply to this post by Steffen DETTMER
> -----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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Verify intermediate certificate

Dr. Stephen Henson
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verify intermediate certificate

Mr.Rout
In reply to this post by Johannes Bauer
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