Re: 1.0.2 to 1.1 migration problem with verify_callback()
> (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?). History; OpenSSL reserved some exdata indices for itself.
Re: 1.0.2 to 1.1 migration problem with verify_callback()
In my verify callback (for 1.0.2, mind you), I use X509_STORE_CTX_get_app_data(ctx) to get the SSL* pointer. X509_STORE_CTX_get_app_data(ctx) is a macro in OpenSSL's "x509_vfy.h" header file that maps to X509_STORE_CTX_get_ex_data(ctx,0) (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?). Remy Lebeau Lebeau Software On 8/5/2019 7:40 AM, Matt Caswell wrote: From within your callback you can do this to get hold of the SSL object: SSL *s = (SSL *)X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()); And then this to get hold of the hostname requested: const char *hostname = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name);
Re: 1.0.2 to 1.1 migration problem with verify_callback()
On 02/08/2019 18:24, Neptune wrote: > I am in the process of migrating our code from the 1.0.2 library to 1.1 and > have run across a situation that I am struggling to reconcile: > > The existing code utilizes the verify_callback() function in order to > perform validation measures against a peer certificate. This callback > performs validation such as checking the certificate against a CRL and doing > wildcard matching. The reason we need to define our own callback and > validation code is because, as I understand it, the built-in OpenSSL > wildcard matching will only process one wildcard field prefix (*.domain.com) > whereas our requirements allow for wildcard patterns beyond just a prefix > (FOO.*.domain.com, FOO.B*R.domain.com, etc.). > > The problem arises when I attempt to access 'ssl->tlsext_hostname' which is > understood because this structure is now opaque. I believe the accessor > function for this is '__owur const char *SSL_SESSION_get0_hostname(const > SSL_SESSION *s);' in ssl.h. However, within the context of the callback > function I only have two arguments to work with: > > int verify_callback(int ok, X509_STORE_CTX *ctx) > > This does not provide me with a SSL_SESSION object to pass into the > SSL_SESSION_get0_hostname accessor function, so... >From within your callback you can do this to get hold of the SSL object: SSL *s = (SSL *)X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()); And then this to get hold of the hostname requested: const char *hostname = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name); Hope that helps, Matt
1.0.2 to 1.1 migration problem with verify_callback()
I am in the process of migrating our code from the 1.0.2 library to 1.1 and have run across a situation that I am struggling to reconcile: The existing code utilizes the verify_callback() function in order to perform validation measures against a peer certificate. This callback performs validation such as checking the certificate against a CRL and doing wildcard matching. The reason we need to define our own callback and validation code is because, as I understand it, the built-in OpenSSL wildcard matching will only process one wildcard field prefix (*.domain.com) whereas our requirements allow for wildcard patterns beyond just a prefix (FOO.*.domain.com, FOO.B*R.domain.com, etc.). The problem arises when I attempt to access 'ssl->tlsext_hostname' which is understood because this structure is now opaque. I believe the accessor function for this is '__owur const char *SSL_SESSION_get0_hostname(const SSL_SESSION *s);' in ssl.h. However, within the context of the callback function I only have two arguments to work with: int verify_callback(int ok, X509_STORE_CTX *ctx) This does not provide me with a SSL_SESSION object to pass into the SSL_SESSION_get0_hostname accessor function, so... 1. Is SSL_SESSION_get0_hostname() the right accessor for this data? 2. If so, how can I call SSL_SESSION_get0_hostname() within verify_callback() without a SSL_SESSION object? 3. Has the validation code for the 1.1 (and future) branches been changed so that I would no longer need to define my own validation code? (He asks hopefully) Thanks in advance for your help. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
