0.9.6g win2k linkage warning: duplicate advapi32 symbols
Hi, I statically link with both libcrypto and libssl, and I got this strange linker warning that I haven't gotten before: ssleay32.lib(ADVAPI32.dll) : warning LNK4006: __imp__WriteRaw@12 already defined in libeay32.lib(ADVAPI32.dll); second definition ignored Looking at the libs (and in the makefiles) it's obvious that both contain advapi32.lib. So it seems logical that I should get this warning. Two questions remain: 1. How come I've never gotten this warning with version 0.9.6a ? I don't see any relevant change in the makefile. 2. Why include advapi32.lib in the static libs anyways? If I understand correctly, both openssl libs use dynamic linkage (in crypto\bio\bss_log.c and in crypto\rand\rand_win.c) and obtain function pointers to advapi32.dll. Tal Mozes Security Research Team Leader Cyber-Ark Software Ltd. +972-8-920 7776 (ext. 224) www.cyber-ark.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: nonces?
Or use the trick we created for Identrus: make the nonce be the hash of the document that made you first do the OCSP query. That doesn't prevent a replay attack, in general, of course. If the document isn't public, then it's as good as arbitrary random bytes. If the document *is* public, then it would be interesting to analyze what replay would really mean given the timestamps within the OCSP message itself. /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: openssl-0.9.6e - configure error
Looks like the source code might have been corrupted during download to your machine. Did you check the md5 against the original .GZ ? That just doesn't look normal. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: August 24, 2002 1:03 PMTo: [EMAIL PROTECTED]Subject: openssl-0.9.6e - configure errorHi Can you tell me what to do here with this configure error? Number found where operator expected at ./Configure line 360, near "ver 02" (Might be a runaway multi-line "" string starting on line 358) (Do you need to predeclare ver?) MAC
Certificate Chain Error
I'm trying to access a secured page via ssl with a client side certificate and receive the verify error:num=19:self signed certificate in certificate chain message when I try to validate the certificate from the client using a standard openssl s_client command. (I've provided the syntax used and the output below.) My goal is to use the LWP libs along with the Crypt::SSLeay to access the secured page, but apparently my client verification is not succeeding as indicated when the s_client command is invoked. The platform used is HPUX 10.2 with OpenSSL version 0.9.6d. I have tried other release with similar results. I can validate the client certificate against the CA and that appears to work fine, so could someone tell me why this is failing and what might be suggested to alleviate the problem. As always, thanks for the help. s_client command and output: openssl s_client -connect memberplusone.deluxe.com:443 -cert cert.pem -key key.pem -state CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write certificate verify A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL3 alert read:fatal:certificate unknown SSL_connect:failed in SSLv3 read finished A 5408:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1031:SSL alert number 46 5408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Latest openssl for solaris 8
Im sure this has been asked but Im wondering If im On solaris 8 with openssl-0.9.6e for use with openssh-3.4p1. Do I need to upgrade to openssl-0.9.6g? What is the main reason/bugs for going from openssl-0.9.6e to openssl-0.9.6g? If anyone could give me some insight that would be great. Thanks Rob __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
encrypted PKCS1 format
When the dsa command is used to generate an encrypted dsa private key, it outputs a PEM encoded file. Does the PEM encoded file simply contain the Base 64 encoding of the ciphertext (which can be decrypted immediately) or does it contain an ASN.1 structure that has the ciphertext inside (and thus requires parsing)? Is it possible to generate an encrypted private key in DER output format? __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: nonces?
Rich Salz wrote: Or use the trick we created for Identrus: make the nonce be the hash of the document that made you first do the OCSP query. That doesn't prevent a replay attack, in general, of course. If the document isn't public, then it's as good as arbitrary random bytes. If the document *is* public, then it would be interesting to analyze what replay would really mean given the timestamps within the OCSP message itself. I was unclear - I meant as a general technique it doesn't - it may well be that it does given the properties of certain protocols, though unless you are guaranteed to answer the same at all points in the future, I don't see how the timestamp helps. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS#7 creation/signing question
On Mon, Aug 26, 2002, Michael Shmulevich wrote: Hello, I am sorry for troubling you with a (quite standard) question, but I cannot figure out my problem alone, and man page doesn't relly help me to solve a problem. I try to transfer an application in a secure way with PKCS#7 attachment. I took the 'openssl smime' as a utility since it looks like suits my needs. I have a chain of certificates with the following structure: Root CA -- CA -- Signer Certificate let's say I transfer a /bin/ls to someone. This is a command I used to create a PKCS#7 structure: $ openssl smime -sign -in /bin/ls -out ls.pkcs7.pem -outform PEM -binary -certfile root_ca.cert -certfile ca.cert -inkey sign.key -signer sign.cert The resulting PKCS#7 exibits all the required (three of them, including the signer certificate, CA and Root CA) certificates, when I try to run $ openssl pkcs7 -noout -text -print_certs -in ls.pkcs7.pem However, I cannot make it to verify the PKCS7, with no meaningful combination. These are two most successful tries: $ openssl smime -verify -in ls.pkcs7.pem -content /bin/ls -signer sign.cert -certfile ca.cert -CAfile root_ca.cert Verification Failure 9887:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:213:Verify error:unable to get local issuer certificate And: $ openssl smime -verify -in ls.pkcs7.pem -content /bin/ls -CAfile root_ca.cert -signer mfg_cvc.cert -certfile cl_cvc_ca.cert Verification Failure 9888:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:213:Verify error:invalid CA certificate Can someone enlighten me what I am doing wrong? I am intentionally not using the standard CA directory, since these certificates are hand-made for testing purposes. These commands suggest something is wrong with the certificate chain. Try using the verify command: openssl verify -CAfile rootca.pem -untrusted othercas.pem signer.pem where 'rootca.pem' contains the root CA and othercas.pem contains the intermediate CA. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: encrypted PKCS1 format
On Mon, Aug 26, 2002, Fiel Cabral wrote: When the dsa command is used to generate an encrypted dsa private key, it outputs a PEM encoded file. Does the PEM encoded file simply contain the Base 64 encoding of the ciphertext (which can be decrypted immediately) or does it contain an ASN.1 structure that has the ciphertext inside (and thus requires parsing)? The formats of all these are documented in the manual pages. In short traditional dsa PEM format include the ciphertext base64 encoded and some auxiliary info (salt, algorithm) placed in the PEM headers. The actual data encrypted is a non standard representation of the DSA key. Its what SSLeay used so its kept for compatibility. Is it possible to generate an encrypted private key in DER output format? Not using traditional format. It is however possible to convert the key to PKCS#8 format (using the pkcs8 utility) in DER format. The pkcs8 format is standard and follows the relevant specs. BTW none of this is PKCS#1 which deals with RSA only. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and JSSE?
Eric Rescorla wrote: Paul L. Allen [EMAIL PROTECTED] writes: JSSE stores keys and certificates in its own private format managed by a thing called keytool. In the JSSE documentation, no mention is ever made of a CA. Keys and certs are always generated as needed by keytool. To get my client its certificate, I had the Cylink CA generate a cert, downloaded it into my Netscape browser, exported that to a PKCS12 file, converted that to PEM and then to DER using the openssl x509 command, and then imported it into a JSSE keystore file using the keytool. A similar operation converted the CA's root certificate into a truststore file for use by JSSE. I've watched my Java client connecting to my OpenSSL server using ssldump. I can see the server's cert going over to the client. The client does not send its own cert over to the server, and the server confirms that it has not got a cert from the client. The client sends its first line of application data to the server and ssldump successfully decrypts it. The server receives binary garbage, and things unravel from there. What do you mean by the server receives binary garbage? The client sends 60 bytes (including the newline) of printable ASCII using BIO_puts(). The server does a matching BIO_gets(), which hangs apparently waiting for a newline. I kill the client. The server's BIO_gets() returns 90 bytes of non-printable binary. Perhaps the client is unhappy with its cert or the CA cert, but these certs (in PEM format) work fine with a test client coded in C. The client and server appear to be successfully negotiating a connection, but data coming out the server end is garbled. The fact that ssldump successfully decrypts data going over the connection suggests that the JSSE side is doing the right thing. But then, why is the JSSE side refusing to send its certificate? Puzzles, puzzles! Well, one question is: is the server asking for the client's certificate. Does ssldump show a CertificateRequest message from the server? In either case, this shouldn't cause bad decryption but just a handshake error. Perhaps an ssldump trace would be helpful to post. If I'm interpreting the trace right, the server is sending a CertificateRequest message. Ssldump does successfully decrypt the line of application data. A typescript of the ssldump session is attached. It's relatively hard to debug JSSE problems because you can't debug the code itself. Are you committed to JSSE or have you considered PureTLS? The guy who wrote the Java code probably picked JSSE because it was included with the JDK. I'll ask him if he's aware of PureTLS. Thanks for your thoughts. Paul Allen -- Boeing Phantom Works \ Paul L. Allen, (425) 865-3297 Math Computing Technology \ [EMAIL PROTECTED] POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group Script started on Mon Aug 26 11:01:24 2002 ]0;paula@bluesky:~/projects/policy_language/policy_parser[paula@bluesky policy_parser]$ ssldump -d -N -i lo -k server.pem port 4434 Enter PEM pass phrase: New TCP connection #1: bluesky.rt.cs.boeing.com(34735) - bluesky.rt.cs.boeing.com(4434) 1 1 0.0800 (0.0800) CS SSLv2 compatible client hello Version 3.1 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_RC4 TLS_RSA_WITH_DES_CBC_SHA SSL2_CK_DES TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_3DES TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 SSL2_CK_RC4_EXPORT40 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 1 2 0.1000 (0.0200) SC Handshake ServerHello Version 3.1 session_id[32]= 1c f6 89 06 3c 92 37 55 de 33 65 0f b6 7d 55 99 f0 02 b7 62 3a 62 4c 07 40 76 ca af ed f2 e4 e2 cipherSuite TLS_RSA_WITH_RC4_128_SHA compressionMethod NULL 1 3 0.1000 (0.) SC Handshake Certificate Subject C=US ST=WA L=Bellevue O=Phantom Works OU=mct CN=webtest.i2net.phantomworks.org [EMAIL PROTECTED] Issuer C=US ST=WA L=Bellevue O=Phantom Works CN=CA Server Serial 27 94 Extensions Extension: 2.16.840.113901.100.2.6 Extension: 2.16.840.113901.100.2.8 Extension: 2.16.840.113901.100.2.7 Extension: 2.16.840.113901.100.2.1 Extension: 2.16.840.113901.100.2.3 Extension: 2.16.840.113901.100.2.4 Extension: X509v3 Subject Key Identifier Extension: X509v3 Authority Key Identifier Extension: X509v3 Issuer Alternative Name Extension: X509v3 Key Usage Critical Extension: X509v3 Basic Constraints Subject C=US ST=WA L=Bellevue O=Phantom
Re: nonces?
I was unclear - I meant as a general technique it doesn't True. though unless you are guaranteed to answer the same at all points in the future, I don't see how the timestamp helps. OCSP includes a generatedAt timestamp, so the future doesn't matter. :) /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Man page error?
Hi - I was running through the man pages for the openssl command line. There are three examples for openssl passwd at http://www.openssl.org/docs/apps/passwd.html The first and last (crypto apr1) match what I get when I run the examples. But the second one doesn't return the result given in the example. I tried on a red hat 7.3 brand new install, and on the null beta. Is the man page correct? I also don't match what I see in the /etc/shadow file, so I certainly could be doing something wrong. Should doing openssl passwd -1 blah match what I see in etc/shadow if I set a password to blah? Tom __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and JSSE?
Paul L. Allen [EMAIL PROTECTED] writes: Eric Rescorla wrote: I've watched my Java client connecting to my OpenSSL server using ssldump. I can see the server's cert going over to the client. The client does not send its own cert over to the server, and the server confirms that it has not got a cert from the client. The client sends its first line of application data to the server and ssldump successfully decrypts it. The server receives binary garbage, and things unravel from there. What do you mean by the server receives binary garbage? The client sends 60 bytes (including the newline) of printable ASCII using BIO_puts(). The server does a matching BIO_gets(), which hangs apparently waiting for a newline. I kill the client. The server's BIO_gets() returns 90 bytes of non-printable binary. Hm... This is very surprising since SSL/TLS includes a MAC check on the data and therefore any crypto mismatches should result in errors, not receiving binary data. Is there any chance that you're BIO_gets() is on the native socket and not the OpenSSL BIO? If I'm interpreting the trace right, the server is sending a CertificateRequest message. Ssldump does successfully decrypt the line of application data. A typescript of the ssldump session is attached. Yes, that appears correct. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and JSSE?
Eric Rescorla wrote: Paul L. Allen [EMAIL PROTECTED] writes: Eric Rescorla wrote: I've watched my Java client connecting to my OpenSSL server using ssldump. I can see the server's cert going over to the client. The client does not send its own cert over to the server, and the server confirms that it has not got a cert from the client. The client sends its first line of application data to the server and ssldump successfully decrypts it. The server receives binary garbage, and things unravel from there. What do you mean by the server receives binary garbage? The client sends 60 bytes (including the newline) of printable ASCII using BIO_puts(). The server does a matching BIO_gets(), which hangs apparently waiting for a newline. I kill the client. The server's BIO_gets() returns 90 bytes of non-printable binary. Hm... This is very surprising since SSL/TLS includes a MAC check on the data and therefore any crypto mismatches should result in errors, not receiving binary data. Is there any chance that you're BIO_gets() is on the native socket and not the OpenSSL BIO? That possibly occurred to me as well, so I carefully checked out the code last week. It looked right. But since doing the BIO_gets() on the wrong BIO is the most likely explanation, I'll work it through one more time. If I'm interpreting the trace right, the server is sending a CertificateRequest message. Ssldump does successfully decrypt the line of application data. A typescript of the ssldump session is attached. Yes, that appears correct. Hmmm... When I watch a demo client and server with client authentication, I see the client's cert going over the wire. I wonder why I don't see it in the case of my real code? Would mis-matching the BIO on the server side explain this as well? Paul Allen -- Boeing Phantom Works \ Paul L. Allen, (425) 865-3297 Math Computing Technology \ [EMAIL PROTECTED] POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
pls help - Trying to create a pkcs12 cert req for sig by domino CA.
I have been unable to generate a cert request acceptable to a domino CA. Can anyone help with this ? I tried creating with req and feeding the pem files to pkcs12 but I get error messages: openssl req -newkey rsa:1024 -out certr.pem openssl pkcs12 -export -inkey privkey.pem -in certr.pem -out certr.pk12 Error loading private key 31508:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:662:Expecting: ANY PRIVATE KEY TIA Chuck Lyon UTS Enterprise Systems University Park PC 417A Florida International University Miami, FL 33199
Re: OpenSSL and JSSE?
Paul L. Allen [EMAIL PROTECTED] writes: Eric Rescorla wrote: Hmmm... When I watch a demo client and server with client authentication, I see the client's cert going over the wire. I wonder why I don't see it in the case of my real code? Would mis-matching the BIO on the server side explain this as well? No, I'm afraid not. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
error:140C5022:SSL routines:SSL_UNDEFINED_FUNCTION:called a function you should not call
Hi, I installed openssl-0.9.6c on a Unixware 7.1 box and I was playing with the demo programs saccept.c and sclient.c in openssl-0.9.6c/demos/bio directory. I compiled and started sclient on a Solaris 2.6 machine and saccept on the unixware one. Both programs worked fine. However, I was playing with saccept.c and moved the following lines into another function: OpenSSL_add_ssl_algorithms(); SSL_load_error_strings(); SL_CTX_new( SSLv23_client_method() ); and I called that function in main(), I got the follwoing error message: - 24152:error:140C5022:SSL routines:SSL_UNDEFINED_FUNCTION:called a function you s hould not call:ssl_lib.c:1654: 24152:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:s23_lib.c:180 -- If I move 'SL_CTX_new( SSLv23_client_method() );' back to main(), it works fine. Does anyone know what the problem is? Many thanks! Lance __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: nonces?
There's a good thread on webappsec list on securityfocus at the moment on this topic. Synchronicity! Matt __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Allowing both SSLv3 and TLS
If I want a server to accept either SSLv3 or TLS connections but not SSLv2 connections, do I use TLSv1_server_method() or SSLv3_server_method() or is this not possible? Thanks, Tim __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and JSSE?
Eric Rescorla wrote: Paul L. Allen [EMAIL PROTECTED] writes: Eric Rescorla wrote: Hmmm... When I watch a demo client and server with client authentication, I see the client's cert going over the wire. I wonder why I don't see it in the case of my real code? Would mis-matching the BIO on the server side explain this as well? No, I'm afraid not. I was afraid of that. More bugs in my code, no doubt. :-) I've discovered what was causing my server to malfunction. When I adapted your sample code to fit into my project, I changed it a bit based on my reading of the BIO_* man pages. (One should never meddle in the affairs of wizards!) Here is what my non-working code looked like, with irrelevant stuff like error checking removed: BIO *io; SSL *ssl; int sock,s; BIO *sbio; BIO *bbio; SSL_CTX *ctx; int r; ctx=initialize_ctx(KEYFILE,PASSWORD); load_dh_params(ctx,DHFILE); SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER, 0); sock=tcp_listen(); s=accept(sock,0,0); sbio=BIO_new_socket(s,BIO_NOCLOSE); bbio=BIO_new(BIO_f_buffer()); BIO_push (bbio, sbio); ssl=SSL_new(ctx); SSL_set_bio(ssl,sbio,sbio); r=SSL_accept(ssl); ... BIO_gets(bbio,...); The socket BIO is pushed onto the buffered BIO, and then the SSL is associated with the socket BIO. Should work fine, I'm thinking. (Yeah, right! Read the man pages one more time, Paul!) Here's the code that's now working after making it look very much like your sample code: BIO *io; SSL *ssl; int sock,s; BIO *sbio; BIO *ssl_bio; SSL_CTX *ctx; int r; ctx=initialize_ctx(KEYFILE,PASSWORD); load_dh_params(ctx,DHFILE); s=accept(sock,0,0); sbio=BIO_new_socket(s,BIO_NOCLOSE); ssl=SSL_new(ctx); SSL_set_bio(ssl,sbio,sbio); io = BIO_new(BIO_f_buffer()); ssl_bio = BIO_new(BIO_f_ssl()); BIO_set_ssl(ssl_bio, ssl, BIO_CLOSE); BIO_push (io, ssl_bio); r=SSL_accept(ssl); BIO_gets(io,...); So, I'm doing my I/O on the buffered BIO, which has an SSL BIO pushed on behind it. The SSL BIO has had its internal SSL pointer set to my SSL structure. Meanwhile, a socket BIO associated with the underlying TCP socket has been connected for both reading and writing to my SSL structure, but it is not pushed onto the chain of BIO's. Eric, I guess I just need to get the technical library to buy me a copy of your book and all will become clear. :-) The JSSE client-side authentication stuff is still not working. As you say, it's hard to debug something that's mostly opaque. We'll investigate PureTLS as an alternative to JSSE. Thanks! Paul Allen -- Boeing Phantom Works \ Paul L. Allen, (425) 865-3297 Math Computing Technology \ [EMAIL PROTECTED] POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Error using SSL_accept (unknown cause)
John don't if this has aleady been answered but u might be missing SSL_set_fd and SSL_set_accept_state(Function Name may not be correct but is somewhere around this) SSL_set_fd will be set with the sockfd which ur socketcall returned a -1 by SSL_Accept generally means that the lower layer (socket layer) has not been properly initialized though SSLv2_server_method() might do what SSL_set_acceptstate will do try explicitly setting it to server mode -SIGTERM amit John Cronin wrote: I have a server program running, which basically executes the following SSLCTX *sslctx; SSL *sslcon; STACK_OF(X509_NAME) *cert_names; socket() bind() listen() accept() SSL_load_error_strings() SSL_library_init() sslctx = SSL_CTX_new(SSLv2_server_method()) sslcon = SSL_new(sslctx) SSL_use_PrivateKey_file(sslcon, servkey.pem, SSL_FILETYPE_PEM) SSL_use_certificate_file(sslcon, servcert.pem, SSL_FILETYPE_PEM) cert_names = SSL_load_client_CA_file(cacert.pem) SSL_set_client_CA_list(sslcon, cert_names) SSL_accept(sslcon) now SSL_accept fails with the following: return value of SSL_accept = -1 SSL_get_error returned 5 (SSL_ERROR_SYSCALL) ERR_get_error returned 0 errno is 0 I have tried this with OpenSSL 0.9.6a 5 Apr 2001 (as preinstalled by my distribution (slackware 8.0)) and again after installing 0.9.6e with no change (openssl version reports that the new version is being used) I cant seem to use gdb to enter any of the SSL routines (do they use secured memory?) Thanks in advance, John [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- As flies to wanton boys are we to the gods; they kill us for their sport. -- Shakespeare, King Lear __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
