Benjamin Grosman <[EMAIL PROTECTED]>:
> I am able to fetch the issue and subject details of the client certificate
> from inside the server, but how do I know that someone hasn't simply
> generated their own certificate with the same details?
If you initialize the verification settings with about the following
call sequence, then your server won't even accept connections from
clients that don't have a valid certificate directly issued from one
of those CAs the self-signed certificates of which are collected
in the file named by "ca_certificate_file":
static long context_num = 0;
SSL_CTX_set_verify(ssl_ctx,
SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
(int (*)(int, X509_STORE_CTX *)) 0);
++context_num;
r = SSL_CTX_set_session_id_context(ssl_ctx,
(void *) &context_num,
(unsigned int) sizeof context_num);
if (!r) ... /* error */
r = SSL_CTX_load_verify_locations(ssl_ctx, ca_certificate_file, NULL);
if (!r) ... /* error */
SSL_CTX_set_client_CA_list(ssl_ctx,
SSL_load_client_CA_file(ca_certificate_file);
SSL_CTX_set_verify_depth(ssl_ctx, 1);
Note that SSL_CTX_set_verify_depth is available only in the current
snapshot, but not in previous versions. Since, as far as I can see,
the internal verification function does not yet properly check whether
intermediate CAs are really certified to act as CAs, you have to
set the verification depth to 1 to disallow certificate owners to sign
certificates at deeper levels -- otherwise they could create their own
certificates with different subject names. This would not open up
your server to people who don't have an accepted certificate in the
first place, but they could pretend to be someone else.
You can also write various callback functions related to certificate
verification and tell the library to call them, but then things become
more involved.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
