RE: s_server gethostbyname failure
Dave, thanks. calling code was supposed to replace d with a real value You are right, of course. Stupid programmer tricks. Turns out d is not the same thing as %d. Got that one solved. My client and my server code now make it through a certificate negotiation. Have not coded any farther as of today. I will look at your gethostbyname information. I do *have* the source code. (That's how I found the d problem.) I use gethostbyname/gethostbyaddr all the time, but who knows. Thanks again, Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, August 13, 2012 7:09 PM To: openssl-users@openssl.org Subject: RE: s_server gethostbyname failure From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Monday, 13 August, 2012 11:32 Found some things on the Web that led me to believe some programs choke when they get IPv6 addresses back from gethostbyname(), so I tried disabling IPv6 on Windows -- but no improvement. I have tried coding a server program more or less following the example in the O'Reilly OpenSSL book and the first BIO_do_accept() fails with 8276:error:02003AFC:system library:getservbyname:reason(2812):.\crypto\bio\b_sock.c:224:s ervice='d' which I am going to guess is the same problem. No, that's not the same problem. That says d is not a valid service (which in TCP means port). And it isn't. It looks like some calling code was supposed to replace d with a real value, probably a decimal number, but didn't. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of CharlesTSR Sent: Monday, August 13, 2012 9:15 AM I have exactly the same problem as http://old.nabble.com/s_server-and-gethostbyname-failure-error -td14675962.ht ml http://old.nabble.com/s_server-and-gethostbyname-failure-error -td14675962.ht ml . I have searched and don't find any replies. I run the following command: openssl s_server -accept 6514 -cert servercacert.pem -key servercakey.pem -state -debug -no_dhe OpenSSL responds Enter pass phrase for servercakey.pem: Loading 'screen' into random state - done Using default temp ECDH parameters ACCEPT When my client issues BIO_do_connect(conn) then openssl s_server fails with gethostbyname failure According to apps/s_socket.c that occurs if the address from which the client connected succeeds in gethostbyaddr (nominally reverse-DNS) but the resulting name fails in gethostbyname (nominally normal DNS). In my experience Windows often enhances DNS with data it decides would be helpful, and its decision isn't always perfect. There is nothing particularly unusual about the Windows 7 64-bit system on which openssl is running. I have used gethostbyaddr frequently with no unexpected errors. I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. Try a simple test program that does gethostbyaddr on the address your client is coming from and gethostbyname on the result, and see how they compare to what is correct for your network. Try running either your client code or s_client on other machine(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CA for IIS-issued self-signed certificate?
Dave - Thanks much! If the filename can't be opened SSL_CTX_load_verify_locations returns false. Your code does check for that, I hope. Good to know. Thanks. (Sometime APIs just stash a name somewhere for use later.) Yes, I check every return code and put out a good error message if the call fails. the Windows *API* has no problem with space in filename (unlike some Windows *UIs*). Like, say, VBA, or at least the MS-Word fields. And it actually accepts either slash or backslash separator Right, I knew that, but I should remember it with MS-Word (which I use a lot for documentation). Not having to escape \ would be a small step forward. Thanks. Make sure ... the Subject and Issuer names are *exactly* the same if your self-signed cert has a KeyUsage extension that does not include certSign, OpenSSL skips it for chain-building, resulting in verify 20. Looks like the latter to me. Please look below and tell me if you don't agree. If so, I fear it is unsolvable, but it does not really matter as the Kiwi is just for testing and if I know why it is failing that is almost as good as it succeeding. I can bypass the verify failure and use it to test everything else. My own client and server with a more conventional cert and CA setup is verifying. Here is a little of the s_client output: depth=0 /CN=KiwiServer verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=KiwiServer verify error:num=21:unable to verify the first certificate verify return:1 And here is the certificate -text Certificate: Data: Version: 3 (0x2) Serial Number: 62:72:81:ef:1c:37:e2:9b:4f:ce:08:bb:a6:bf:82:03 Signature Algorithm: sha1WithRSAEncryption Issuer: CN=KiwiServer Validity Not Before: Jul 27 21:05:20 2012 GMT Not After : Jul 27 00:00:00 2013 GMT Subject: CN=KiwiServer Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): snip Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication Signature Algorithm: sha1WithRSAEncryption snip -END CERTIFICATE- Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, August 13, 2012 7:09 PM To: openssl-users@openssl.org Subject: RE: CA for IIS-issued self-signed certificate? From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Saturday, 11 August, 2012 08:57 I wondered if perhaps there were path or filename specification problems (need to escape backslashes? a problem with embedded spaces?) but I eliminated all of those variables -- put the certificate with a simple name in the current path. If the filename can't be opened SSL_CTX_load_verify_locations returns false. Your code does check for that, I hope. FWIW, the Windows *API* has no problem with space in filename (unlike some Windows *UIs*). And it actually accepts either slash or backslash separator (and sometimes slash is more convenient). What do I look for? How do I get more granularity than unable to get local issuer certificate? Top-level cut: do you get the same error (verify 20) with s_client? If so, the problem is either the cert or the truststore, and you're confident of the truststore. Make sure the description as self-signed (or at least self-issued) is correct, i.e. the Subject and Issuer names are *exactly* the same. If s_client works, the problem is almost certainly (say 99.9%) in your code. This reminds me of one possibility that came up with someone else a few weeks ago: if your self-signed cert has a KeyUsage extension that does not include certSign, OpenSSL skips it for chain-building, resulting in verify 20. If you look at the cert with the usual Windows tools (inetcpl, CryptExtOpenCER, mmc) you should be able to see if KeyUsage is present and if so what is in it, or you can use commandline openssl x509 -text. If neither of the above, you probably do need to debug, but: I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. It will take some re-arrangement to be able to trace into OpenSSL. That's unfortunate. 64-bit Windows, if that matters. It shouldn't, but if there's a bug somewhere, it might. snip previous __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project
RE: s_server gethostbyname failure
OpenSSL s_server works without error if my client sends to localhost but not if it sends to the hostname of the machine. (Other than a name error because I have not re-done the server certificate.) I am calling that a totally satisfactory outcome as it works for me for testing. I consider this issue closed (although not technically resolved). Thanks for your help and patience. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, August 13, 2012 7:09 PM To: openssl-users@openssl.org Subject: RE: s_server gethostbyname failure From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Monday, 13 August, 2012 11:32 Found some things on the Web that led me to believe some programs choke when they get IPv6 addresses back from gethostbyname(), so I tried disabling IPv6 on Windows -- but no improvement. I have tried coding a server program more or less following the example in the O'Reilly OpenSSL book and the first BIO_do_accept() fails with 8276:error:02003AFC:system library:getservbyname:reason(2812):.\crypto\bio\b_sock.c:224:s ervice='d' which I am going to guess is the same problem. No, that's not the same problem. That says d is not a valid service (which in TCP means port). And it isn't. It looks like some calling code was supposed to replace d with a real value, probably a decimal number, but didn't. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of CharlesTSR Sent: Monday, August 13, 2012 9:15 AM I have exactly the same problem as http://old.nabble.com/s_server-and-gethostbyname-failure-error -td14675962.ht ml http://old.nabble.com/s_server-and-gethostbyname-failure-error -td14675962.ht ml . I have searched and don't find any replies. I run the following command: openssl s_server -accept 6514 -cert servercacert.pem -key servercakey.pem -state -debug -no_dhe OpenSSL responds Enter pass phrase for servercakey.pem: Loading 'screen' into random state - done Using default temp ECDH parameters ACCEPT When my client issues BIO_do_connect(conn) then openssl s_server fails with gethostbyname failure According to apps/s_socket.c that occurs if the address from which the client connected succeeds in gethostbyaddr (nominally reverse-DNS) but the resulting name fails in gethostbyname (nominally normal DNS). In my experience Windows often enhances DNS with data it decides would be helpful, and its decision isn't always perfect. There is nothing particularly unusual about the Windows 7 64-bit system on which openssl is running. I have used gethostbyaddr frequently with no unexpected errors. I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. Try a simple test program that does gethostbyaddr on the address your client is coming from and gethostbyname on the result, and see how they compare to what is correct for your network. Try running either your client code or s_client on other machine(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Size of ephemeral DH keys
Is there a correlation between the strength (size) of the asymmetric keys used to do the authentication and the strength (size) of the ephemeral DH keys generated/used to protect the session key (during the key exchange)? On first glance, in s3_srvr.c, it seems like the tmp_dh_callback() function is only ever passed keylength == [512, 1024] - the result of the SSL_C_EXPORT_PKEYLENGTH() macro. And a DH key of length 1024-bits is roughly equivalent to a 80-bit symmetric key. It seems strange that it would be using a 80-bit key to protect the exchange of a 128- or 256-bit symmetric session key. I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? More generally, is there a standard that defines or set of best practices that recommends the strength of ephemeral DH keys based on the cipher suite, strength (size) of the keys used for authentication, etc.? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Size of ephemeral DH keys
On Tue, Aug 14, 2012 at 12:23 PM, no_spam...@yahoo.com wrote: Is there a correlation between the strength (size) of the asymmetric keys used to do the authentication and the strength (size) of the ephemeral DH keys generated/used to protect the session key (during the key exchange)? Yes, there is. On first glance, in s3_srvr.c, it seems like the tmp_dh_callback() function is only ever passed keylength == [512, 1024] - the result of the SSL_C_EXPORT_PKEYLENGTH() macro. And a DH key of length 1024-bits is roughly equivalent to a 80-bit symmetric key. It seems strange that it would be using a 80-bit key to protect the exchange of a 128- or 256-bit symmetric session key. That's a classic Security Level mismatch. I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. More generally, is there a standard that defines or set of best practices that recommends the strength of ephemeral DH keys based on the cipher suite, strength (size) of the keys used for authentication, etc.? Yes, FIPS, ECRYPT, NESSIE, etc: * SP800-57, Part 1, Recommendation for Key Management, Section 5.6.1 * SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths * ECRYPT2 Yearly Report on Algorithms and Keysizes (2010) Also see http://www.cryptopp.com/wiki/Security_Level. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OpenSSL OCSP
Bonjour, Answers inline. -- Erwann ABALEA Le 14/08/2012 19:03, adrien pisarz a écrit : Hi, I have several questions about the ocsp functionnality. I read many articles before asking those questions and unfortunetaly I still don't have the answers. Maybe you can help me. Fist of all, here is my ocsp configuration : openssl ocsp -index index_prod.txt -CAfile OpCA.pem -rsigner ocsp.crt -rkey ocsp.key -port 3456 -text -out /home/userocsp/ocsp_responder.log The file index is populated by a self-made script, the ocsp.crt (resp. key) is a certificate (resp. key) which contains the ocsp signature extensions the OpCA.pem contains the subAC certificate Here are my questions : 1. Why the ocsp client work only if the -VAFile is set and otherwise I got a signature error ? Is there a way to solve this issue ? Maybe because the responder is not one of: - the CA that signed the certificate you're requesting the status on - a designated responder directly signed by the CA that signed the certificate you're requesting the status on Reread RFC2560. If you're instanciating the third possible responder type (trusted responder whose public key is trusted by the requester), then you obviously need to inform the client/requester. You didn't provide elements on who signed who, so that's just a guess. 2. If I wan manage several subAC should I open a port foreach subCA ? With the command-line tool, yes. If you need to have more CAs, then you could probably try something more suited than the command-line tools. The command-line tool also doesn't respond to GET requests, only POST ones. 3. Why the ocsp responder requires that all the certificates (even the valide's one) must be present in the index.txt in order to provide a correct answer ? I was expected that openssl will check the certificate signature and if the serial is not present in the index.txt, it will answer good and not unknow. Design choice. You're giving the responder a database, so it supposed to know *all* the certificates. OCSP can be based on CRLs (black-list), but that's not implemented by the tool. If that's what you want, you'll have to write your own. 4. As said, the openssl responder is working but a IHS server is not abble to validate his answer and I got those errors : [...] Does anyone know how to configure an IHS with an openssl ocsp responder ? You may ask your provider for this, not OpenSSL.
RE: [openssl-users] OpenSSL OCSP
Hi, Thanks for your reply and all the information provided. regarding the 3. question, you are right, I want to have an OCSP responder based on CRL. For information, the index file is written by parsing a CRL file but I don't want to write into this file all the valid certificates as an enrolment be done and my index file may not be synchronized. I have an other question, why the engine option is not available with the ocsp options ? It's not possible to have the key embeded in a HSM ? Regards,AdrienDate: Tue, 14 Aug 2012 19:35:12 +0200 From: erwann.aba...@keynectis.com To: openssl-users@openssl.org CC: apis...@hotmail.com Subject: Re: [openssl-users] OpenSSL OCSP Bonjour, Answers inline. -- Erwann ABALEA Le 14/08/2012 19:03, adrien pisarz a écrit : Hi, I have several questions about the ocsp functionnality. I read many articles before asking those questions and unfortunetaly I still don't have the answers. Maybe you can help me. Fist of all, here is my ocsp configuration : openssl ocsp -index index_prod.txt -CAfile OpCA.pem -rsigner ocsp.crt -rkey ocsp.key -port 3456 -text -out /home/userocsp/ocsp_responder.log The file index is populated by a self-made script, the ocsp.crt (resp. key) is a certificate (resp. key) which contains the ocsp signature extensions the OpCA.pem contains the subAC certificate Here are my questions : 1. Why the ocsp client work only if the -VAFile is set and otherwise I got a signature error ? Is there a way to solve this issue ? Maybe because the responder is not one of: - the CA that signed the certificate you're requesting the status on - a designated responder directly signed by the CA that signed the certificate you're requesting the status on Reread RFC2560. If you're instanciating the third possible responder type (trusted responder whose public key is trusted by the requester), then you obviously need to inform the client/requester. You didn't provide elements on who signed who, so that's just a guess. 2. If I wan manage several subAC should I open a port foreach subCA ? With the command-line tool, yes. If you need to have more CAs, then you could probably try something more suited than the command-line tools. The command-line tool also doesn't respond to GET requests, only POST ones. 3. Why the ocsp responder requires that all the certificates (even the valide's one) must be present in the index.txt in order to provide a correct answer ? I was expected that openssl will check the certificate signature and if the serial is not present in the index.txt, it will answer good and not unknow. Design choice. You're giving the responder a database, so it supposed to know *all* the certificates. OCSP can be based on CRLs (black-list), but that's not implemented by the tool. If that's what you want, you'll have to write your own. 4. As said, the openssl responder is working but a IHS server is not abble to validate his answer and I got those errors : [...] Does anyone know how to configure an IHS with an openssl ocsp responder ? You may ask your provider for this, not OpenSSL.
Re: Size of ephemeral DH keys
Thank you for the information and links. [stuff deleted] I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. I don't understand this comment. Are you suggesting that my application ONLY use what OpenSSL supplies as the value of the keylength parameter? And NOT use larger-than-1024-bit DH key sizes? Don't the standards and/or research suggest that larger key sizes SHOULD be used when appropriate? I guess what I'm asking is: what is the proper method for using larger ephemeral DH key sizes in OpenSSL? What I'm envisioning is something like the following: if the cipher suite and authentication key size info contained in the SSL structure require something stronger than 1024-bit ephemeral DH keys, use something bigger. And perhaps have an application override that can force the tmp_dh_callback to use 1024-bit for backwards compatibility. Does this make any sense? Or is the right answer not to use ephemeral DH cipher suites? The trade off being the lack of PFS for a more consistent security level. [stuff deleted] Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Size of ephemeral DH keys
On Tue, Aug 14, 2012 at 3:00 PM, no_spam...@yahoo.com wrote: Thank you for the information and links. [stuff deleted] I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. I don't understand this comment. Are you suggesting that my application ONLY use what OpenSSL supplies as the value of the keylength parameter? And NOT use larger-than-1024-bit DH key sizes? Don't the standards and/or research suggest that larger key sizes SHOULD be used when appropriate? The standards are sufficiently vague, and often [mildly] offends all parties. OAuth 2.0 editor resigns and takes name off spec, http://www.h-online.com/open/news/item/OAuth-2-0-editor-resigns-and-takes-name-off-spec-1654984.html. I guess what I'm asking is: what is the proper method for using larger ephemeral DH key sizes in OpenSSL? Ah, my bad. I'm not sure how to configure it on the client or the server. What I'm envisioning is something like the following: if the cipher suite and authentication key size info contained in the SSL structure require something stronger than 1024-bit ephemeral DH keys, use something bigger. And perhaps have an application override that can force the tmp_dh_callback to use 1024-bit for backwards compatibility. Does this make any sense? Yes. Or is the right answer not to use ephemeral DH cipher suites? The trade off being the lack of PFS for a more consistent security level. No, DHE is good since it ensures forward secrecy. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How do session accept timeout with OpenSSL
Thanks Dave for your time and patience. I am porting an existing Windows-based TCP/IP server (receive-only, not a Web server) to OpenSSL. The way it works with TCP/IP is it sets up a socket, binds it to the desired port, sets up a timeval, and issues a select. When the select is satisfied if the socket is ready it starts a thread that issues an accept and goes into a receive loop. Otherwise it does some housekeeping like checking for a quit flag. In any event it loops back around to the select. Pretty typical I think. Most of that ports fairly straightforwardly to OpenSSL. Not one to one, but pretty straghtforward: BIO_new_accept(), BIO_do_accept() * 2, BIO_pop(), SSL_setbio(), ... What about the select? Is there some sort of BIO_select()? Is there some way to do SSL on native sockets rather than BIO objects? BIO has (I think!) a regular system socket under the covers -- is there a supported API for getting that socket so I can do a select on it? Or do I have to re-write somehow with non-blocking sockets and/or using signals for my timeout rather than select()? Or ... ? I have tried getting TCP/IP bind and BIO_do/new_accept() to coexist but they don't want to share a port, and my BIO_do_accept fails in the absence of a preceding BIO_do/new_accept(). Thanks much. Tried searching for an answer but accept and bind and select are such common keywords, and most of the hits are either for select for determining when a socket is readable or writable, or for OpenSSL's session timeouts. -- View this message in context: http://old.nabble.com/How-do-session-accept-timeout-with-OpenSSL-tp34299004p34299004.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: Size of ephemeral DH keys
On Tue, Aug 14, 2012, no_spam...@yahoo.com wrote: Is there a correlation between the strength (size) of the asymmetric keys used to do the authentication and the strength (size) of the ephemeral DH keys generated/used to protect the session key (during the key exchange)? On first glance, in s3_srvr.c, it seems like the tmp_dh_callback() function is only ever passed keylength == [512, 1024] - the result of the SSL_C_EXPORT_PKEYLENGTH() macro. And a DH key of length 1024-bits is roughly equivalent to a 80-bit symmetric key. It seems strange that it would be using a 80-bit key to protect the exchange of a 128- or 256-bit symmetric session key. I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? The actual key length is only meaningful if the is_export parameter is non-zero. This a legacy from the days when there were export restrictions on strong crypto. If is_export is zero you are free to use whatever parameter length you consider appopriate but there is no guarantee the peer will support very large values. It is more common practice to use a fixed set of DH parameters through the SSL_CTX_set_tmp_dh API instead of using the callback. 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: [openssl-users] OpenSSL OCSP
On Tue, Aug 14, 2012, adrien pisarz wrote: For information, the index file is written by parsing a CRL file but I don't want to write into this file all the valid certificates as an enrolment be done and my index file may not be synchronized. I have an other question, why the engine option is not available with the ocsp options ? It's not possible to have the key embeded in a HSM ? You should note that the ocsp utility responder functionality is only meant to use used for test purposes. It isn't really usable as a full blown responder: it can only handle one request at a time for example. 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: fingerprint does not match on FIPS_mode_set when FIPS + openssl is dynamically linked into build
Eventually I solved this problem. Here is the set of commands I need to use to generate the shared fips-capable openssl libraries: su cd fips // wherever that may be ./config make make install // this installs fipscanister.o and adjacent files into /usr/local/ssl/fips-2.0/ cd openssl // still as root ./config fips shared make depend make make install // this installs libssl.so* and libcrypto.so* into /usr/local/ssl/lib // I couldn’t get ldconfig to work for me, so I did this export LD_LIBRARY_PATH=/usr/local/ssl/lib:$LD_LIBRARY_PATH When I make my tiny application, I use the following directive in my Makefile: DRIVER = encryption_driver #export FIPSLD_CC = gcc // don't need this for .so #export CC = fipsld // don't need this for .so CC = gcc CFLAGS = -Wall INCLUDES = -I/usr/local/ssl/include/ LFLAGS = -L/usr/local/ssl/lib LIBS = -lcrypto -lssl -ldl $(DRIVER): $(DRIVER).c $(DRIVER).h $(CC) $(CFLAGS) -o $@ $(INCLUDES) $(LFLAGS) $(LIBS) $^ Subsequently, a call to FIPS_mode_set in my encryption_driver returns without error. This was very difficult to debug in my actual product build sequence. Several executables are generated from the build and it turns out some were linking in an old version of openssl in some archaic location on the build machine (boo!) I made a lot of calls to ldd to discover this. Hopefully this is helpful to someone else out there... Cassie __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CA for IIS-issued self-signed certificate?
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Tuesday, 14 August, 2012 08:09 snip if your self-signed cert has a KeyUsage extension that does not include certSign, OpenSSL skips it for chain-building, resulting in verify 20. Looks like the latter to me. Please look below and tell me if you don't agree. If so, I fear it is unsolvable, but it does not really matter as the Kiwi is just for testing and if I know why it is failing that is almost as good as it succeeding. snip Certificate: snip X509v3 extensions: X509v3 Key Usage: Key Encipherment, Data Encipherment Yes, that's KeyUsage without certSign. Since problem-understood is sufficient for you in this situation, fine. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Elliptic Curve key generation help
Before you call generate_key, you need to initialize your EC_KEY with a curve:
EC_GROUP *group = EC_GROUP_new_by_curve_name(curve);
EC_KEY_set_group(testKey, group);
For 'curve' you could use, for example, NIST P256 which is defined with the
macro: NID_X9_62_prime256v1
You can then use these primitives to get the public and private keys:
EC_KEY_get0_private_key
EC_KEY_get0_public_key
Jason
On Aug 14, 2012, at 5:49 PM, Tom Leavy
tombu...@gmail.commailto:tombu...@gmail.com
wrote:
I have been trying to figure out how to generate an elliptic curve public
private key pair and can't find much information on how you properly do that.
So far I have done the following and I'm pretty sure I am missing a step
someplace.
void makeECCKeyPair() {
EC_KEY *testKey = EC_KEY_new();
EC_KEY_generate_key(testKey);
}
Re: Elliptic Curve key generation help
Last time I learnt how to generate ECC key, I use apps/ecparam.c as a
reference.
To get a feel on what the code is doing, I played with the openssl ecparam
utility.
Using the utility, I also created CSR (PKCS10), created self-signed
certificate, etc.
I hope this is helpful.
Erwin
On Tue, Aug 14, 2012 at 5:49 PM, Tom Leavy tombu...@gmail.com wrote:
I have been trying to figure out how to generate an elliptic curve public
private key pair and can't find much information on how you properly do
that. So far I have done the following and I'm pretty sure I am missing a
step someplace.
void makeECCKeyPair() {
EC_KEY *testKey = EC_KEY_new();
EC_KEY_generate_key(testKey);
}
Re: Elliptic Curve key generation help
Wow can't believe I already got an answer! Thanks so much guys I should be good
to go.
On Aug 14, 2012, at 6:59 PM, Jason Goldberg jgoldb...@oneid.com wrote:
Before you call generate_key, you need to initialize your EC_KEY with a curve:
EC_GROUP *group = EC_GROUP_new_by_curve_name(curve);
EC_KEY_set_group(testKey, group);
For 'curve' you could use, for example, NIST P256 which is defined with the
macro: NID_X9_62_prime256v1
You can then use these primitives to get the public and private keys:
EC_KEY_get0_private_key
EC_KEY_get0_public_key
Jason
On Aug 14, 2012, at 5:49 PM, Tom Leavy tombu...@gmail.com
wrote:
I have been trying to figure out how to generate an elliptic curve public
private key pair and can't find much information on how you properly do
that. So far I have done the following and I'm pretty sure I am missing a
step someplace.
void makeECCKeyPair() {
EC_KEY *testKey = EC_KEY_new();
EC_KEY_generate_key(testKey);
}
