JSS library - PrivateKey.getEncoded() return NULL
When using a org.mozilla.jss.crypto.PrivateKey object, the getEncoded() method always return NULL. -Is the getEncoded method really implemented ? -Is there a way to get a byte[] array representing the private key ? -Must we convert the org.mozilla.jss.crypto.PrivateKey before encoding (PK11Key, Key, ...) ? Any help welcome. Thanks in advance.
mozilla can't connect to some https-sites
hi, i've discovered that mozilla up to 0.9.5 (build 2001101202) can't connect to some https-sites netscape navigator 4.77 can connect to, for example https://me.in-berlin.de/. with mozilla 0.9.5 i get an unknown SSL error (-8101), navigator 4.77 works fine. has anybody got an idea why? rj
PR_Cleanup hangs
After closing a SSL blocking socket and preparing to shutdown, I call: NSS_Shutdown(); PR_Cleanup(); PR_Cleanup, however, never returns. Any thoughts? Running on Win2K. Thanks, Mike Oliver Invertix
Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???
This can happen if you have set the SSL_ENABLE_FDX flag on the SSL socket, but do not have threads reading and writing simultaneously. Have you set SSL_ENABLE_FDX? -- Nelson Bolyard Netscape Disclaimer: I speak for myself, not for Netscape
Re: PR_Cleanup hangs
Mike Oliver wrote: After closing a SSL blocking socket and preparing to shutdown, I call: NSS_Shutdown(); PR_Cleanup(); PR_Cleanup, however, never returns. Any thoughts? Running on Win2K. It would be nice to use the debugger to see where PR_Cleanup is waiting. I suspect that it is waiting for all the user threads to terminate. Because of NSPR's past as the underpinnings of Netscape's port of Sun JVM, NSPR has the notion of user threads and system threads. This is the first argument to PR_CreateThread. If you call PR_Cleanup(), it will wait until all the threads created as PR_USER_THREAD have terminated. Wan-Teh
Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???
No, I have not set SSL_ENABLE_FDX. W/r/t options, all I have set is: SSL_SECURITY SSL_HANDSHAKE_AS_CLIENT Mike Oliver Invertix Nelson B. Bolyard [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This can happen if you have set the SSL_ENABLE_FDX flag on the SSL socket, but do not have threads reading and writing simultaneously. Have you set SSL_ENABLE_FDX? -- Nelson Bolyard Netscape Disclaimer: I speak for myself, not for Netscape
Re: PR_Cleanup hangs
I have two other threads running, but I did not create them using NSPR, but rather as Win32 ::CreateThread calls. Could this be causing the problem? Any other thoughts? Would you recommend that I download all the source and step into PR_Cleanup w/ the debugger? Thanks for all your help. Mike Oliver Invertix Wan-Teh Chang [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Mike Oliver wrote: After closing a SSL blocking socket and preparing to shutdown, I call: NSS_Shutdown(); PR_Cleanup(); PR_Cleanup, however, never returns. Any thoughts? Running on Win2K. It would be nice to use the debugger to see where PR_Cleanup is waiting. I suspect that it is waiting for all the user threads to terminate. Because of NSPR's past as the underpinnings of Netscape's port of Sun JVM, NSPR has the notion of user threads and system threads. This is the first argument to PR_CreateThread. If you call PR_Cleanup(), it will wait until all the threads created as PR_USER_THREAD have terminated. Wan-Teh
Re: PR_Cleanup hangs
Mike Oliver wrote: I have two other threads running, but I did not create them using NSPR, but rather as Win32 ::CreateThread calls. Could this be causing the problem? Any other thoughts? Would you recommend that I download all the source and step into PR_Cleanup w/ the debugger? If those threads call an NSPR function, they may be given an NSPR thread ID. If so, they would be considered a PR_USER_THREAD and PR_Cleanup would wait for their termination. In hindsight, these attached threads probably should be considered PR_SYSTEM_THREAD's. My suggestion is to not call PR_Cleanup(). It is okay to omit the PR_Cleanup() call. All the resources created by NSPR, such as file descriptors and memory allocated from the heap, are automatically cleaned up by the OS upon process exit. Wan-Teh
Re: mozilla can't connect to some https-sites
Robert Joop wrote: i've discovered that mozilla up to 0.9.5 (build 2001101202) can't connect to some https-sites netscape navigator 4.77 can connect to, for example https://me.in-berlin.de/. with mozilla 0.9.5 i get an unknown SSL error (-8101), Well, first of all, you should be getting a better error message than that. Error code -8101 is not a new error code. PSM should recognize it. SEC_ERROR_INADEQUATE_CERT_TYPE means that the server certificate (or one of the CA certificates in the server cert's chain) has some extension that says it is not able to be used for SSL server certificates. Perhaps this error could also be caused by lack of a trust flag for the root CA cert. navigator 4.77 works fine. has anybody got an idea why? I'll guess that your two browsers use different copies of the cert7.db and key3.db files. rj -- Nelson Bolyard Netscape Disclaimer: I speak for myself, not for Netscape
Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???
Mike Oliver wrote: Nelson B. Bolyard [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This can happen if you have set the SSL_ENABLE_FDX flag on the SSL socket, but do not have threads reading and writing simultaneously. Have you set SSL_ENABLE_FDX? No, I have not set SSL_ENABLE_FDX. W/r/t options, all I have set is: SSL_SECURITY SSL_HANDSHAKE_AS_CLIENT More questions: 1. What platform? 2. Is your program acting as an SSL server at any time? (The HANDSHAKE_AS_CLIENT would suggest not, but I have to ask) One way it could conceivably happen is as follows: SSL or NSPR might call some system function, other than send or recv, that normally does not block for a long time, but that is capable of retunring ETIMEDOUT (if Unix) or WSAETIMEDOUT (if Win32). The PR_INTERVAL_NO_TIMEOUT timeout value should prevent the underlying system send or recv call from returning ETIMEDOUT, but some other system call could unexpectedly return it, causing NSPR/NSS to return it as PR_IO_TIMEOUT_ERROR. This is just speculation, of course. Please continue to post any followup messages to this newsgroup. -- Nelson Bolyard Netscape Disclaimer: I speak for myself, not for Netscape
