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]
