Hi,
The crash occurs with 0.9.8 because it wrongly calls the function "close"
instead of "closesocket" in order to release the client socket. In the
1.0.0 source, this has been corrected but the modification has not been
back-ported to the 0.9.8 source tree.
Also, the crash occurs only if you com
Thomas J. Hruska schrieb:
> Running 'openssl s_client' on 0.9.8n without any additional arguments
> crashes openssl.exe.
>
There is very different behavior between 0.0.8 and 1.0.0 on WinXP Pro SP3:
openssl version
OpenSSL 0.9.8j 07 Jan 2009
openssl s_client
Loading 'screen' into random sta
Victor Duchovni wrote:
On Sun, Apr 25, 2010 at 06:58:06PM -0700, Thomas J. Hruska wrote:
Running 'openssl s_client' on 0.9.8n without any additional arguments
crashes openssl.exe.
On a Linux system it reports a connection refused (to localhost:4433)
I realized after sending the e-mail that
er, wait. Lemme check something.
-inform PEM -in [filename].csr -days 1095 -out [filename].crt -config
../openssl.cnf
-Kyle H
On Sun, Apr 25, 2010 at 6:26 PM, Lou Picciano wrote:
> We've run into an interesting - apparently new? - behavior of the openssl ca
> command:
> I believe we've used th
The switch is -infile, not -infiles.
-Kyle H
On Sun, Apr 25, 2010 at 6:26 PM, Lou Picciano wrote:
> We've run into an interesting - apparently new? - behavior of the openssl ca
> command:
> I believe we've used the following command in the past (pre 1.0.0). (Don't
> know why we were still using
On Sun, Apr 25, 2010 at 06:58:06PM -0700, Thomas J. Hruska wrote:
> Running 'openssl s_client' on 0.9.8n without any additional arguments
> crashes openssl.exe.
On a Linux system it reports a connection refused (to localhost:4433)
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3,
Running 'openssl s_client' on 0.9.8n without any additional arguments
crashes openssl.exe.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/
__
We've run into an interesting - apparently new? - behavior of the openssl ca
command:
I believe we've used the following command in the past (pre 1.0.0). (Don't know
why we were still using the -infiles option with a single input file -
something vestigial, no doubt; Nonetheless, I think it's
Excellent. Problem solved.
Thanks,
YYK
On Sun, Apr 25, 2010 at 10:48 PM, Antoine Pitrou wrote:
>
> > The problem is in my include statements. The output of the following
> > test program is "OpenSSL version included is: 9466063" even when I
> > compile with -I/usr/local/ssl/include/openssl.
>
Hi All,
In Win64 environment socket descriptor is represented as a SOCKET data
type which in turn is an alias of UINT_PTR data type.
In functions like BIO_new_socket, SSL_set_fd, etc. socket is passed as
an argument of int data type.
In Win64 size of pointers is 64-bit but size of int's is 32-b
Hi Kyle,
regarding your hint:
> SSL[_CTX]_set_cipher_list((is_ctx ? ctx : ssl),"STRONG:@STRENGTH") is
> your friend. I believe it defaults to essentially "NONE", but I could
> be wrong on that one -- I just know that "unable to negotiate a shared
> cipher" means that the cipher list sent by the c
Kyle Hamilton wrote:
> 'no peer certificate available' is a different error than 'peer
> certificate did not verify'. This means that the TLS server is
> running without a certificate. (TLS and SSL do *not* require servers
> to provide certificates, but they do require that servers must provide
>
> The problem is in my include statements. The output of the following
> test program is "OpenSSL version included is: 9466063" even when I
> compile with -I/usr/local/ssl/include/openssl.
What if you try -I/usr/local/ssl/include/ instead?
__
Hi All,
I'm developing for Windows CE (6.0) and running into problems validating
PKCS7 Signatures created on Windows CE.
The same code running on Win32 creates valid Signatures. I noticed, that on
Win CE, the exact same payload with the exact same private key and
certificate creates signature whi
Hi all,
I downloaded and built OpenSSL 1.0.0 on OSX 1.5 PPC using the workaround
described in the PROBLEMS file. After restoring the .dylib files to their
original locations and adding /usr/local/ssl/bin to paths.d, I can execute
OpenSSL fine. openssl version tells me 1.0.0 (as expected).
The p
SSL[_CTX]_set_cipher_list((is_ctx ? ctx : ssl),"STRONG:@STRENGTH") is
your friend. I believe it defaults to essentially "NONE", but I could
be wrong on that one -- I just know that "unable to negotiate a shared
cipher" means that the cipher list sent by the client has a null union
with the cipher
'no peer certificate available' is a different error than 'peer
certificate did not verify'. This means that the TLS server is
running without a certificate. (TLS and SSL do *not* require servers
to provide certificates, but they do require that servers must provide
certificates before they ask f
Mounir IDRASSI wrote:
> Hi,
>
> Try adding the switch /Zi to the CFLAG in the makefile and rebuild the
> dlls. This is mandatory to create a full program database.
> I come across the same problem and I solved it with this. The perl
> scripts should be updated to include this flag for the debug bui
Hi,
Try adding the switch /Zi to the CFLAG in the makefile and rebuild the
dlls. This is mandatory to create a full program database.
I come across the same problem and I solved it with this. The perl
scripts should be updated to include this flag for the debug build.
Cheers,
--
Mounir IDRASS
Dear readers,
I know, it's great, sunny whether today, but may be someone would kindly
help, anyway ;-)
*Background:*
I'm just debugging some problem around SSL_CTX_load_verify_locations()
call in my particular environment. Since I'm not able to find the reason
for:
openssl.exe s_client -debug
Dear Stephen and dear all,
regarding Stephen's question below:
On Sat, Apr 24, 2010, Modem Man wrote:
Dear all,
I'm fiddling since two days with BIO_do_handshake(), and always have no
luck.
I'm afraid, it's time to cry for help now.
*Short description:*
After BIO_do_handshake(
21 matches
Mail list logo
