Fwd: [Foundations] 2013 Doc Camp CFP
Since people are always complaining about OpenSSL docs, I thought this might be of interest. -- Forwarded message -- From: adam a...@flossmanuals.net Date: 1 August 2013 08:23 Subject: [Foundations] 2013 Doc Camp CFP To: Foundations List foundati...@lists.freedesktop.org hi If any projects on the list are lacking good documentation (surely no one here ;) then consider applying for the 2013 Doc Camp. The CFP is open to any free software project or any individual to apply. Its a great event: http://www.flossmanuals.org/news/2013-doc-camp-call-proposals Apps close Aug 7. Not only is it productive (each project walks away with a book) its a heap of fun and great for building out your documentation volunteer base adam ___ foundations mailing list foundati...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/foundations __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3105] [PATCH] config matches OUT with full os/compiler line
OS: Linux ubuntu 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Version: 1.1.0-dev, since commit a59f43629583b4a73c3d28ddac2c3d5a49127ece Previously, config could match $OUT-$CC and $OUT with only part of a line output by ./Configure LIST, and would incorrectly think the value is valid. Now, it makes sure the entire line is exactly matched. --- config | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config b/config index a019f20..f793632 100755 --- a/config +++ b/config @@ -966,14 +966,14 @@ fi # compiler for the platform ... in which case we add it on # the end ... otherwise we leave it off -$PERL ./Configure LIST | grep $OUT-$CC /dev/null +$PERL ./Configure LIST | grep ^$OUT-$CC$ /dev/null if [ $? = 0 ]; then OUT=$OUT-$CC fi OUT=$PREFIX$OUT -$PERL ./Configure LIST | grep $OUT /dev/null +$PERL ./Configure LIST | grep ^$OUT$ /dev/null if [ $? = 0 ]; then echo Configuring for $OUT -- 1.7.12.1 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3101] [PATCH] Add CMP (RFC 4210) implementation
On 2.Aug.13 14:22, Stephen Henson wrote: On Fri Aug 02 10:23:05 2013, martin.pe...@nsn.com wrote: - the code in crypto/cmp also includes the functionality to perform the most important cmp message sequences via HTTP. This code depends on libcurl, so it is split into its own library (libcrypto_cmpseq.a) in order to help deal with the circular dependency when curl is also linked with openssl. There is some minimal HTTP code which the OpenSSL OCSP library uses and some functions to download certificates and CRLs. Could you use that and avoid the curl dependency? So far we've been using libcurl because we wanted a complete (and easy to use) HTTP implementation that would, for example, be able to make use of proxies and handle HTTP redirections properly. The minimal HTTP implementation in OCSP might also be sufficient for what's required by CMP. We will look into using that instead of libcurl, and get back to you. best regards, Miikka __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3101] [PATCH] Add CMP (RFC 4210) implementation
On 2.Aug.13 14:22, Stephen Henson wrote: On Fri Aug 02 10:23:05 2013, martin.pe...@nsn.com wrote: - the code in crypto/cmp also includes the functionality to perform the most important cmp message sequences via HTTP. This code depends on libcurl, so it is split into its own library (libcrypto_cmpseq.a) in order to help deal with the circular dependency when curl is also linked with openssl. There is some minimal HTTP code which the OpenSSL OCSP library uses and some functions to download certificates and CRLs. Could you use that and avoid the curl dependency? So far we've been using libcurl because we wanted a complete (and easy to use) HTTP implementation that would, for example, be able to make use of proxies and handle HTTP redirections properly. The minimal HTTP implementation in OCSP might also be sufficient for what's required by CMP. We will look into using that instead of libcurl, and get back to you. best regards, Miikka __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Unable to trust leaf Certificate
Thanks for the quick response, Steve. On 08/03/13 11:27, Dr. Stephen Henson wrote: On Fri, Aug 02, 2013, Misaki.Miyashita wrote: Hello, We have a server where its ServerCert is signed by an intermediateCA, which is signed by a RootCA. Currently, OpenSSL seems to require RootCA cert to be installed (in the certs dir) in order to connect to the server. We would like a feature where the leaf certificate (ServerCert) can be trusted if that particular cert is in the certs dir. Jordan Brown was in contact with Steve H. to find out that there is an experimental X509_V_FLAG_PARTIAL_CHAIN flag support in 1.0.2. We tried our experiment with 1.0.2 and X509_V_FLAG_PARTIAL_CHAIN. That helped some but does not seem to have addressed the need. I need some help understanding what's going on to resolve this issue. Here is my findings: Test 1: openssl verify -partial_chain ServerCert.pem - This is successful if the intermediate cert is installed: This is good. - Without -partial_chain, 'openssl verify' fails even if the intermediate cert is installed. - openssl stat()s for intermediate cert (success) and RootCA cert (fail) - check_trust() returns TRUSTED as last_untrusted(=1) is less than sk_X509_num(=2) - This fails if only the ServerCert is installed. - OpenSSL stats for the intermediateCA (fail) only. - check_trust() returns UNTRUSTED as last_untrusted(=1) is not less than sk_X509_num(=1) - We would like this case to be successful. Test2: openssl s_client -connect lc-sfbay-02:636 -partial_chain -CApath /etc/openssl/certs - This is successful if RootCA certificate is installed - openssl stat()s for RootCA cert (success) - This fails if RootCA is not installed even if ServerCert and/or intermediateCA is installed - openssl stat()s for RootCA cert (fail) only - check_trust() returns UNTRUSTED as last_untrusted(=2) is not less than sk_X509_num(=2) - We would like this case to succeed. Can I get some help figuring out what needs to be changed so that the leaf certificate (ServerCert) can be trusted? This works fine for me and the test certificate apps/server.pem . I'm not sure what the problem is unless you didn't call c_rehash or equivalent after you intalled the server certificate. Try using the -CAfile option too. I have digest.0 file linking to the .pem file in the certs dir. (Note: VS.pem is the root CA cert, oracle.pem is the intermediate CA cert, lc-sfbay-02.pem is the ServerCert) /etc/openssl/certs# ls -l total 103 drwxr-xr-x 2 root root 5 Jul 31 10:57 OLD -rw-r--r-- 1 root root1484 Jul 31 08:19 VS.pem lrwxrwxrwx 1 root root 15 Jul 31 11:14 f3c9bec7.0 - lc-sfbay-02.pem -rw-r--r-- 1 root root 0 Aug 1 10:38 last_untrusted++ -rw-r--r-- 1 root root1996 Jul 31 08:19 lc-sfbay-01.pem -rw-r--r-- 1 root root1996 Jul 31 08:19 lc-sfbay-02.pem -rw-r--r-- 1 root root2134 Jul 31 08:19 oracle.pem The following commands all fails with lookup:unable to get local issuer certificate % openssl verify -partial_chain -CApath /etc/openssl/certs lc-sfbay-02.pem % openssl verify -partial_chain -CAfile lc-sfbay-02.pem -CApath /etc/openssl/certs lc-sfbay-02.pem % openssl verify -partial_chain -CAfile f3c9bec7.0 -CApath /etc/openssl/certs lc-sfbay-02.pem When I trace each command, check_trust() return 3 (X509_TRUST_UNTRUSTED) because ctx-last_untrusted(=1) is not less than sk_X509_num(=1). Do you have any idea why the same test fails for us? Thank you -- misaki __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Unable to trust leaf Certificate
On Mon, Aug 05, 2013, Misaki.Miyashita wrote: Thanks for the quick response, Steve. On 08/03/13 11:27, Dr. Stephen Henson wrote: On Fri, Aug 02, 2013, Misaki.Miyashita wrote: Hello, We have a server where its ServerCert is signed by an intermediateCA, which is signed by a RootCA. Currently, OpenSSL seems to require RootCA cert to be installed (in the certs dir) in order to connect to the server. We would like a feature where the leaf certificate (ServerCert) can be trusted if that particular cert is in the certs dir. Jordan Brown was in contact with Steve H. to find out that there is an experimental X509_V_FLAG_PARTIAL_CHAIN flag support in 1.0.2. We tried our experiment with 1.0.2 and X509_V_FLAG_PARTIAL_CHAIN. That helped some but does not seem to have addressed the need. I need some help understanding what's going on to resolve this issue. Here is my findings: Test 1: openssl verify -partial_chain ServerCert.pem - This is successful if the intermediate cert is installed: This is good. - Without -partial_chain, 'openssl verify' fails even if the intermediate cert is installed. - openssl stat()s for intermediate cert (success) and RootCA cert (fail) - check_trust() returns TRUSTED as last_untrusted(=1) is less than sk_X509_num(=2) - This fails if only the ServerCert is installed. - OpenSSL stats for the intermediateCA (fail) only. - check_trust() returns UNTRUSTED as last_untrusted(=1) is not less than sk_X509_num(=1) - We would like this case to be successful. Test2: openssl s_client -connect lc-sfbay-02:636 -partial_chain -CApath /etc/openssl/certs - This is successful if RootCA certificate is installed - openssl stat()s for RootCA cert (success) - This fails if RootCA is not installed even if ServerCert and/or intermediateCA is installed - openssl stat()s for RootCA cert (fail) only - check_trust() returns UNTRUSTED as last_untrusted(=2) is not less than sk_X509_num(=2) - We would like this case to succeed. Can I get some help figuring out what needs to be changed so that the leaf certificate (ServerCert) can be trusted? This works fine for me and the test certificate apps/server.pem . I'm not sure what the problem is unless you didn't call c_rehash or equivalent after you intalled the server certificate. Try using the -CAfile option too. I have digest.0 file linking to the .pem file in the certs dir. (Note: VS.pem is the root CA cert, oracle.pem is the intermediate CA cert, lc-sfbay-02.pem is the ServerCert) /etc/openssl/certs# ls -l total 103 drwxr-xr-x 2 root root 5 Jul 31 10:57 OLD -rw-r--r-- 1 root root1484 Jul 31 08:19 VS.pem lrwxrwxrwx 1 root root 15 Jul 31 11:14 f3c9bec7.0 - lc-sfbay-02.pem -rw-r--r-- 1 root root 0 Aug 1 10:38 last_untrusted++ -rw-r--r-- 1 root root1996 Jul 31 08:19 lc-sfbay-01.pem -rw-r--r-- 1 root root1996 Jul 31 08:19 lc-sfbay-02.pem -rw-r--r-- 1 root root2134 Jul 31 08:19 oracle.pem The following commands all fails with lookup:unable to get local issuer certificate % openssl verify -partial_chain -CApath /etc/openssl/certs lc-sfbay-02.pem % openssl verify -partial_chain -CAfile lc-sfbay-02.pem -CApath /etc/openssl/certs lc-sfbay-02.pem % openssl verify -partial_chain -CAfile f3c9bec7.0 -CApath /etc/openssl/certs lc-sfbay-02.pem When I trace each command, check_trust() return 3 (X509_TRUST_UNTRUSTED) because ctx-last_untrusted(=1) is not less than sk_X509_num(=1). Do you have any idea why the same test fails for us? Try commenting out the next line: if (sk_X509_num(ctx-chain) == 1) The following code block checks for an exact match of the EE certificate, but it is currently only performed if there is only one certificate in the chain. Commenting out that lnie means it tries to match unconditionally. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Unable to trust leaf Certificate
Try commenting out the next line: if (sk_X509_num(ctx-chain) == 1) The following code block checks for an exact match of the EE certificate, but it is currently only performed if there is only one certificate in the chain. Commenting out that lnie means it tries to match unconditionally. Since there is an else branch to the if clause, I changed the code to if (1 || sk_X509_num(ctx-chain) == 1) instead of removing the check so that the if branch is always taken. Case1 : % openssl verify -partial_chain -CApath /etc/openssl/certs lc-sfbay-02.pem This command was not affected by the change since if (ctx-check_issued(ctx, x, x)), one line above the changed code, returned 0, and it didn't even get to the changed code. Case 2: %openssl s_client -connect lc-sfbay-02:636 -verify 9 -partial_chain -CApath /etc/openssl/certs With this code, the if branch is taken and it now calls X509_STORE_CTX_get1_issuer(). However, X509_STORE_CTX_get1_issuer() returns failure. When I traced the call, it trys to open c0ff1f52.0 which is root CA's certificate. I tried supplying -CAfile, but that didn't change any thing. % openssl s_client -connect lc-sfbay-02:636 -verify 9 -partial_chain -CAfile lc-sfbay-02.pem -CApath /etc/openssl/certs Any idea what's going wrong? Thank you -- misaki __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
