[openssl-users] (Probably) Silly Application Programming Question

[Judson Wilson]

It's always good to start with the s_client and s_server programs for
incrementally verifying compatibility in your new programs.  Those would
have failed on your certificates, alerting you it's not a program problem.

On Sun, Jan 10, 2016 at 6:20 PM, Karl Denninger <karl at denninger.net> wrote:

> I found the problem... for an unexplained reason either the certificate or
> key were corrupt; I have added checking to make sure they're coherent, as
> apparently OpenSSL is perfectly happy to load a bogus cert (or key) without
> throwing an error, but won't present them.
>
>
> On 1/10/2016 17:07, Judson Wilson wrote:
>
> On the client side, double check that you are creating the SSL object from
> the context AFTER you set the client cert for the context, and not the
> other way around.
>
> On Sun, Jan 10, 2016 at 2:18 PM, Karl Denninger <karl at denninger.net>
> wrote:
>
>> I'm sure this is a function of my lack of understanding of the
>> documentation, but here it is...
>>
>> I have an application that implements SSL-encrypted transport between two
>> or more devices.  For those that are clients without certificates (e.g.
>> someone connecting with a web browser) it is working fine.
>>
>> However, I also want certain "things" to connect *with* a certificate.
>> Toward that end I have set up a separate context for said connections, with
>> (simplified a bit):
>>
>>                 master_method = (SSL_METHOD *) SSLv23_server_method();
>> /* Create instance */
>>                 master_context = SSL_CTX_new(master_method);  /* Get SSL
>> context for later */
>>
>> Then I set up the CA that is going to verify the client certificates that
>> are presented, with:
>>
>>                 sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR);
>>                 if (!SSL_CTX_load_verify_locations(master_context, tmp,
>> NULL)) {
>>                         syslog(LOG_ERR, "Cannot load verification; MASTER
>> will not validate");
>>                 }
>>
>> and then load the server-side certificate and key, plus tell it to verify
>> the peer.
>>
>>                 sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert);
>>                 if (SSL_CTX_use_certificate_file(master_context, tmp,
>> SSL_FILETYPE_PEM) < 0) {
>>                         syslog(LOG_WARNING, "Cannot load SSL Certificate
>> - SSL MASTER DISABLED");
>>                 } else {
>>                         sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey);
>>                         if (SSL_CTX_use_PrivateKey_file(master_context,
>> tmp, SSL_FILETYPE_PEM) < 0) {
>>                                 syslog(LOG_WARNING, "Cannot load SSL Key
>> - SSL MASTER DISABLED");
>>                         } else {
>>                                 SSL_CTX_set_verify(master_context,
>> SSL_VERIFY_PEER, verify_callback);
>>                                 master_ssl_possible = 1;   /* Enable */
>>                                 syslog(LOG_INFO, "SSL MASTER capability
>> initalized.");
>>                         }
>>                 }
>>
>> verify_callback just returns the preverify_ok flag back; I don't care WHY
>> the verification failed, just whether it did or not.  In other words
>> looking at the "last reason" is good enough (which I can get once the
>> accept fails, if it does.)
>>
>> Now the client has a very similar set of code in it and when it connects
>> it gets the verification (with the callback set to NULL) and, provided the
>> certificate verifies against the CA file provided, all is well and it
>> works.  The client's certificate and key are loaded and the same basic code
>> as up above is used to load the cert and key without errors being thrown
>> (except, of course, that I call SSLv23_client_method() to get the method
>> structure.)  It also connects *and* properly verifies the server's
>> certificate.
>>
>> However, on the server side I never get a client certificate back despite
>> having loaded one into the context on the client and asking for it with
>> SSL_VERIFY_PEER on the server.
>>
>> If I INSIST on a client certificate by adding the
>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at
>> SSL_accept() with an error indicating that no client certificate was
>> provided.
>>
>> If not, however, the accept succeeds, the verification callback routine
>> is never called (!) and when I attempt to get the peer certificate with
>> SSL_get_peer_certificate() so I can walk through it and check the returned
>> attributes (I wish to use the subjectAltName field among others) I get back
>> a NULL.
>>
>> This has to be something stupid on my part, because I should get the
>> verify_callback in any event, I believe -- but I never do.
>>
>> --
>> Karl Denninger
>> karl at denninger.net
>> *The Market Ticker*
>> *[S/MIME encrypted email preferred]*
>>
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> Karl Denninger
> karl at denninger.net
> *The Market Ticker*
> *[S/MIME encrypted email preferred]*
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160110/246fedf5/attachment-0001.html>