Re: Printing OpenSSL console error message in syslog
On 5/24/2013 7:02 AM, Rahul Godbole wrote: Hi, Is there a way in which I get have all OpenSSL error messages being printed in the syslog instead of console? Can I set some option or something else in OpenSSL for that? I am using OpenSSL 1.0.1c with fips 2.0.2. If you are using the OpenSSL Libraries in your own code, you have full control over the output of error messages, since your code will get them as strings through various APIs. If you are using the openssl command line tool, just pipe its stderr (and stdout for some commands) to the logger(1) program. For example: $ ( ( openssl whatever -whatever 13 ) 21 | logger -p local4.err ) 31 This redirects openssl stdout to temporary handle 3, then redirects openssl stderr to stdout and pipes it to logger. Finally the temporary handle 3 is redirected back to stdout of the whole thing. Another example: $ openssl whatever -whatever 21 | logger -p local4.info This redirects both openssl stderr and stdout to stdout then pipes it to logger which will pass it to syslog. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Release policy
Hello, I want to use OpenSSL in one of my project. As the project will run on production servers I'm wondering which branch should I use. Could you tell me what's the difference between OpenSSL 1.0.0 and 1.0.1 ? I'm guessing that 1.0.1 contains some experimental code, so is less suitable for production, but need to confirm my guessing. Regards, Krzysztof Kwiatkowski C++ Software Engineer, Service Integrator image/gif
openssl-1.0.1e RSA signature verification fails
Hi Openssl developers,
In our product we are using openssl source to some of the security
development. In our old product we were using openssl-0.9.8l and the product
is now in market. In our new product we upgraded our source base with
openssl-1.0.1e, we didnt change any thing in our application but the RSA
signature verification is failing when I comment the following portion of
code in p_verify.c file, it started working, May I have to clue what should
be set in our application to solve the issue with our modifying the openssl
code.
if (ctx-digest-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE)
{
i = -1;
pkctx = EVP_PKEY_CTX_new(pkey, NULL);
if (!pkctx)
goto err;
if (EVP_PKEY_verify_init(pkctx) = 0)
goto err;
if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0)
goto err;
i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len);
err:
EVP_PKEY_CTX_free(pkctx);
return i;
}
In the above mention code is commented now, in result RSA_Signature
verification is passing now. In this portion of code EVP_PKEY_CTX_new -
int_ctx_new -EVP_PKEY_meth_find -OBJ_bsearch_pmeth is the failure path.
OBJ_bsearch_pmeth returns zero,(openssl error is unsupported algorithms) but
OpenSSL_add_all_algorithms is already called in our application. To add to
this when I debugged type value received in EVP_PKEY_meth_find seems high
value 1179403647(in decimal), this is derived from the pkey-ameth-pkey_id
where as we dont set this value in our application.
In our application do we need to set something to avoid the failure. Thanks
in Advance.
Thanks,
Lavanya
--
View this message in context:
http://openssl.6102.n7.nabble.com/openssl-1-0-1e-RSA-signature-verification-fails-tp45250.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Hi
Hi Jakob, Thanks for your reply, please find the details given below and also please look topic which I have posted in the same forum today with the title openssl-1.0.1e RSA signature verification fails which will some more details. 1. How many bits are your RSA public key (the modulus), this is also the number of bits in the signature. It is 128 bits 2. Which hash algorithm (such as MD5 or SHA-256) is used by the signature you are trying to verify? It is SHA1 not sure whether it SHA-256(as such I am searching for the right algorithm string to pass to EVP_PKEY_asn1_find_str(tmpeng, algname, -1) function. 3. Which RSA padding scheme is used when converting the raw hash value into RSA input? For example are you using PKCS#1 v. 1.x padding, PSS (PKCS#1 v. 2.1), or one of the ISO 9796 schemes. Padding method is EVP_MD_CTX ctx EVP_MD_CTX_FLAG_PAD_PKCS1 Hope to get the answer for this. Thanks, Lavanya -- View this message in context: http://openssl.6102.n7.nabble.com/Hi-tp45235p45258.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NULL ptr deref when calling SSL_get_certificate with 1.0.0k
My product got hit by this bug too. ( it uses 0.9.8y branch). I understand the fix is in main branch, but I am curious - will 0.9.8 be patched eventually? -- View this message in context: http://openssl.6102.n7.nabble.com/NULL-ptr-deref-when-calling-SSL-get-certificate-with-1-0-0k-tp43636p45271.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hi
Hi Openssl developers,
In our product we are using openssl source to some of the security
development. In our old product we were using openssl-0.9.8l and the product
is now in market. In our new product we upgraded our source base with
openssl-1.0.1e, we didnt change any thing in our application but the RSA
signature verification is failing when I comment the following portion of
code in p_verify.c file, it started working, May I have to clue what should
be set in our application to solve the issue with our modifying the openssl
code.
if (ctx-digest-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE)
{
i = -1;
pkctx = EVP_PKEY_CTX_new(pkey, NULL);
if (!pkctx)
goto err;
if (EVP_PKEY_verify_init(pkctx) = 0)
goto err;
if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0)
goto err;
i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len);
err:
EVP_PKEY_CTX_free(pkctx);
return i;
}
In the above mention code is commented now, in result RSA_Signature
verification is passing now. In this portion of code EVP_PKEY_CTX_new -
int_ctx_new -EVP_PKEY_meth_find -OBJ_bsearch_pmeth is the failure path.
OBJ_bsearch_pmeth returns zero,(openssl error is unsupported algorithms) but
OpenSSL_add_all_algorithms is already called in our application. To add to
this when I debugged type value received in EVP_PKEY_meth_find seems high
value 1179403647(in decimal), this is derived from the pkey-ameth-pkey_id
where as we dont set this value in our application.
In our application do we need to set something to avoid the failure. Thanks
in Advance.
--
View this message in context:
http://openssl.6102.n7.nabble.com/Hi-tp45235p45274.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
encrypt Zip files
Hello everybody I have to encrypt a zip file with pkcs7. But when I decrypt again, the zip is corrupted and can't be opened. The zip contains a xml file, and encryption of this file is no problem. My command lines are: smime -encrypt -in file.zip -out file.p7m -outform DER cert.pem and smime -decrypt -in file.p7m -out file.zip -inform DER -recip cert.pem -inkey key.pem Is there any solution on this? I can't avoid dealing with the zip. The decrypted zip shows only 2/3 of the original length. Kind regards Rainer Schäferkordt Analogon Enterprise GmbH Geschäftsführer: Dr. Rainer Schäferkordt Neuengammer Hausdeich 511 21037 Hamburg Tel 040 73509358 Fax 040 73509361 www.analogon.net Handelsregister HRB 123138 Amtsgericht Hamburg USt-IdNr: DE283899011
Reg: The private key installation on the client side
Hi, I have tried to generate self-signed certificates using the openssl. While generating these certificates the private key is involved during the certificate signing process by the rootCA. 1. What is the actual purpose of this private key? 2. why this private key is installed in the client side? Waiting for your reply. Thanks, Keshav
Re: Using HMAC through EVP interface?
On Thu, May 23, 2013, no_spam...@yahoo.com wrote: Can one use HMAC through EVP? If so, can someone point me to an example? It seems that when the OpenSSL module is in FIPS mode, it doesn't like programs using HMAC_*() functions directly: OpenSSL internal error, assertion failed: Low level API call to digest SHA1 forbidden in FIPS mode! That shouldn't happen. The HMAC_* interface is used by the TLS code in FIPS mode so it does work. 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: Hi
On Thu, May 23, 2013, Lavanya wrote:
Hi Openssl developers,
In our product we are using openssl source to some of the security
development. In our old product we were using openssl-0.9.8l and the product
is now in market. In our new product we upgraded our source base with
openssl-1.0.1e, we didnt change any thing in our application but the RSA
signature verification is failing when I comment the following portion of
code in p_verify.c file, it started working, May I have to clue what should
be set in our application to solve the issue with our modifying the openssl
code.
if (ctx-digest-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE)
{
i = -1;
pkctx = EVP_PKEY_CTX_new(pkey, NULL);
if (!pkctx)
goto err;
if (EVP_PKEY_verify_init(pkctx) = 0)
goto err;
if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0)
goto err;
i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len);
err:
EVP_PKEY_CTX_free(pkctx);
return i;
}
In the above mention code is commented now, in result RSA_Signature
verification is passing now. In this portion of code EVP_PKEY_CTX_new -
int_ctx_new -EVP_PKEY_meth_find -OBJ_bsearch_pmeth is the failure path.
OBJ_bsearch_pmeth returns zero,(openssl error is unsupported algorithms) but
OpenSSL_add_all_algorithms is already called in our application. To add to
this when I debugged type value received in EVP_PKEY_meth_find seems high
value 1179403647(in decimal), this is derived from the pkey-ameth-pkey_id
where as we dont set this value in our application.
In our application do we need to set something to avoid the failure. Thanks
in Advance.
It's hard to say what the cause is without knowing how you are verifying the
signature in more detail. How are you initialising the EVP_PKEY structure?
If you are doing something non-portable like initialising EVP_PKEY manually
instead of using EVP_PKEY_assign_RSA that will cause problems.
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: encrypt Zip files
On Fri, May 24, 2013, Analogon Enterprise wrote: Hello everybody I have to encrypt a zip file with pkcs7. But when I decrypt again, the zip is corrupted and can't be opened. The zip contains a xml file, and encryption of this file is no problem. My command lines are: smime -encrypt -in file.zip -out file.p7m -outform DER cert.pem and smime -decrypt -in file.p7m -out file.zip -inform DER -recip cert.pem -inkey key.pem Is there any solution on this? I can't avoid dealing with the zip. The decrypted zip shows only 2/3 of the original length. Try the -binary option. 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: Release policy
On 5/23/2013 10:49 AM, Krzysztof Kwiatkowski wrote: Hello, I want to use OpenSSL in one of my project. As the project will run on production servers I'm wondering which branch should I use. Could you tell me what's the difference between OpenSSL 1.0.0 and 1.0.1 ? I'm guessing that 1.0.1 contains some experimental code, so is less suitable for production, but need to confirm my guessing. I cannot speak for the project, but the way I understand it, OpenSSL does not use the odd=experimental, even=stable rule of some other projects. Rather, experimental code is not released with a final version number at all (though there will obviously be a placeholder version number in the unreleased code). 1.0.1 contains additional features over 1.0.0, but almost no backward incompatibilities. 1.0.1a, b, c, etc. are patch releases that try to be as binary compatible (for documented APIs) with 1.0.1 as possible, and with no additional features from 1.0.1. There were some minor API adjustments in the 1.0.1 series to fix existing compatibility bugs. It should also be noted that the current FIPS certified module (meaningful only for US Government use) is designed for use with 1.0.1, while the previous one was for version 0.9.7 , which gives version 1.0.1 and artificially extended lifespan compared to other version series. There is some information on this subjects at http://www.openssl.org/news/state.html though that page contains some misprints and is a few months out of date (as is the main news page). I think the page should say something like: * Next proposed minor releases: OpenSSL 0.9.8z, 1.0.0l and 1.0.1f, currently in development. * The release date is yet to be set. * Next proposed FEATURE release: OpenSSL 1.0.2, currently in development. * Next proposed MAJOR release: OpenSSL 1.1.0, currently in development. * The release date is yet to be set. * The current CVS Source Code State http://www.openssl.org/source/cvs/ Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Release policy
On Fri, May 24, 2013, Jakob Bohm wrote: It should also be noted that the current FIPS certified module (meaningful only for US Government use) is designed for use with 1.0.1, while the previous one was for version 0.9.7 , which gives version 1.0.1 and artificially extended lifespan compared to other version series. Actually the previous FIPS module was for OpenSSL 0.9.8, the very first one was for 0.9.7. The current module should remain compatible with OpenSSL 1.0.x for x = 1. 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
Prefix “[openssl-users]” onto mailing list subjects?
Hi everyone, Would there be interest/approval in prefixing [openssl-users] onto the subject of messages from this list? This kind of thing is standard on most mailing lists of this kind that I’ve seen. It makes it easier to distinguish the “context” of a message at-a-glance. -F __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Prefix “[openssl-users]” onto mailing list subjects?
Since I find it much easier to read the posts with NNTP, it doesn't matter to me at all. The 'context' is in the name of the newsgroup. What I'd like is a way to remain part of the group but not receive email at all. I know it's technically possible, since other gmane newsgroups work that way. On 5/24/2013 9:16 AM, Felipe Gasper wrote: Hi everyone, Would there be interest/approval in prefixing [openssl-users] onto the subject of messages from this list? This kind of thing is standard on most mailing lists of this kind that I’ve seen. It makes it easier to distinguish the “context” of a message at-a-glance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Reg: The private key installation on the client side
On 5/24/2013 9:47 AM, keshava jm wrote: Hi, I have tried to generate self-signed certificates using the openssl. While generating these certificates the private key is involved during the certificate signing process by the rootCA. You are doing it wrong! 1. What is the actual purpose of this private key? The purpose is that ONLY the client has a copy, while everybody in the world may have a copy of the public key (for instance, there is one in the certificate). 2. why this private key is installed in the client side? Because the whole point is that ONLY the client has it, NEVER the CA (unless the CA is the client). Waiting for your reply. The intended and proper way to do things is: 1. The CA creates its own private key, which is kept in a very secure place (like a computer with no network connections, rigged with dynamite to self-destruct if tampered with and placed in a deep underground bunker surrounded by armed guards instructed to let no one (not even each other) inside except for the designated CA head signers, who must enter together to watch each other behaving properly. This is what VeriSign Inc (now part of Symantec) and GlobalSign Inc. did years ago, including the live explosives! For a private company CA, less extreme measures will do. 2. The CA (as the only person) uses its private key to create a self-signed certificate with the CA:TRUE attribute etc. This certificate will have a very long lifetime (decades usually). 3. The CA publishes, in some very hard to falsify place, like a huge stone monument, this certificate, or at least its strong check sum (SHA-256 or stronger). In the real world, a copy is hand carried to specific offices at Microsoft, Google and Mozilla who put the CA certificate into their next software updates. For a private company CA, the CA certificate is just installed on all the computers by the head sysadmin, using his boss privileges. 4. Each client creates his own private key, which he tries to keep secure as best he can. Then uses it to sign a request (e.g. with openssl req -new) specifying what he wants his certificate to say his name etc. is. 5. The client sends this request to the CA front office. Clerks at the CA front office then performs various checks to make sure the client really is whom he claims (in the request) to be, and that it is really him that requested this. If all is OK, they hand the request over to the CA head signers. For a private company CA, the clerks are just the regular IT or HR staff, who know all the employees and servers personally. 6. The CA head signers carry a pile of already proven requests they got from the clerks into the bunker and use commands such as openssl ca to create matching certificates signed by the CA's private key and listing the name of the CA's own certificate as the issuer, each certificate will also have a unique serial number. While they are there, they also sign a long list of all the certificates that have been cancelled until to date (a CRL). 7. The CA clerks send the signed certificates back to the clients. They also publish the list of cancelled certificates on their web site in a file format called a CRL. 8. The client now uses his certificate with his secret private key to sign stuff such as e-mails and checks, each signature includes a copy of his certificate. 9. Each person receiving the signed stuff has previously gone to the big stone monument and copied the genuine CA certificate into his computer. Once a day or so, they also download the latest list of cancelled certificates and checks that it was signed by the CA, and is dated today. When they receive the signed stuff, they check that it was signed in a way that matches the public key in the certificate, that the certificate itself was signed in a way that matches the public key in the CA's certificate and that the clients certificate is not on the cancelled list (there are other checks too, but the computer does all the work). If all is well, they believe that the stuff really came from the client and that the client is who the certificate says he is (because they trust the CA clerks to do this right). 10. If the clients private key is ever stolen, the client is required (by contract and/or law) to tell the CA clerks, who will add the certificate to the list of cancelled certificates so no one will believe signatures made by the thief. The same is done if the client loses his right to the certificate in some other way, e.g. a company employee being fired from the job position listed in the certificate, or a server being uninstalled. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones
Re: Prefix “[openssl-users]” onto mailing list subjects?
This is NOT a Gmame newsgroup. This is a mailing list run by the openssl people using their own servers. Gmame just makes a copy in a simulated newsgroup, but Gmame is not the real list, don't let them fool you. On 5/24/2013 4:29 PM, Ken Goldman wrote: Since I find it much easier to read the posts with NNTP, it doesn't matter to me at all. The 'context' is in the name of the newsgroup. What I'd like is a way to remain part of the group but not receive email at all. I know it's technically possible, since other gmane newsgroups work that way. On 5/24/2013 9:16 AM, Felipe Gasper wrote: Hi everyone, Would there be interest/approval in prefixing [openssl-users] onto the subject of messages from this list? This kind of thing is standard on most mailing lists of this kind that I’ve seen. It makes it easier to distinguish the “context” of a message at-a-glance. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Reg: The private key installation on the client side
Hi Jakob On Fri, May 24, 2013 at 11:57 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 5/24/2013 9:47 AM, keshava jm wrote: [snip] The intended and proper way to do things is: 1. The CA creates its own private key, which is kept in a very secure place (like a computer with no network connections, rigged with dynamite to self-destruct if tampered with and placed in a deep underground bunker surrounded by armed guards instructed to let no one (not even each other) inside except for the designated CA head signers, who must enter together to watch each other behaving properly. This is what VeriSign Inc (now part of Symantec) and GlobalSign Inc. did years ago, including the live explosives! For a private company CA, less extreme measures will do. 2. The CA (as the only person) uses its private key to create a self-signed certificate with the CA:TRUE attribute etc. This certificate will have a very long lifetime (decades usually). 3. The CA publishes, in some very hard to falsify place, like a huge stone monument, this certificate, or at least its strong check sum (SHA-256 or stronger). In the real world, a copy is hand carried to specific offices at Microsoft, Google and Mozilla who put the CA certificate into their next software updates. For a private company CA, the CA certificate is just installed on all the computers by the head sysadmin, using his boss privileges. 4. Each client creates his own private key, which he tries to keep secure as best he can. Then uses it to sign a request (e.g. with openssl req -new) specifying what he wants his certificate to say his name etc. is. 5. The client sends this request to the CA front office. Clerks at the CA front office then performs various checks to make sure the client really is whom he claims (in the request) to be, and that it is really him that requested this. If all is OK, they hand the request over to the CA head signers. For a private company CA, the clerks are just the regular IT or HR staff, who know all the employees and servers personally. 6. The CA head signers carry a pile of already proven requests they got from the clerks into the bunker and use commands such as openssl ca to create matching certificates signed by the CA's private key and listing the name of the CA's own certificate as the issuer, each certificate will also have a unique serial number. While they are there, they also sign a long list of all the certificates that have been cancelled until to date (a CRL). 7. The CA clerks send the signed certificates back to the clients. They also publish the list of cancelled certificates on their web site in a file format called a CRL. 8. The client now uses his certificate with his secret private key to sign stuff such as e-mails and checks, each signature includes a copy of his certificate. 9. Each person receiving the signed stuff has previously gone to the big stone monument and copied the genuine CA certificate into his computer. Once a day or so, they also download the latest list of cancelled certificates and checks that it was signed by the CA, and is dated today. When they receive the signed stuff, they check that it was signed in a way that matches the public key in the certificate, that the certificate itself was signed in a way that matches the public key in the CA's certificate and that the clients certificate is not on the cancelled list (there are other checks too, but the computer does all the work). If all is well, they believe that the stuff really came from the client and that the client is who the certificate says he is (because they trust the CA clerks to do this right). 10. If the clients private key is ever stolen, the client is required (by contract and/or law) to tell the CA clerks, who will add the certificate to the list of cancelled certificates so no one will believe signatures made by the thief. The same is done if the client loses his right to the certificate in some other way, e.g. a company employee being fired from the job position listed in the certificate, or a server being uninstalled. This is without question the best and clearest exlanation of all this. Thank you. Do you know of a web resource that explains this just as clearly and which adds information, such as what software is involved in each stage, and how it is used (yes, I have seen the Apache documentation for configuration to use client side certificates, but a reference manual is not the same as a textbook or tutorial). For example, I have seen, and am still investigating, the use of JavaScript in a client's browser to distribute client side certificates (obviously, involving a connection over HTTPS, to a site that requires single use credentials, issued by a RA, along with a series of challenge/responds question and answes to verify user
Pipe command not working
The | command don't work for me in OpenSSL. Is it a shell thing? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Pipe command not working
The | command don't work for me in OpenSSL. Is it a shell thing? Not enough details (heck not any) to answer. But yes, pipes are implemented by the shell. -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Pipe command not working
ah.. sorry. i tried running this command openssl x509 -noout -modulus -in server.crt | openssl md5 in openssl on windows and linux and it wont pipe back to Openssl. it says unknown option | On Fri, May 24, 2013 at 10:17 AM, Salz, Rich rs...@akamai.com wrote: The | command don't work for me in OpenSSL. Is it a shell thing? Not enough details (heck not any) to answer. But yes, pipes are implemented by the shell. -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Pipe command not working
Windows doesn't do pipes; you have to use temp files. -- Principal Security Engineer Akamai Technology Cambridge, MA
RE: Pipe command not working
_ From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Salz, Rich Sent: Friday, 24 May, 2013 14:05 To: openssl-users@openssl.org Subject: RE: Pipe command not working Windows doesn't do pipes; you have to use temp files. Not true. IIRC the original MSDOS-based Windows (3.1, 95, 98) didn't, but all NT series Windows do. I use Windows pipes all the time -- including for the sort of openssl commandline operations OP posted. One thing to watch out for, though, with C programs (including openssl): Standard/portable C makes a distinction between text and binary files. On Unix this distinction is erased; all files -- and all pipes -- are the same. On Windows however text files are written with C's newline \n converted to two bytes CR LF, and back to \n when reading; binary files are not. Mostly when accessing actual files -- even temporary ones -- programs get this right, but IME less often for pipes. And even though changing NL to CR LF generally has no effect on a person looking at the words and sentences in a text file, it has a catastrophic effect on hashing which by design is sensitive to any change at all even one bit. For piping one commandline openssl to another, using (as I do) the ShiningLight build and thus the visual c++ runtime, it has worked, but for arbitrary mixtures of other Windows programs I have had issues. One possibility: OP did say in openssl which is to me kind of ambiguous. If you run commandline *interactive*, it doesn't do pipes, on any OS: bash@myhost $ /path/to/openssl OpenSSL x509 -in somefile | md5 unknown option | usage summary OpenSSL C:\somedir \path\to\openssl OpenSSL x509 -in somefile | md5 unknown option | usage summary OpenSSL
server certificate verification fails
I add the server certificate in PEM format to the SSL store using the following call. X509_STORE_add_cert(SSL_CTX_get_cert_store(pctx), x509cert); The SSL_get_verify_result(SSL handle); always seems to return error code 20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Has anyone been able to get X509_V_OK code from the verify function? This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited.
