[openssl.org #491] [Fwd: Bug#180067: openssl: 0.9.7 causes gcc in sid to output warnings]
In OpenSSL, the 'info_callback' gets a 'const SSL *' argument; the application in question used 'SSL *', which caused the compiler warning for 0.9.7 (earlier OpenSSL versions did not declare the 'info_callback' argument list at all). The problem has been solved by changing the application accordingly (Debian Bug#180067). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #496] BUG: openssl v 0.9.7 openssl ca -gencrls
[[EMAIL PROTECTED] - Mon Feb 10 08:28:12 2003]: # openssl ca -gencrl Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem:pass entered -BEGIN X509 CRL- snip -END X509 CRL- Segmentation fault # The revocation list between BEGIN X509 CRL- and END X509 CRL- seems usable if copied from console into a file crls.pem Trying -out option gives: # openssl ca -gencrl -out crls.pem Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem:pass entered Segmentation fault # Just to report this undesirable behaviour. If you'd need more contact info, you may contact me via email: [EMAIL PROTECTED] If I made a mistake, i'd be very pleased for getting some answers, too. Fixed in 0.9.7-stable which will be 0.9.7a. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]: But OpenSSL tries to complete the server CA list with the certificates set in the client CA list. This can result in an invalid server CA list if the client CA list contains a CA cert with a DN that matches the issuer DN in the server cert or the root CA cert of the server CA list. So it is not possible for the servwe to accept client certs issued by the own root CA and prevent this root from being sent to the client as own root. Indeed, it uses a primitive path building algorithm in ssl3_output_cert_chain() which relies on the first certificate it finds whose subject matches the issuer name of the current certificate to be the next in the chain and halts when it finds one with issuer and subject names being equivalent. In my test there was a self signed root cert in the list of CA certs for the server cert, but there was an other CA cert (same DN, different life time) in the list of CA certs for accepted client certificates. OpenSSL inserted the CA cert from the accepted client CAs in the list of server CA certificates... IIRC this is very old code and has been about since the early SSLeay days. I see the problem imediately ... ;-) There are a number of problems with it. [...] It really needs replacing with something less horrible. For example it might: 1. Build the chain using the normal certificate verify code including the usual checks on validity and using appropriate purpose and trust. 2. Give a (fatal?) error if the verification fails. 3. Include a flag to exclude the root CA from outputted chain 4. Include an flag to disable the automatic chain building altogether and rely on the chain being correctly present in the extra certs of the context. I don't see a need for points 3 and 4. If the CA certs for the server cert are in a seperate list, the content of the cert chain is in control of the user. And if he doesn't want the root cert in the chain, he only has to exclude them in the config file. The actual bug is only because OpenSSL tried to be to smart and included in the list certificates it never was told to include... All I want to have is something like: build the list of server CA certs from the given file (or build by SSL_CTX_add_extra_chain_cert()) (in the order I give) and _don't_ include any other certificates... 5. Cache the path after it has been determined. Or build it one time and reuse it... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #492] SSL: server root certs and client auth.
[[EMAIL PROTECTED] - Mon Feb 10 16:53:48 2003]: Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]: There are a number of problems with it. [...] It really needs replacing with something less horrible. For example it might: 1. Build the chain using the normal certificate verify code including the usual checks on validity and using appropriate purpose and trust. 2. Give a (fatal?) error if the verification fails. 3. Include a flag to exclude the root CA from outputted chain 4. Include an flag to disable the automatic chain building altogether and rely on the chain being correctly present in the extra certs of the context. I don't see a need for points 3 and 4. Points 1 to 3 are largely doing what it does now but properly. However it would require some changes to OpenSSL and some new APIs for example for new selectable purposes and trust settings for the chain build and (possibly) a new cert store. However option 4 easy to do and could be argued as being a bug fix. If the CA certs for the server cert are in a seperate list, the content of the cert chain is in control of the user. And if he doesn't want the root cert in the chain, he only has to exclude them in the config file. The actual bug is only because OpenSSL tried to be to smart and included in the list certificates it never was told to include... All I want to have is something like: build the list of server CA certs from the given file (or build by SSL_CTX_add_extra_chain_cert()) (in the order I give) and _don't_ include any other certificates... That's exactly what point 4 would do. You do something like: SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); at some stage and it would then just use the supplied certificate(s) in SSL_CTX_add_extra_chain_cert(). 5. Cache the path after it has been determined. Or build it one time and reuse it... Which leads to the interesting problem of when to build the chain. If its done on first use this will result in configuration errors only being apparent after a client connects. On the other hand the way that the various certificates and stores are presented in arbitrary order, not to mention a new SSL_MODE_NO_AUTO_CHAIN flag makes it trickier to determine when its OK to build the chain. Of course the cached chain might also become invalid at some point in the future, such as when a certificate expires... Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 16:53:48 2003]: Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]: It really needs replacing with something less horrible. For example it might: 1. Build the chain using the normal certificate verify code including the usual checks on validity and using appropriate purpose and trust. 2. Give a (fatal?) error if the verification fails. 3. Include a flag to exclude the root CA from outputted chain 4. Include an flag to disable the automatic chain building altogether and rely on the chain being correctly present in the extra certs of the context. I don't see a need for points 3 and 4. Points 1 to 3 are largely doing what it does now but properly. However it would require some changes to OpenSSL and some new APIs for example for new selectable purposes and trust settings for the chain build and (possibly) a new cert store. OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() If the CA certs for the server cert are in a seperate list, the content of the cert chain is in control of the user. And if he doesn't want the root cert in the chain, he only has to exclude them in the config file. The actual bug is only because OpenSSL tried to be to smart and included in the list certificates it never was told to include... All I want to have is something like: build the list of server CA certs from the given file (or build by SSL_CTX_add_extra_chain_cert()) (in the order I give) and _don't_ include any other certificates... That's exactly what point 4 would do. You do something like: SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); at some stage and it would then just use the supplied certificate(s) in SSL_CTX_add_extra_chain_cert(). That are two different things: 1. build the chain with the certs from SSL_CTX_add_extra_chain_cert() 2. verify the chain is correct (trust settings OK, certs not expired,...) 5. Cache the path after it has been determined. Or build it one time and reuse it... Which leads to the interesting problem of when to build the chain. If its done on first use this will result in configuration errors only being apparent after a client connects. I think it should be done in SSL_CTX_add_extra_chain_cert(). But the return value contains to few information: only OK or failed. But the chain has 3 states: * error in cert chain * chain certs vaild but incomplete * chain certs valid and complete How integrate that in the actual interface ? since at least mod_ssl test for != 0, a quick solution would be: * error in cert chain = 0 * chain certs vaild but incomplete = 1 * chain certs valid and complete = 2 On the other hand the way that the various certificates and stores are presented in arbitrary order, not to mention a new SSL_MODE_NO_AUTO_CHAIN flag makes it trickier to determine when its OK to build the chain. As I suggested: Build it in SSL_CTX_add_extra_chain_cert() and return a different code for a complete chain... Of course the cached chain might also become invalid at some point in the future, such as when a certificate expires... Opens an other question: There are two validity models for cert chains: 1. A CA cert needs only to be be valid the moment the end entity cert is issued 2. A CA cert must be valid the complete life time of the end entity cert. In both cases you only have to check for expired CA certificates when you add a certificate to the chain... Becomes more complicated if you add OCSP... So you check the complete chain in SSL_CTX_add_extra_chain_cert() and check the host certificate when it is needed... But if you want to use the chain until any certificate in it expires, you can add a time stamp to it (this chain expires at ...) Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #492] SSL: server root certs and client auth.
[[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]: Hello Steve, OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() Perhaps I should clarify myself too :-) The current situation is not good. If the primitive auto chain building comes up with the wrong answer then there isn't any easy method I can think of that will allow it to fix things. Giving no certificate store at all and doing all its own verification might work but it's a hack. As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X. If it is decided that a 0.9.7X fix is needed then this should be a minimal bug fix solution that keeps the changes in functionality down to a minimum but gives the application some method of correcting things when the chain build breaks. For that maybe a new flag or possibly auto disable of the chain build if any extra certs are added. After all if the application is supplying extra certs it presumably is expecting the auto chain build to fail anyway? I can't see any legitimate reason for supplying extra certs *and* having auto chain build. The extra certs would be sent verbatim which is what 0.9.7 currently does anyway. Doing things properly will need new functionality and new functions and possibly break existing applications. As such that should be a 0.9.8 target. For example what purpose and trust settings do you use in the chain building? The defaults will be SSL server for servers and SSL client for clients but some applications might need something different which the current primitive chain build will handle but the correct version wont. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]: OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() Perhaps I should clarify myself too :-) The current situation is not good. If the primitive auto chain building comes up with the wrong answer then there isn't any easy method I can think of that will allow it to fix things. ACK Giving no certificate store at all and doing all its own verification might work but it's a hack. As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X. If it is decided that a 0.9.7X fix is needed then this should be a minimal bug fix solution that keeps the changes in functionality down to a minimum but gives the application some method of correcting things when the chain build breaks. ACK For that maybe a new flag or possibly auto disable of the chain build if any extra certs are added. After all if the application is supplying extra certs it presumably is expecting the auto chain build to fail anyway? I can't see any legitimate reason for supplying extra certs *and* having auto chain build. That confused me too. The extra certs would be sent verbatim which is what 0.9.7 currently does anyway. Doing things properly will need new functionality and new functions and possibly break existing applications. As such that should be a 0.9.8 target. ACK For example what purpose and trust settings do you use in the chain building? The defaults will be SSL server for servers and SSL client for clients but some applications might need something different which the current primitive chain build will handle but the correct version wont. I don't think that we should do there to much checks. We should check: * the validity period (begin end) of all certs * the trust settings for all certificates * the purpose for the CA certs I don't think we really should check the purpose of the own certificate. (At least not break if it doesn't matches.) A mismatching purpose should result in a warning but not in an error. But since OpenSSL has no warnings... If the purpose of the certificate doesn't match, the peer should decide if a connection is established. In special cases it is usefull to use a client cert for a server and a server key for a client. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #497] Bug report: openssl-0.9.7 make errors (no-ripemd, no-ssl2)
Hi,
I had some problems building 0.9.7 on win32 using masm and VC.
I used the no-ripemd no-ssl2 arguments to mk1mf.pl, and then tried to
make. Apparently some ripemd files were still included in the makefile. To
work around this, I changed mk1mf.pl in line 887 to the following:
elsif (/^no-ripemd$/) { $no_rmd160=$no_ripemd=1; }
After that everything, compiled right, but then I got linkage problems. The
new ocsp app doesn't handle well the OPENSSL_NO_SSL2. Line 735 reads:
ctx = SSL_CTX_new(SSLv23_client_method());
This should probably be replaced by:
#if !defined(OPENSSL_NO_SSL2) !defined(OPENSSL_NO_SSL3)
ctx = SSL_CTX_new(SSLv23_client_method());
#elif !defined(OPENSSL_NO_SSL3)
ctx = SSL_CTX_new(SSLv3_client_method());
#elif !defined(OPENSSL_NO_SSL2)
ctx = SSL_CTX_new(SSLv2_client_method());
#else
#error SSL is disabled
#endif
Please let me know if there is any reason this could cause any problems.
Cheers.
Tal
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
