Jan Meijer wrote:
> You could have a point here. I was fooling around with a test certificate
> that is signed by our root CA (the SURFnet PCA). With this test-certificate
> I signed client certs and I had problems verifying the client certs. The
> troubles went away after including the PCA certificate in the chain (which
> basically tells me openssl does not trust anything unless the final root CA
> cert is included. Think I could argue this reasoning ;). Basically our CA
> will always put the correct subject line into a client/server cert, as will
> the PCA (in a CA's cert). I think it all depends on how the actual clients
> and servers handle chain-checking when deciding what might be usefull for
> the Openssl verify function to act like.
>
> I tried to use it when something failed with my netscape browser, and since
> that is a pretty closed environment I went to openssl for help. There's the
> history of my initial question. Thanks for the answer, I'll have a look at
> the docs :)
I've just finished sorting out our code and checking with the posts
here. Since the above seemed a bit confused (no offence, but this post
seems to imply that you knew less than your previous post :-) and since
it
will help me get things straight in my head, this is a simple summary.
If anything contradicts posts from S Henson then believe him - I learnt
everything I say here from his posts and playing with our code (home
grown Java/C stuff that uses 0.9.4).
IF ANYTHING BELOW IS WRONG PLEASE CORRECT ME! Thanks.
- I will discuss the case where one party, which I call "client" submits
a certificate to another party, which I'll call "server". Those names
aren't intended to imply that one party initiated the connection, or
that verification will not also occur in the other direction.
- So, the client submits a certificate.
- The server's aim is to find a self-signed certificate that signed that
certificate, or a self-signed certificate that signed a certificate that
signed that certificate, or a self-signed certificate that signed a
certificate that signed a certificate that...
- I'll call the self-signed certificate the "root certificate" and the
certificates between it and the client's certificate "intermediate
certificates".
- All intermediate certificates must be present, but they need not all
be present on the server side. The client may supply some intermeditae
certificates. This occurs during the SSL handshake.
- In my experiments the intermediate certificates were used if they were
preent in the client's CAfile or the server's CAfile. Presumable CA
directories would also work.
- The root certificate must be present on the server - the server will
not (successfuly) use a root certificate supplied by the client.
- This procedure is open to abuse because you may not trust people that
are trusted by people you do trust(!). For example, you may trust A. A
may trust B, but you may not trust B. Intermediate certificates can
force you to trust B. This is a security hole.
- This occurs as follows: You sign A's certificate with your root
certificate. A then signs B's certificate with A's certificate. When B
connects to your server, B may include A's certificate. Your server
will then verify B, using A's certificate as an intermediate
certificate.
- At the moment (0.9.4) this can be avoided by refusing to accept a
depth greater than 1 in the verification process.
- Checking the depth is done in our code (and I believe this is normal)
within verify_callback. This routine is supplied to SSL using
SSL_CTX_set_verify. I can't post our code (sorry), but you would simply
return 0 if depth is greater than 1.
- This same callback can also be used to implement CRLs.
- One way to avoid the problem above is to use the CA flag in
basicConstraints. This is a small piece of data within the certificate
that indicates whether the certificate is a CA certificate or not
(remember that information in the certificate, once signed, cannot be
changed, or it will break the signature).
- In the past it was recommended that people not bother with this piece
of data for compatibility. However, it is need to solve the problem
above.
- The security hole above can be closed by only signing other people's
certificates if the CA flag is false and then checking that all
intermediate certificates have a true CA flag.
- This allows you to implement a hierarchy of certificates. You can
have a root CA whose private key is used to sign some "working CA
certificates" (CA flag true) and then hidden away. By keeping the root
key off-network and off-site you can be pretty sure that it will not be
compromised.
- The working CA certificates are used, as intermediate certificates, to
sign other people's certificates. But only certificates where the CA
flag is false are signed.
- Let's return to A and B. A now has a CA=false certificate. A signs
B's certificate. B connects, using A's certificate as an intermediate
certificate. Because A's certificate is not a CA=true certificate,
OpenSSL 0.9.5 refuses it. There is no security hole.
(The last statement is taken from posts - I haven't looked at the code
for 0.9.5 - it is not yet released, but I guess there's a public CVS
archive somewhere if you're curious).
Andrew
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
