Re: FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)
Mike Trent wrote: > > It seems that after setting FIPS mode off one cannot set it back on again > in the same executable. > > I have a test program which does: > > FIPS_mode_set(1) - works ok indicated by a return true. > FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call > returns 0, so it seems to be off. > > Then followed by again FIPS_mode_set(1) which returns a 0 indicating > failure. A FIPS_Mode() call indicates that the test program is still in > non FIPS mode. > > Is it possible to turn off FIPS and turn it back on in an executable? > > Thanks. > Ok... found the answer. One needs to make this call:RAND_set_rand_method(NULL); prior to making a FIPS_mode_set(1) after having turned off FIPS. -- View this message in context: http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121535.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
FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)
It seems that after setting FIPS mode off one cannot set it back on again in the same executable. I have a test program which does: FIPS_mode_set(1) - works ok indicated by a return true. FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call returns 0, so it seems to be off. Then followed by again FIPS_mode_set(1) which returns a 0 indicating failure. A FIPS_Mode() call indicates that the test program is still in non FIPS mode. Is it possible to turn off FIPS and turn it back on in an executable? Thanks. -- View this message in context: http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121412.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: WSAEWOULDBLOCK versus WSAECONNREFUSED
Md Lazreg wrote: > It is possible that the previous Windows behavior is correct but that > is not the behavior I want. I think you are incorrect about that. > I want the same behavior as UNIX which in my opinion is what my clients > would want. My clients can connect to a set of servers in a raw, if one > is not available for whatever reason I want them to move to the next one > instead of having to wait the whole timeout before trying the next server. I agree. But that's not what your code does now. What your code does is stops trying the first server. What you want it to do is start trying the second server. Here's probably what you want: 1) Start trying to connect to the first server. 2) Wait a short amount of time to see if we have a connection. 3) If we have a connection, we are done. We succeed. 4) If we don't have a connection, add another attempt to another server, if possible. 5) If all connection possibilities have failed, stop. We fail. 6) Go to step 2. Note that this does not require the change you made, which allows you to detect soft failures. If you get a soft failure, there is no reason to abort the attempt -- it still might succeed. And why would you want to wait 60 seconds or so if a server is not responding at all if you have another server you could try? > Thanks for your help. You're welcome. I'm glad you got it working the way you think you want it. But I don't think it's working the way you should want it. There is no rush to abort a connection attempt that might ultimately succeed, no matter how unlikely. Just don't wait for it -- keep going, and if it fails, no loss. If it succeeds later, you still win. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
With my new code, if my server is overloaded and cannot accept a connection immediately, my Windows client does not wait the whole timeout. This is the behavior I want. I do not want it to be sitting there just in case my server becomes available again or is on the process of being restarted. My original code was behaving like this: On UNIX: 1) Make a nonblocking connect call 2) I get EINPROGRESS 3) Do a select call that checks for writability of the socket [as man UNIX documentation says] 4) The select returns BEFORE the timeout and getsockopt shows me an error of ECONNREFUSED. [This is the behavior I want] On Windows: 1) Make a nonblocking connect call 2) I get WSAEWOULDBLOCK 3) Do a select call that checks for writability of the socket [as MSDN documentation says] 4) The select returns AFTER the timeout [This is the behavior I did not like because since my server is down I want my client to return immediately, I do not care if the server is going to be restarted, or if it was temporarily overloaded or else] My new code changes step 3) in the Windows code to check for writability and errorability by changing the following: status = select(m_sock_fd+1, NULL, &WriteSet, NULL, &tv); to this: status = select(m_sock_fd+1, NULL, &WriteSet, &ErrorSet, &tv); Now Windows and UNIX behave the same. When my server is down or overloaded, the select call in the Windows client puts the socket in the ErrorSet and returns immediately, calling the getsockopt show me an error of WSAECONNREFUSED. It is possible that the previous Windows behavior is correct but that is not the behavior I want. I want the same behavior as UNIX which in my opinion is what my clients would want. My clients can connect to a set of servers in a raw, if one is not available for whatever reason I want them to move to the next one instead of having to wait the whole timeout before trying the next server. Thanks for your help. On Mon, Aug 24, 2009 at 6:47 PM, David Schwartz wrote: > > Md Lazreg wrote: > > > On UNIX the select will return after signaling the write set > > [ as documented]. > > On Windows the select will return after signaling the _error_ > > set [The MSDN documentation says that you need to check the write set]. > > That makes no sense. > > > My problem was that my select was checking only for write-ability > > [which is what the documentation says for both Windows and UNIX]. > > So on Windows I was forced to timeout while on UNIX I was returning > > immediately. > > Your code was correct. > > > Now I changed my select to check for both write-ability and > > error-ability on Windows. Then I call getsockopt which returns > > WSAECONNREFUSED as I have been expecting. > > That makes no sense. I'm glad it's working for you, but that doesn't make > any sense. > > What does your code do now if the server is overloaded and cannot accept a > connection immediately? > > DS > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: WSAEWOULDBLOCK versus WSAECONNREFUSED
Md Lazreg wrote: > On UNIX the select will return after signaling the write set > [ as documented]. > On Windows the select will return after signaling the _error_ > set [The MSDN documentation says that you need to check the write set]. That makes no sense. > My problem was that my select was checking only for write-ability > [which is what the documentation says for both Windows and UNIX]. > So on Windows I was forced to timeout while on UNIX I was returning > immediately. Your code was correct. > Now I changed my select to check for both write-ability and > error-ability on Windows. Then I call getsockopt which returns > WSAECONNREFUSED as I have been expecting. That makes no sense. I'm glad it's working for you, but that doesn't make any sense. What does your code do now if the server is overloaded and cannot accept a connection immediately? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
add extension to an existing (signed) CA certificate
Hello, since Firefox 3.5 apparently doesn't accept Root CA self signed certificate which doesn't contain correct extensions (Basic Constraints: CA:TRUE) I wonder how I can add these extensions to my already existing and self signed Root CA : http://ca.institut-telecom.fr/pki/IT_MASTER_CA/itrootca.crt My second level (intermediate; http://ca.institut-telecom.fr/pki/IT_CA/itca.crt) CA does contain these extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA And it works fine with them. Apparently that was the case of verisign CA back to V1 certificate also .. http://www.drh-consultancy.demon.co.uk/nscertype.html http://unitstep.net/blog/2009/03/16/using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas/ From http://www.openssl.org/docs/apps/x509v3_config.html , I read DESCRIPTION Several of the OpenSSL utilities can add extensions to a certificate or certificate request based on the contents of a configuration file. So I suspect and hope that I can change, alter, my running root CA certificate !?, can you tell me how ? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
* David Schwartz wrote on Sun, Aug 23, 2009 at 15:40 -0700: > > My question is why _using the same code_ Windows is returning > > WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? > > while UNIX correctly returns ECONNREFUSED... > > Because Windows cannot tell whether your server is down or > [...] Nice summary and explanation, thank you. > Because Windows servers do not behave correctly, I think this suggests that replying a connect request with `tcp connection refused' would be wrong TCP server behavior, but as I understand, it is correct what Windows is doing: man listen(2) int listen(int s, int backlog); [...] The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that retries succeed. So unfortunately portable code cannot detect whether remote side has no listener (i.e. cannot detect whether the error is permanent or temporary). Personally I think this is itself is correct, because of course noone can tell that ever for sure (as David's server restart example shows), but customers keep requesting it and often code relies on that and behaves strangely. Steffen End of message. -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: Accessing unknown certificate extensions by OID
Hi and thanks for your continued help! Meanwhile I did indeed define the syntax of the extension and get my way through to the leaf being an ASN1_OBJECT representing the professionOID. Now my lack of knowledge strikes back: I want to check, whether a professionOID of "1.2.276.0.76.4.88" is included in the extension. What I get from i2d_ASN1_OBJECT(profoid, NULL) is plain and simple "9". I still fail to find the method that will present this notation of an OID... Mit freundlichen Grüßen / Kind regards Natanael Mignon Von: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] im Auftrag von Dr. Stephen Henson [st...@openssl.org] Gesendet: Samstag, 22. August 2009 13:50 An: openssl-users@openssl.org Betreff: Re: Accessing unknown certificate extensions by OID Yes you can call X509_EXTENSION_get_data() to get the encoded extension as an ASN1_OCTET_STRING structure. From that ASN1_STRING_length() and ASN1_STRING_data() will get you the data itself. Then it is ASN1 parsing time... there are numerous examples in the OpenSSL code itself, see crypto/cms/cms_asn1.c for a more recent one. Once you have an appropriate ASN1 module you can use d2i_foo() (or whatever you call it) to decode the data you extracted above. Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Thanks all. Both UNIX and Windows will return EINPROGRESS and WSAEWOULDBLOCK successively after a non blocking connect. [I was confused about this before but now I understand it.] The difference between UNIX and Windows is in the select system call that comes after the connect call. On UNIX the select will return after signaling the write set [ as documented]. On Windows the select will return after signaling the _error_ set [The MSDN documentation says that you need to check the write set]. My problem was that my select was checking only for write-ability [which is what the documentation says for both Windows and UNIX]. So on Windows I was forced to timeout while on UNIX I was returning immediately. Now I changed my select to check for both write-ability and error-ability on Windows. Then I call getsockopt which returns WSAECONNREFUSED as I have been expecting. Thanks again. On Mon, Aug 24, 2009 at 12:40 AM, David Schwartz wrote: > > Md Lazreg wrote: > > > When my SSL server is up and running everything works as expected. > > When my SSL server is down, my client times out in 20 seconds because > > WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not > listening! > > > I expect WSAGetLastError() to return WSAECONNREFUSED when my server > > is not listening... > > > The problem I have with this is that my client is forced to wait for > > 20 seconds before giving up. I expect it to return immediately if the > > SSL server is not listening... > > > Am I missing something? Thanks. > > Why? The SSL server might be restarting. Perhaps it will be listening again > in a second or two. It takes as long as it takes to ensure that the server > is not listening and will not resume listening. > > This is one of the differences between Windows and traditional UNIX > systems. > On Windows, if a server is overloaded, it refuses connections rather than > silently ignoring them. As a result, when a client gets a connection > refused, it cannot assume the server is not listening. It's possible the > server is overloaded. So it has to try again, which takes some time. > > > My question is why _using the same code_ Windows is returning > > WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? > > while UNIX correctly returns ECONNREFUSED... > > Because Windows cannot tell whether your server is down or overloaded. UNIX > assumes that it is down, which may or may not be correct. > > The Windows client behavior you are seeing is correct, but only because it > is assuming Windows server behavior that is incorrect. The UNIX behavior is > incorrect -- it cannot be sure your server is actually down, but assumes so > anyway -- but only because it assumes the server will behave correctly. > > Because Windows servers do not behave correctly, Windows clients are forced > to behave incorrectly. I have yet to figure out why things are this way, > but > this is the way they are. It appears to be a deliberate Microsoft decision > that we all have to live with. > > The summarize: When Windows server are overloaded, they reject connections > rather than ignoring them. Thus, a client that sees a rejected connection > cannot be sure the server is not running -- it could just be overloaded. > (So > you are correctly told the connection could not be made at that time, but > might succeed later.) > > It's also possible the server is restarting, and will be accepting > connections again in a second or two. The Windows client checks for this as > well. > > DS > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
