Miroslav Kratochvil wrote: > Thanks for fast reply. > > On Thu, Jan 22, 2009 at 7:48 PM, Patrick Patterson > <ppatter...@carillonis.com> wrote: >> On January 22, 2009 01:41:18 pm Miroslav Kratochvil wrote: >>> 2] I want it to reject the certificates which are present in a >>> certificate revocation list (possibly multiple revocation lists), >>> which is supplied in some file. It would be best if the file was >>> loaded on program startup/initialization, so there was no need to do >>> any I/O at runtime. (because my program can possibly do a chroot().) >>> I'm asking for what's the best and usual way to do this - all >>> documentation I found about CRL-handling functions is in form of >>> man-like reference (which doesn't help much, as I'm a newbie here), or >>> in the form of source code (which is hard to read, because it does a >>> million other things I don't need). Could anyone point out any >>> tutorial which explains this, or, at least, shows correct functions to >>> do this? >> Ok - you WILL have to do IO during run time, since a CRL has a validity >> period >> that is usually in the 8 - 24 hour period. So, unless you are going to >> restart your application every 8 hours, you should have some way of ensuring >> that you are using the most up to date CRL. Which either means reloading it >> based on the certificate's CRL Distribution point extension, or reloading it >> off of disk. > > Umm, I guess I have to specify it better - I'm not using SSL in the > "traditional" way, CA-signing is the authorization that the user can > access the network. (So if CA decides, he signs your certificate, and > you can do things.) I want the CRL act like a permanent ban (CA > decides that the user was in fact a rogue and kicks him), to revoke > the certificate forever, like it's common at GPG world. (I know that > "forever" is not practical, so it should be at least to "next CA > change". I'm not really planning the traditional ever-lasting CA's). > Ok - if you are going to use X.509 certificates, then you SHOULD follow RFC5280 and the ISO X.509 recommendations about their use. So, you should perform the validation correctly, and definitely allow Trusted Third party Certificate authorities, unless this application is only going to be used in a close, proprietary environment where you can control 100% of the clients (like the DOCSIS or SWIFT environments). Since it looks like you are writing more open software, then I would strongly suggest that you do PDVal correctly.
(It will make my job a lot easier as someone who has to actually implement this "in real life" :) >>> 3] I would like to check the incoming client certificate against >>> multiple certificate authorities. I know this is possible with >>> SSL_load_verify_locations using the indexed-directory loading, but, as >>> I understood, it loads and examines the CA's on-demand (which is >>> impossible when my program is chrooted.) Is there a possibility to >>> load multiple CA's into memory? >> No, it can load them at startup. > > uh, technically, how? Sorry if it's common, but I really wasn't able > to google that. > Other people have given you a code reference... if you want, you could also take a look at how Pathfinder picks up it's CA locations. >>> 4] I use SSL_VERIFY_FAIL_IF_NO_PEER_CERT, which, suprisingly to me, >>> doesn't verify certificate in Client mode. I suppose the Client mode >>> is set when the SSL is connected using SSL_connect(), so my clients >>> don't check for server certificate presence. Is there a method to >>> force the certificate check even in the Client mode? >>> >>> and maybe a summary: >>> 5] Generally I guess that all my problems fall into "write your own >>> verify_callback" category. If I'm right, I can do 4] myself, but sadly >>> have really no idea how to store the CA's and CRL's in memory. >>> >> Or, you could use a tool like pathfinder >> (http://www.carillon.ca/tools/pathfinder.php) to do it for you - I presume >> that you are doing this on Unix, so it should pretty much "just work" for >> you. We provide patches for a number of applications (apache, openldap, >> stunnel, etc.) that should act as a template for adding in this functionality >> to your program. > > As the CA/key management is meant to be handled by individuals which > are supposed to know what they are doing, pathfinder probably doesn't > really fit here. > Actually, this is EXACTLY why Pathfinder was written, to make it simple and easy for an administrator who knows what they are doing to deploy a PKI based solution. Pathfinder is certainly NOT intended for someone that is not aware of at least the basics of Path Discovery and Validation. We're working on some "installing Pathfinder" documents that will help people that aren't PKI semi-experts deploy Pathfinder, but for now, it really does rely on people knowing what CRLs are, Trust Anchors are, etc. Especially for people programming it... Pathfinder was written with the idea that doing PDVal is a sufficiently ugly problem that most sane programmers wouldn't want to do it if we gave them any way out at all :) >>> I hope someone here can point out any resources that would help me, or >>> just tell me what functions/method of certificate storing/verifying to >>> use. >>> Thanks in advance, >>> >>> Mirek Kratochvil >>> >>> >>> PS., if it helps, the program I'm talking about is here: >>> http://exa.czweb.org/?view=cloudvpn BTW - it looks like you are re-implementing TunnelVision, but with Certificates. I think the code for it is still in Debian somewhere. (a program written and released by the fine folks at Net Integration Technologies (now IBM) back in 1999) Have fun. Patrick. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
