Hi Konrad; It sounds like you are reproducing what has already been done in WvStreams, in the WvX509 and WvX509Mgr classes.
You may want to check both those, and the WvX509Path class in Pathfinder which, IIRC, implements the X509 verification routines. Have fun. Patrick. Konrad Kleine wrote: > Thank you, Kyle Hamilton! We understand what you pointed out. > > Since we are creating a C++ class abstraction (class "SslCertificate") > as a wrapper around a "X509*", we would like to add our "X509*" to the > list of trusted CA certificates. > > Each "SslCertificate" object carries a "X509*" with it and new > "SslCertificate" objects can be created from a "X509*". I say this to > emphasize that we need to have the ability to set our trusted CAs using > "X509" pointers and that there is no need to know our class. > > I think we have to look at the X509_STORE structure but on > http://www.openssl.org/docs/ssl/SSL_CTX_set_cert_store.html it says: > "Currently no detailed documentation on how to use the X509_STORE object > is available." > > That's why we ask here. > > Currently, we can "only" add CA certificate locations as files or > directories using the "SSL_CTX_load_verify_locations". > > But since a "SslCertificate" object can also be created from a > certificate-file or a directory of certificate-files we don't really > need "SSL_CTX_load_verify_locations" and it would break our > object-system somehow. > > Back to the point: > > 0) How can we get the X509-certificate store that we trust? > Is this correct? > > SSL_CTX * context = ... > X509_STORE * store = context->cert_store; > > 1) How can we add a bunch of "X509*" to the X509-certificate-store > that we trust? > > 2) We don't want to use the "SSL_CTX_set_default_verify_paths" > function, since we want to have absolute control of the path > that we trust. However we would like to get the "X509" pointers > that "SSL_CTX_set_default_verify_paths" creates without actually > calling "SSL_CTX_set_default_verify_paths"? > This is needed if someone wants to trust the default locations > such as /etc/ssl/certs. > > Thanks in advance. > Konrad > > Kyle Hamilton schrieb: >> The CA is the point of trust -- the "trust anchor". Since the server >> certificate is issued by the anchor, the client needs the anchor's >> certificate to be able to verify it. >> >> If you want to bypass this, look at the definition of >> SSL_set_verify(). If your verification callback returns 0, the >> certificate is considered unverified. If it returns 1, the >> certificate is considered verified. It is YOUR code that must make >> this determination; usually this includes checking a local certificate >> store for a certificate with a CN= the FQDN of the server, and then >> seeing if the key used for the connection matches the one in that >> certificate. OpenSSL won't do this for you automatically if you don't >> have the server certificate's issuer's certificate on the client. >> >> You may regard it as a bug or a feature, but it's simply reporting >> that the issuer of the certificate has not been saved locally -- and >> thus, it is working as designed and working as intended. It's up to >> your callback code to figure out if it's a case where the verification >> can be considered to have passed. >> >> -Kyle H >> >> On Thu, Jul 3, 2008 at 1:39 AM, Konrad Kleine <[EMAIL PROTECTED]> wrote: >>> Hello, >>> >>> we are writing an client/server-application in C/C++ using OpenSSL. >>> >>> The communication works fine, but if we set the client to verify the >>> server's certificate (using "SSL_set_verify(ssl, SSL_VERIFY_PEER, >>> ourVerifyCallback);") we get the error: >>> >>> "unable to get local issuer certificate" which is explained here: >>> http://www.openssl.org/docs/apps/verify.html#item_20 >>> >>> Some background information on our Certificate hierarchy: We have a >>> custom, self-signed CA certificate and a Server certificate that is >>> directly signed by the CA certificate. Out certificate chain therefore >>> has a depth of 1. >>> >>> To solve the verification problem on client side, it works if we call this: >>> >>> SSL_CTX_load_verify_locations(sslContext, "PATH/TO/CA_FILE.pem", 0); >>> >>> That's fine, but is it possible to verify the server's certificate on >>> client side by specifying a whole directory or a perhaps the copy of the >>> server's certificate file directly? >>> >>> In our examples, verification fails if we don't specify a file that >>> contains the CA certificate among others. >>> >>> Thanks in advance >>> Konrad >>> >>> ______________________________________________________________________ >>> OpenSSL Project http://www.openssl.org >>> User Support Mailing List openssl-users@openssl.org >>> Automated List Manager [EMAIL PROTECTED] >>> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager [EMAIL PROTECTED] >> > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
