Re: Call own sign/verify callback - engine
If you are using RSA, maybe it should be useful to look at some RSA implementations, such as engines/e_devcrypto.c On Thu, Feb 6, 2020 at 7:23 PM Pedro Lopes wrote: > Hello, > > I'd like that my callback is called when a sign/verify is being requested > by > *EVP_DigestSignFinal()* function. > I've tried add a EVP_PKEY_METHOD to app_methods stack, that works good > however doesnt fit on my solution. > > I noticed that creating an engine and set pkey methods there, it could > solve > it. > I looked at gost engine to have in mind what I should do. > So, in engine I call *ENGINE_set_pkey_meths()*, so far so good. > > The issue occurs when I try to assign a RSA key. I call > *EVP_PKEY_assign(*outKey, NID_sha1WithRSAEncryption, key);*. The error > returned is *pkey_set_type:unsupported algorithm*. > > Most probably I'm missing something. > > If *EVP_PKEY_assign()*worked I will call *EVP_DigestSignInit(ctx, NULL, > sha1(), engine, pkey)*. > > Thanks in advance. > -- SY, Dmitry Belyavsky
Call own sign/verify callback - engine
Hello, I'd like that my callback is called when a sign/verify is being requested by *EVP_DigestSignFinal()* function. I've tried add a EVP_PKEY_METHOD to app_methods stack, that works good however doesnt fit on my solution. I noticed that creating an engine and set pkey methods there, it could solve it. I looked at gost engine to have in mind what I should do. So, in engine I call *ENGINE_set_pkey_meths()*, so far so good. The issue occurs when I try to assign a RSA key. I call *EVP_PKEY_assign(*outKey, NID_sha1WithRSAEncryption, key);*. The error returned is *pkey_set_type:unsupported algorithm*. Most probably I'm missing something. If *EVP_PKEY_assign()*worked I will call *EVP_DigestSignInit(ctx, NULL, sha1(), engine, pkey)*. Thanks in advance.
Re: [openssl-users] Verify callback to ignore certificate expiry
Thanks for your help, I posted the sample (which I guess is a little misleading given that it's taken straight off the OpenSSL page I noted) and not what it currently does which is very close to what you've suggested. So that's one problem I don't have to worry about! Thanks again ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, December 03, 2015 9:08 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] Verify callback to ignore certificate expiry On Thu, Dec 03, 2015 at 05:00:12PM +, Nounou Dadoun wrote: > Calling > X509_STORE_CTX_set_error(ctx, X509_V_OK); Is actually what I'm doing > already but I was worried that it would then ignore any other errors > (e.g. bad signature etc.); No, because is error is reported separately, and you're not setting "ok = 1" for the other errors. > I'd actually thought > the errors might be ORed together but that doesn't look like the case. Each error is reported separately. > So does it invoke the callback for each error (which is sort of a convoluted > way of ORing)? Yes, though I don't think of it as "ORing". > If I say ok to EXPIRED will it catch a bad signature? Yes. -- Viktor. ___ 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
Re: [openssl-users] Verify callback to ignore certificate expiry
On Thu, Dec 03, 2015 at 05:00:12PM +, Nounou Dadoun wrote: > Calling > X509_STORE_CTX_set_error(ctx, X509_V_OK); > Is actually what I'm doing already but I was worried that it would then > ignore any other errors (e.g. bad signature etc.); No, because is error is reported separately, and you're not setting "ok = 1" for the other errors. > I'd actually thought > the errors might be ORed together but that doesn't look like the case. Each error is reported separately. > So does it invoke the callback for each error (which is sort of a convoluted > way of ORing)? Yes, though I don't think of it as "ORing". > If I say ok to EXPIRED will it catch a bad signature? Yes. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Verify callback to ignore certificate expiry
Calling
X509_STORE_CTX_set_error(ctx, X509_V_OK);
Is actually what I'm doing already but I was worried that it would then ignore
any other errors (e.g. bad signature etc.); I'd actually thought the errors
might be ORed together but that doesn't look like the case.
So does it invoke the callback for each error (which is sort of a convoluted
way of ORing)?
If I say ok to EXPIRED will it catch a bad signature?
Thanks for your help ... N
Nou Dadoun
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Viktor Dukhovni
Sent: Thursday, December 03, 2015 7:00 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verify callback to ignore certificate expiry
On Thu, Dec 03, 2015 at 06:01:36AM +, Nou Dadoun wrote:
> Another quick question, I'm setting up a server ssl handshake on a device on
> which the certificate verification will sometimes fail not because the
> certificate is bad but because the time is not set properly on the device.
>
> I'm doing an ssl verify callback that is almost identical to one of
> the examples in
> https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verif
> y_cb.html
> I.e.
>
> int verify_callback(int ok, X509_STORE_CTX *ctx)
> {
> int err = X509_STORE_CTX_get_error(ctx);
> X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx);
> if (err == X509_V_ERR_CERT_HAS_EXPIRED)
> {
> if (check_is_acceptable_expired_cert(err_cert)
> return 1;
> }
> return ok;
> }
>
> I have some other slight differences but basically what I need is an
> implementation for the (fictitious)
> "check_is_acceptable_expired_cert(err_cert)" function call.
>
> Is there any quick way of doing this that doesn't involve completely
> reconstructing the steps for verification (and leaving one out)? I
> can do that if I need to but this is only one part of a larger
> endeavour that will take much more time - any pointers? thanks N
The required function is mostly a NOOP, after you return 1, OpenSSL will
continue to perform all the other checks it would do had the certificate not
been expired.
However, you probably want the verification result to be OK at the completion
of the handshake (have SSL_get_verify_result() return X509_V_OK). So all that
the code needs to do is to set the error status to X509_V_OK.
X509_STORE_CTX_set_error(ctx, X509_V_OK);
Provided you return 0 (abort the handshake on any errors you're not explicitly
ignoring, you're OK.
If you ever decide to continue handshakes despite other errors, then more care
is required to restore any previous error status (which you'll need to store
somewhere) when ignoring the errors you want to suppress.
--
Viktor.
___
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
Re: [openssl-users] Verify callback to ignore certificate expiry
On Thu, Dec 03, 2015 at 06:01:36AM +, Nounou Dadoun wrote:
> Another quick question, I'm setting up a server ssl handshake on a device on
> which the certificate verification will sometimes fail not because the
> certificate is bad but because the time is not set properly on the device.
>
> I'm doing an ssl verify callback that is almost identical to one of the
> examples in
> https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verify_cb.html
> I.e.
>
> int verify_callback(int ok, X509_STORE_CTX *ctx)
> {
> int err = X509_STORE_CTX_get_error(ctx);
> X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx);
> if (err == X509_V_ERR_CERT_HAS_EXPIRED)
> {
> if (check_is_acceptable_expired_cert(err_cert)
> return 1;
> }
> return ok;
> }
>
> I have some other slight differences but basically what I need is an
> implementation for the (fictitious)
> "check_is_acceptable_expired_cert(err_cert)" function call.
>
> Is there any quick way of doing this that doesn't involve completely
> reconstructing the steps for verification (and leaving one out)? I can
> do that if I need to but this is only one part of a larger endeavour that
> will take much more time - any pointers? thanks N
The required function is mostly a NOOP, after you return 1, OpenSSL
will continue to perform all the other checks it would do had the
certificate not been expired.
However, you probably want the verification result to be OK at the
completion of the handshake (have SSL_get_verify_result() return
X509_V_OK). So all that the code needs to do is to set the error
status to X509_V_OK.
X509_STORE_CTX_set_error(ctx, X509_V_OK);
Provided you return 0 (abort the handshake on any errors you're
not explicitly ignoring, you're OK.
If you ever decide to continue handshakes despite other errors,
then more care is required to restore any previous error status
(which you'll need to store somewhere) when ignoring the errors
you want to suppress.
--
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Verify callback to ignore certificate expiry
Another quick question, I'm setting up a server ssl handshake on a device on
which the certificate verification will sometimes fail not because the
certificate is bad but because the time is not set properly on the device.
I'm doing an ssl verify callback that is almost identical to one of the
examples in
https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verify_cb.html
I.e.
int verify_callback(int ok, X509_STORE_CTX *ctx)
{
int err = X509_STORE_CTX_get_error(ctx);
X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx);
if (err == X509_V_ERR_CERT_HAS_EXPIRED)
{
if (check_is_acceptable_expired_cert(err_cert)
return 1;
}
return ok;
}
I have some other slight differences but basically what I need is an
implementation for the (fictitious)
"check_is_acceptable_expired_cert(err_cert)" function call.
Is there any quick way of doing this that doesn't involve completely
reconstructing the steps for verification (and leaving one out)? I can do that
if I need to but this is only one part of a larger endeavour that will take
much more time - any pointers? thanks N
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Verify callback and sending of the client certificate
On Fri, Aug 09, 2013, Florian Weimer wrote: > Qt installs a verification callback like this > > |// Register a custom callback to get all verification errors. > |X509_STORE_set_verify_cb_func(ctx->cert_store, q_X509Callback); > > ctx is an SSL_CTX *. This callback is invoked not just to verify > the server certificate, but also when OpenSSL tries to complete the > certificate chain before sending the client certificate. OpenSSL > clears errors resulting from this, but it cannot roll back the > effects of calling the callback. Are these callback invocations > expected behavior? > This is expected behaviour for OpenSSL 1.0.1 and earlier where the same parent SSL_CTX store is used for both chain building and peer chain verification. If an application only wants to set a callback for verification of peer chains it should instead set the callback using SSL_CTX_set_verify(). OpenSSL 1.0.2 and later will support separate stores for chain building and peer verification. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify callback and sending of the client certificate
On 08/09/2013 01:18 PM, Peter Sylvester wrote: On 08/09/2013 11:17 AM, Florian Weimer wrote: Qt installs a verification callback like this |// Register a custom callback to get all verification errors. |X509_STORE_set_verify_cb_func(ctx->cert_store, q_X509Callback); It is not recommended to access to members in the way above, but rather: X509_STORE_set_verify_cb_func(SSL_CTX_get_store(ctx), q_X509Callback); I think you mean SSL_CTX_get_cert_store, and this is unrelated to my question. :-) -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify callback and sending of the client certificate
On 08/09/2013 11:17 AM, Florian Weimer wrote: Qt installs a verification callback like this |// Register a custom callback to get all verification errors. |X509_STORE_set_verify_cb_func(ctx->cert_store, q_X509Callback); It is not recommended to access to members in the way above, but rather: X509_STORE_set_verify_cb_func(SSL_CTX_get_store(ctx), q_X509Callback); /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify callback and sending of the client certificate
Qt installs a verification callback like this |// Register a custom callback to get all verification errors. |X509_STORE_set_verify_cb_func(ctx->cert_store, q_X509Callback); ctx is an SSL_CTX *. This callback is invoked not just to verify the server certificate, but also when OpenSSL tries to complete the certificate chain before sending the client certificate. OpenSSL clears errors resulting from this, but it cannot roll back the effects of calling the callback. Are these callback invocations expected behavior? -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: X509 Verify callback
On Tue, 2010-05-11 at 09:58 -0400, Chris Bare wrote: > That's almost perfect, but doesn't putting it inside the X509_STORE like this > tell the rest of the code it's trusted? If I'm downloading it using AIA I > can't trust it and still need to chain up to a trusted root. Hm, true. But surely there's something else (ctx->verify_cb or ctx->verify?) that lets you fix that up too? -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: X509 Verify callback
> On Mon, 2010-05-10 at 14:43 -0400, Chris Bare wrote:
> > Is there a way get have X509_verify_cert retry it's path building after it
> > gets an X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT?
> > My idea is to implement a verify callback that uses the AIA information to
> > download the issuer cert and add it to the stack of untrusted certs.
> > Is this possible, or would I have to let X509_verify_cert error out and call
> > it again?
>
> How about...
>
> int my_get_issuer_func(X509 **issuer, X509_STORE_CTX *ctx, X509 *x)
> {
> int ret = X509_STORE_CTX_get1_issuer(issuer, ctx, x);
>
> if (ret > 0)
> return ret;
>
> /* Do whatever you need to look up the issuer... */
> }
>
> ... and somewhere else in your SSL_CTX setup:
>
> X509_STORE *store = SSL_CTX_get_cert_store(vpninfo->https_ctx);
> store->get_issuer = my_get_issuer_func;
>
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com Intel Corporation
>
That's almost perfect, but doesn't putting it inside the X509_STORE like this
tell the rest of the code it's trusted? If I'm downloading it using AIA I
can't trust it and still need to chain up to a trusted root.
It's too bad the verify function takes a STORE for trusted certs and a stack
for other certs. If both were STOREs I could do exactly what you describe
above.
--
Chris Bare
ch...@bareflix.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: X509 Verify callback
On Mon, 2010-05-10 at 14:43 -0400, Chris Bare wrote:
> Is there a way get have X509_verify_cert retry it's path building after it
> gets an X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT?
> My idea is to implement a verify callback that uses the AIA information to
> download the issuer cert and add it to the stack of untrusted certs.
> Is this possible, or would I have to let X509_verify_cert error out and call
> it again?
How about...
int my_get_issuer_func(X509 **issuer, X509_STORE_CTX *ctx, X509 *x)
{
int ret = X509_STORE_CTX_get1_issuer(issuer, ctx, x);
if (ret > 0)
return ret;
/* Do whatever you need to look up the issuer... */
}
... and somewhere else in your SSL_CTX setup:
X509_STORE *store = SSL_CTX_get_cert_store(vpninfo->https_ctx);
store->get_issuer = my_get_issuer_func;
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: X509 Verify callback
> On 05/10/2010 08:43 PM, Chris Bare wrote: > > Is there a way get have X509_verify_cert retry it's path building after it > > gets an X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT? > > My idea is to implement a verify callback that uses the AIA information to > > download the issuer cert and add it to the stack of untrusted certs. > > Is this possible, or would I have to let X509_verify_cert error out and call > > it again? > > > > Trying to do path building during path validation > may end up in a never ending loop or almost. > How else can I leverage the local path building code? What if I happen to have parts of the path already? The path validation will build the path until it fails and that shows me what to go out and download next. At least that's how I'm thinking of it, but I'm open to suggestions. -- Chris Bare ch...@bareflix.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: X509 Verify callback
On 05/10/2010 08:43 PM, Chris Bare wrote: Is there a way get have X509_verify_cert retry it's path building after it gets an X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT? My idea is to implement a verify callback that uses the AIA information to download the issuer cert and add it to the stack of untrusted certs. Is this possible, or would I have to let X509_verify_cert error out and call it again? Trying to do path building during path validation may end up in a never ending loop or almost. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X509 Verify callback
Is there a way get have X509_verify_cert retry it's path building after it gets an X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT? My idea is to implement a verify callback that uses the AIA information to download the issuer cert and add it to the stack of untrusted certs. Is this possible, or would I have to let X509_verify_cert error out and call it again? -- Chris Bare ch...@bareflix.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: verify callback API question ctx->current_cert
On Mon, Aug 03, 2009, Josselin Jacquard wrote: > Hi all, i'm using openssl on top of a pgp authentication. > > I've got a null pointer exception with ctx->current_cert (the other testers > of my project don't have this null pointer) and I don't understand why this > pointer is null. > > I've change ctx->current_cert to ctx->cert to make it work. Is it secure ? > Depends on what you want to use it for. The ctx->cert field is the certificate being verified while ctx->current_cert is the certificate passed to the verify callback indicating an error of some sort occurred. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify callback API question ctx->current_cert
Hi all, i'm using openssl on top of a pgp authentication.
I've got a null pointer exception with ctx->current_cert (the other testers
of my project don't have this null pointer) and I don't understand why this
pointer is null.
I've change ctx->current_cert to ctx->cert to make it work. Is it secure ?
Thanks a lot for the dev work on openssl.
Here's my code :
int GPGAuthMgr::VerifyX509Callback(int preverify_ok, X509_STORE_CTX *ctx) {
char buf[256];
X509 *err_cert;
int err, depth;
err_cert = X509_STORE_CTX_get_current_cert(ctx);
err = X509_STORE_CTX_get_error(ctx);
depth = X509_STORE_CTX_get_error_depth(ctx);
/*
* Retrieve the pointer to the SSL of the connection currently treated
* and the application specific data stored into the SSL object.
*/
X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256);
if (!preverify_ok) {
fprintf(stderr, "Verify error:num=%d:%s:depth=%d:%s\n", err,
X509_verify_cert_error_string(err), depth, buf);
}
/*
* At this point, err contains the last verification error. We can use
* it for something special
*/
if (!preverify_ok)
{
if ((err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT) ||
(err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY))
{
//HERE'S THE NULL POINTER. I'VE CHANGED ctx->current_cert TO ctx->cert IN
ORDER TO MAKE IT WORK. IS IT OK ?
X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert), buf, 256);
printf("issuer= %s\n", buf);
fprintf(stderr, "Doing REAL PGP Certificates\n");
/* do the REAL Authentication */
if (!AuthX509(ctx->cert))
{
return false;
}
std::string pgpid = getX509CNString(ctx->cert->cert_info->issuer);
if (!isPGPAuthenticated(pgpid))
{
return false;
}
preverify_ok = true;
Re: certificate verify callback API question
Somehow I missed the response. Good, that there are archives: > Those examples need updating. Use of X509_NAME_oneline() has been discouraged > for some time. Yes, seems so, Any other function that takes a NULL X509* may also have a problem. My question was simply to confirm that a NULL pointer *can* happen. > While this is true it wont happen unless you explicitly set policy checking > along with some additional flags. If an application does set the extra flags > it is expected to understand the implications in the callback. Yes. If they are documented :-) > One case is when you set a flag to require an explicit policy but there is > none in the chain. In that case the error isn't tied to one particular > certificate but the chain itself. > The other case is when you set a flag to notify that policy checking has > succeeded. Again this means the whole chain is OK and not indicating anything > right/wrong with a particular certificate. That is what I figured out. I am not asking for a change, here a kind of devil's advocate argument: Leaving the pointer unchanged (i.e. the end entity) would that hurt much? One could still interprete: "no policy related to the chain that ends with the cert ..." and "The chain for cert xxx is valid and we have policy yyy". At least in case of the missing explicit policy error, a callback may want to log something of the chain. > Steve. Anyway, thanks for the answer. /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: certificate verify callback API question
On Wed, Jun 24, 2009, Peter Sylvester wrote: > Hello, > > In 1.0.0beta it seems that the interface between > the certificate verify callback and the store context > has slightly changed. > > The X509_STORE_CTX_get_current_cert may now > return NULL which was not the case before the > introduction of policy checking. > > Is it the responsibility of the callback not to assume > a non-null pointer now, for example not to simply > call X509_oneline to format the cert subject? > > At least the verify callbacks currently in use in > apps check this (except for s_cb which is used > by s_server, but which is not yet affected). > > The example in the openssl docs uses > > X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256); > > but also: > > X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert) > > Those examples need updating. Use of X509_NAME_oneline() has been discouraged for some time. While this is true it wont happen unless you explicitly set policy checking along with some additional flags. If an application does set the extra flags it is expected to understand the implications in the callback. One case is when you set a flag to require an explicit policy but there is none in the chain. In that case the error isn't tied to one particular certificate but the chain itself. The other case is when you set a flag to notify that policy checking has succeeded. Again this means the whole chain is OK and not indicating anything right/wrong with a particular certificate. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
certificate verify callback API question
Hello, In 1.0.0beta it seems that the interface between the certificate verify callback and the store context has slightly changed. The X509_STORE_CTX_get_current_cert may now return NULL which was not the case before the introduction of policy checking. Is it the responsibility of the callback not to assume a non-null pointer now, for example not to simply call X509_oneline to format the cert subject? At least the verify callbacks currently in use in apps check this (except for s_cb which is used by s_server, but which is not yet affected). The example in the openssl docs uses X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256); but also: X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert) Thanks in advance for any information. Peter Sylvester __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify callback called twice
I've written a callback function to verify certificates because I
need to verify if the user can access some resources.
cert_verify_callback()
{
if ! preverify_ok
log error
return 0
if ! depth // user certificate
check if certificate CN is an allowed user
if no
log error
return 0
return 1
}
The problem is that the function seems to be called twice when
the user is not allowed to access.
In other words, when preverify is 1 and callback returns 0, the
function is re-executed.
Can somebody explain why?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: client verify callback
On Tue, Jul 24, 2001 at 02:45:17PM -0230, Cory Winter wrote: > Hi, > > If a client implements it's own verify callback and that callback prompts > the user for input. (ie. Yes/No to allow connection) Is there a mechanism > which would prevent this action from blocking the server? Currently my > server which accepts all connections on a single thread denies connections > to other clients once a single client is waiting for input from the user. > > SSL_accept(...) doesn't return until SSL_connect(...)'s verify callback > returns. The handshake waits. Is this incorrect usage of the verify > callback? Hmm. I think it is ok to use it this way. As far as I can see, Netscape does the same if there are doubts (unknown CA, hostname not matching). I would see it the other way round: your server is broken. A single client can block it. It's the perfect situation for a DoS attack. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: client verify callback
Cory Winter <[EMAIL PROTECTED]> writes: > If a client implements it's own verify callback and that callback prompts > the user for input. (ie. Yes/No to allow connection) Is there a mechanism > which would prevent this action from blocking the server? Currently my > server which accepts all connections on a single thread denies connections > to other clients once a single client is waiting for input from the user. This is a bad idea in general since it allows one client to block everyone else. Better to use non-blocking I/O or a separate thread to service each client. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
client verify callback
Hi, If a client implements it's own verify callback and that callback prompts the user for input. (ie. Yes/No to allow connection) Is there a mechanism which would prevent this action from blocking the server? Currently my server which accepts all connections on a single thread denies connections to other clients once a single client is waiting for input from the user. SSL_accept(...) doesn't return until SSL_connect(...)'s verify callback returns. The handshake waits. Is this incorrect usage of the verify callback? Cory -- Cory Winter E-Mail: [EMAIL PROTECTED] IONA Phone : (709) 738-3725 Total Business Integration (TM) WWW : http://www.iona.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Verify Callback
Hello! I'm some questions 1) int verify_callback(int ok, X509_STORE_CTX *ctx); Does this function make the verification of the certificate received with the certificate of the his CA? 2) How I can generate a store of certificates? Thanks in advance, Regards, Antonio. -- -- Antonio Ruiz Martínez Facultad de Informática-Universidad de Murcia 30001 Murcia - España (Spain) Telf: +34-968-364644 e-mail: [EMAIL PROTECTED] -- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Error calling Verify Callback
You need to write a function named verify_callback. Look at apps/s_cb.c for an example. > -Original Message- > From: Marcus Carey [SMTP:[EMAIL PROTECTED]] > Sent: Friday, April 27, 2001 11:35 AM > To: [EMAIL PROTECTED] > Subject: Error calling Verify Callback > > #include > SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,verify_callback); > > When I compile my program with the above function I get the following > error: > > > serv.cpp: In function `int main(...)': > serv.cpp:103: `verify_callback' undeclared (first use this function) > serv.cpp:103: (Each undeclared identifier is reported only once > serv.cpp:103: for each function it appears in.) > > > How do I use the SSL_CTX_set_verify in my programs? > > Thanks! > > Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
