Thank you Henrik, it's getting clearer :) But, just a couple more questions? :)
<snip> > If the certificate is issues by a second level CA and the > client trusts the higher level CA who issued the > certificate for the second level CA then you must present > the CA chain or else the client will not be able to > verify the certificate as there is no direct chain of trust > from the certificate to the trusted root CA. I understand. Are there options on how the chain is presented? In particular, is it always presented as a single (combined) response to the client, or can/does the client make a second request for the next cert up the chain if it finds it does not yet trust the last cert presented? > > But I'm not clear on "how" to concat the two or what in > > what order? Is it as simple as > > "cat x1.pem cacert.pem > chainfile.crt" > > And if so, should it be only the ---BEGIN CERT -- to ---END > > CERT--- data, not all of the rest of the text, or can it > > include the human readable text as well? > > As long as it contains the ---BEGIN CERT... blocks openssl > applications with support for loading certificate chain > files should be be fine. Any content outside these blocks > are ignored by OpenSSL. So I take it the simple "cat" command would do to create the chain file, right? > See the documentation for the server application you are > using in how certificate chains should be presented to > the application. I suppose that means the application may or may not require the certs in the chain file to be in any particular order, and, one application (i.e. Apache) might even require the file constructed differently than another app (say Sendmail)? > If you are writing your own application then you need to load > the certificate chain in the application. There is at least > two different methods > > a) Prepare the chain in the certificate file, and load it > when loading the certificate: > > SSL_CTX_use_certificate_chain_file > > b) Set up trust to the CAs who issued your certificate before > loading the certificate > > SSL_CTX_load_verify_locations > > Several other variants are possible. Thank you for the tip. I will indeed be writing a new app using OpenSSL just as soon as I get these general concepts understood :) > > Also, what's the difference between the /certs and the /newcerts > > directories? Is the /certs where I place the certs that I trust > > and the /newcerts only stores the certs I've issued, but don't > > need to trust them explicitly (since I trust the issuer)? > > Not really relevant to running servers.. these are just > directories used by the CA.pl script and the demoCA configuration. > > The certs directory is probably meant to contain already issued > and delivered certificates allowing you to keep track of which > certificates have been delivered to their use and which are newly > issued certificates. > The directory is not actually used from what I can tell. That's interesting. So it sounds as though each app must be told where the certs are and it's NOT something that the OpenSSL lib inherhently knows? But what about the references I've read that require the creation of hashed links to the individual certs in a directory? Who, and/or what, uses that data then? Is that application dependent as well? Pardon my confusion, but I've been building a new server this past week, upgrading to the latest versions of all the server apps, and with all the README and INSTALL files I've been reading, it's getting difficult to keep straight which app and which library requires what :) Thanks again Henrik, you're a great help! Best regards, Dann ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
