Lutz Jaenicke wrote:
> On Tue, Apr 24, 2001 at 12:27:28PM +0200, Peter Lindsäth wrote:
> > I have the following certificates:
> >
> > root.cert - self signed CA
> > node1root.cert - issued by root
> > node2root.cert - issued by root
> > daemon.cert - issued by node1root
> > client1.cert - issued by node2root
> >
> > I have an SSL server which use the daaemon.cert and has root.cert and node1.cert
> > in its certificateChain.
> > I want to accept and authenticate clients issued by node2root. Not all
> > 'children' to root.cert.
> >
> > My question is what do I put in SSL_CTX_add_client_CA() to make my CA list, and
> > what should I put in the file SSL_CTX_load_verify_locations() loads?
>
> Disclaimer: I haven't tested any of the following ideas!
>
> 1 You put node2root.cert into SSL_CTX_add_client_CA(). Therefore you advertise
> that you trust node2root.cert. (You could also add root.cert instead, it
> must be filtered out in step 3 anyway.)
> 2 You put root.cert to SSL_CTX_load_verify_locations(). When a client
> certificate is presented, it will undergo the complete check of the
> OpenSSL library including certificate purpose etc. If it fails in any
> regard, further checks can be omitted anyway.
> (When the root cert is not found, the error message appearing will depend
> on the certificate chain sent (with/without root cert), so catching this
> special condition may be difficult. Also, the certificate chain verification
> has been carefully crafted by Steve Henson and I would rather trust this
> verificatin routine and only later apply an additional check than
> trying to hack something together myself.)
> 3 After establishing the connection, you call SSL_get_peer_cert_chain()
> and examine the chain. If node2root.cert is not part of the chain
> (use X509_cmp() to compare certificates), close the connection immediately
> and remove the session, as it became invalid.
> 3a Step 3 can be modified in a way, that the verification already takes place
> in the verify_callback. If you always know for sure, that node2root.cert
> is issued by root.cert (level 1), you can check at level 1 whether
> node2root.cert is matched and flag failure if not. This may however
> become tricky later when you change your structure and want to change
> your CA structure. You have forgotten about this special restriction
> (level 1 checking) and spend weeks finding out why it fails with
> your new structure...
> Therefore the corresponding checks in verify_callback() must be
> carefully crafted to be flexible enough. Maybe set a flag when the
> "trusted" CA was found at any level and then on the last level, when
> OK is found, check whether the "trusted" flag is set and only then
> let the OK pass and change to "fail" otherwise....
>
> I personally would tend to version 3a on the long run...
>
> Best regards,
> Lutz
Thanks for the tip.
Well, now there seems to be a problem making a intermediate CA using the self signed
CA.
I've been trying some different approaches but I don't seem to get it right. The most
commonly proposed method, in the mail-archive, would be using the following line:
openssl x509 -req -in node2root.req -CA root.cert -CAkey root.key -out node2root.cert
-CAcreateserial
This, however, doesn't seem work if you trust the output of 'openssl x509 -in
node2root.cert -noout -text'. And by using the cert with my application
X509_V_ERR_INVALID_CA is received. I guess the line 'CA:TRUE' is missing in the
'X509v3 Basic Constraints', but how do I fix that?
Ever so thankful
/Peter
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
