Re: Please try today's snapshot
I've successfully compiled the 20010315 snapshot for the Win32 environment using VC++6.0 without any of the "warnings as errors" messages. All self tests appear to complete successfully. I've performed some initial tests of my software modules against both debug and release DLLs and things appear stable and execute correctly. Two thumbs up from me! :-) - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 10:28 AM Subject: Please try today's snapshot I'd like those who have reported problems with OpenSSL 0.9.6abeta1 to try tonights snapshots: openssl-0.9.6-stable-SNAP-20010314.tar.gz openssl-engine-0.9.6-stable-SNAP-20010314.tar.gz Of those reports, only the AIX problem with the engine variant and the Irix problem have not been dealt with. -- Richard Levitte \ Spannvgen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_write ..
- Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 16, 2001 5:49 AM Subject: Re: Problems with SSL_write .. From: Peter Sylvester [EMAIL PROTECTED] Peter.Sylvester Peter.Sylvester sprintf(szBuf, Peter.Sylvester"POST %s HTTP/1.0\r\nContent-Type: %sContent-Length: %d\r\n", Peter.Sylvester m_szURL, "text/html\r\n\r\n", nBytesToWrite); Peter.Sylvester Peter.Sylvester Due to the "text/html\r\n\r\n" the Content-length is already outside the header Peter.Sylvester Peter.Sylvester sprintf(szBuf, Peter.Sylvester"POST %s HTTP/1.0\r\nContent-Length: %d\r\nContent-Type: %s", Peter.Sylvester m_szURL, "text/html\r\n\r\n", nBytesToWrite); The best is probably to make all line-ends part of the format string: sprintf(szBuf, "POST %s HTTP/1.0\r\nContent-Type: %s\r\nContent-Length: %d\r\n\r\n",m_szURL, "text/html", nBytesToWrite); Yes, that's the way I do it in my code as well. When your code is parsing HTTP and your functions expect HTTP header data as parameters it's best to pass in strings not containing any "\r\n" newline chars. That way, you only have one line of code, the sprintf() call, responsible for properly formatting the HTTP headers prior to transmission... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: __declspec(dllexport) and __declspec(dllimport)
I'm forwarding a previous message concerning this issue: - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 04, 2001 11:50 AM Subject: Re: Windows, DLLs and variables. From: "Rob Neff" [EMAIL PROTECTED] neff.ra #ifdef MYDLL_EXPORTS neff.ra #define MYDLL_API __declspec(dllexport) neff.ra #else neff.ra #define MYDLL_API __declspec(dllimport) neff.ra #endif neff.ra neff.ra extern MYDLL_API int nTestdll; neff.ra neff.ra MYDLL_API int fnTestdll(void); That's basically what is in place in the current development source. I gotta ask you though, do function declarations really need to be prefixed that way too? We've seemed to do fine without that so far... The following is copied from MS VC++ 6.0 online help: - You do not need to use __declspec(dllimport) for your code to compile correctly, but doing so allows the compiler to generate better code. The compiler is able to generate better code because it knows for sure whether a function exists in a DLL or not, so the compiler can produce code that skips a level of indirection that would normally be present in a function call that crossed a DLL boundary. However, you must use __declspec(dllimport) in order to import variables used in a DLL. With the proper .DEF file EXPORTS section, __declspec(dllexport) is not required. __declspec(dllexport) was added to provide an easy way to export functions from an .EXE or .DLL without using a .DEF file. - Hope that helps, Rob __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ENGINE_load_key
[snip] Corinne Dive-Reclus, Principal Software Engineer Baltimore Technologies, Focus 31, West Wing,Cleveland Road, Hemel Hempstead, Hertfordshire, HP2 7BW, England Tel: +44 (0) 1442 342600 Fax: +44 (0) 1442 347399 E-mail [EMAIL PROTECTED] Website http://www.baltimore.com/ Just out of curiosity, why is a software engineer from Baltimore security products questioning OpenSSL usage? I was under the impression Baltimore sold their own commercial version of SSL enabled products. Forgive me for my ignorance of those products, but are you now using, or have you always used, OpenSSL within your product offerings? Again, just curious. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Incorrect MIME headers separators in 0.9.5a
I find this topic thread amusing in that I've encountered a similar issue located within Netscape's, err..iPlanet's Proxy server with regard to the insertion of HTTP headers into the stream. I discovered this during the testing of my https library (which uses OpenSSL of course!). The proxy was not terminating the inserted HTTP with CRLF as the RFCs dictate but was rather terminating with an LF only. Yes, I've read the "tolerance" section too but find it amusing that I had to patch my wonderful library to "tolerate" that server (which is their latest release) because they've failed to follow the spec completely. And yes I've also been in contact with their engineering dept to inform them of this oversight. I guess the bright side of all this is that if everything worked as spec'd, we'd be out of jobs, eh? Of course, all the code WE write doesn't contain any bugs. Uh huh... - Original Message - From: Emmanuel Gadaix [EMAIL PROTECTED] To: Jean-Marc Desperrier [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:07 AM Subject: Re: Incorrect MIME headers separators in 0.9.5a Lotus has of course been contacted, and I agree that it is mostly their mistake. But, considering they've been advertising S/MIME functionality for YEARS already, and that it still isn't working correctly (up to latest 5.06a release downloaded yesterday), I thought that the only hope to have interoperability would be to get a quick patch from OpenSSL. On 30/01/2001 13:53:29 Jean-Marc Desperrier wrote: I suggest Emmanuel that you contact Lotus and tell them about this bug in _their_ software. It fails to handle messages that have a correct MIME syntax (see RFC 2045, 2046, 2047), and it should be corrected for better interoperability. - Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows, DLLs and variables.
Regarding Windows DLL's and variables, the following is generated by the VC6 wizard for the DLL header file for just such a thing: #ifdef MYDLL_EXPORTS #define MYDLL_API __declspec(dllexport) #else #define MYDLL_API __declspec(dllimport) #endif extern MYDLL_API int nTestdll; MYDLL_API int fnTestdll(void); The above, when contained within the product's header file, accomplishes the necessary objective quite cleanly. To accommodate Unix/VMS/Windows, the defines may be wrapped by an #ifdef WIN32. Global variables are easily accessible via this mechanism. Of course, even though the DLL may be loaded only one time in memory, the global data it contains is NOT shared among multiple processes. The initial value may be the same for each process upon startup but modifications to the vars in one process are not seen by another process. Also, modify access to those vars by multiple threads within the same process must be synchronized... - Original Message - From: Toomas Kiisk [EMAIL PROTECTED] To: OpenSSL Development [EMAIL PROTECTED] Sent: Wednesday, January 03, 2001 4:37 AM Subject: Re: Windows, DLLs and variables. On Fri, 29 Dec 2000, Dr S N Henson wrote: AFAICS this needs a "DATA" declaration in the DEF file *and* a custom header declaration otherwise it doesn't work (linker errors or invalid data). The header declaration is where things get more interesting. When compiling code that is going to be linked into the DLL you need to precede the variable with: _declspec( dllexport ) however when linking to these variables you need: _declspec( dllimport ) So the declaration needs to be different according to whether the DLL code is being compiled or linked to. I did some testing, recording a symbol in EXPORTS section of DEF file exports it without __declspec(dllexport) hack (according to dumpbin /exports). I was even able to link a program against this library. However, it did not work without declaring imported symbol __declspec(dllimport). By the way, it appeared that DEF file DATA keyword is broken (or maybe it is just too poorly documented). I used m$ visual studio 6, SP3. -- vix __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Verification of server certificate
Gentlemen, After successfully establishing an SSL connection, I'm attempting to ascertain the validity of the server certificate received by the client. The server certificate received was signed by Verisign, yet the OpenSSL engine does not successfully validate it.The root certificates I loaded into the SSL_CTX using the function SSL_CTX_load_verify_locations() were the Class 3 Verisign certificates exported from IE 5.0. The interesting thing about this is that the issuer hash calculated using OpenSSL on the server certificate received is different that the hashes calculated on the exported certificates, yet IE still manages to accept the certificate as valid! The obvious question, at least for me, is does the OpenSSL library base its decision solely on the issuername hash when looking up the trusted CA root certificates or is IE doing something completely different, like not basing it's lookup on issuer hash but perhaps issuer CommonName? Can someone provide me with a code snippet, or point me in the appropriate direction, that outlines another way to verify certificates without using the issuer name hash? My concern is if Verisign, or any other CA, is creating server certificates using licensing terms or some other policy within the issuer name on a per-certificate basis yet using the original public and private keys to sign it.Would this explain why the issuer hashes don't match yet IE continues to validate the cert if IE does its lookup not based on issuer hash? Or am I way out in left field??? Thank you in advance for any assistance!
Re: Rescorla's book SSL and TLS
FWIW: I just picked up a copy myself from Barnes and Nobles so I know they carry it too... - Original Message - From: Dan Kegel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 20, 2000 12:30 PM Subject: Rescorla's book "SSL and TLS" I just got Eric Rescorla's book "SSL and TLS", and really like it. It's well written, easy to understand, and even explains not just SSL as it is, but how it came to be that way. It's a big improvement over earlier books, IMHO. Anyone who's been wishing there was a good SSL book, check it out. There's a link to it from http://www.kegel.com/ssl/#books - Dan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/evp bio_enc.c evp.h
Eh? Isn't the IV length the same as the block length? Nope. Rijndael's biggest IV is 16 bytes, but the biggest block is 32 bytes. I haven't checked why, so if someone wants to enlighten me... I too was under the assumption that the IV in use needed to be the same size as the block length. Since Rijndael encrypts at 128, 192, and 256 bits, the IV should be 16, 24, or 32 bytes in size. Not being a cryptography expert myself I'm afraid I provide little help to Ben's request. However, I DID notice that in the code downloaded from NIST that in the header file they specify a MAX_SIZE of 32 for the IV for cipher structure definition. However, the code in use is hard-coded 16 byte memcpy and pointer operations. Thus it appears that, no matter the size of block or key, the IV remains at 16 bytes for 128, 192, 256 bits keys. I think this has much to do with the following statement taken directly from the AES proposal, and I quote: 4. Specification Rijndael is an iterated block cipher with a variable block length and a variable key length. The block length and the key length can be independently specified to 128, 192 or 256 bits. Note: this section is intended to explain the cipher structure and not as an implementation guideline. For implementation aspects, we refer to Section 5. 4.1 The State, the Cipher Key and the number of rounds The different transformations operate on the intermediate result, called the State: Definition: the intermediate cipher result is called the State. The State can be pictured as a rectangular array of bytes. This array has four rows, the number of columns is denoted by Nb and is equal to the block length divided by 32. The Cipher Key is similarly pictured as a rectangular array with four rows. The number of columns of the Cipher Key is denoted by Nk and is equal to the key length divided by 32. I'd be curious to know what would happen to the IV code if the key size was increased beyond 256 bits as the proposal implies... For anyone wishing to see the code and spec for this cipher use the following link: http://csrc.nist.gov/encryption/aes/ (as if you guys don't know where it is! ;-) Hope this helps! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
From: Geoff Thorpe [EMAIL PROTECTED] Hi there, [snip] psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purposes, at the least. Hmm, perhaps you're right. I'm just a bit worried about how hard it might become if someone is stupid enough to actually use the returned (non-const) pointer to change something that is on RO memory... Exactly. Well, if I'm not mistaken - none of the current changes should involve returning non-consts pointers to const memory, and that is not even the issue at hand: in fact it's quite the opposite. The issue *is* (again, if I'm not mistaken) that we want the exposed API to be locked up a bit tighter with in-values being declared as "const" where in any sane world they should be (and thus, application programmers can benefit from the discipline that brings back into their own compilation checking) even though OpenSSL itself is in certain weird ways sometimes modifying what that "const" parameter was referring to. Bear in mind also that in *all* [snip] A clear and concise explanation for the justification of constifying the library - the API exposed to the applications programmer. What the library does internally with the memory should have no affect upon the calling application's state. If the function expects a const pointer, I will provide one and assume the buffer will not become "tainted" by the function on return. Should the function return a const pointer, I will not modify the contents pointed to by it. Viewed in this light, const is a form of contract between caller and callee. I know this is elementary to the readers of this mail group. My point is that if the constification can be made to the exposed APIs without causing undo performance degradation or code breakage then I'm for it. Even if only half of the exposed function parameters can be constifyed then that is at least self-documenting code which helps those of us from an "older" generation who's arms get sore continually reaching for API specifications because our neural memory banks are full . Thanks! ;-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSAref glue will go byebye!
Add another vote to the "remove RSAref code" column (and you may even bypass the 10 days waiting period for mail-in ballots, unlike certain current political processes in a large western hemisphere country that shall remain nameless...)! - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 08, 2000 10:22 AM Subject: RSAref glue will go byebye! OK, from what I understand, everyone agrees that the RSAref glue code can go. My first step will be to simply remove all references to it, while still leaving the rsaref/ directory in, if anyone would still be interested in it (actually, I'm toying with the idea of making it an engine that one could link into ones application, distributed as a completely separate library, just for demonstration purposes :-)). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
With regards to this current discussion, has anyone given thought to the
fact that if the const string address being passed into a function with a
const typed parameter resides within a memory page marked as ReadOnly the
constified function will GP should it attempt to write to that page? I'm
not sure of the behavior of every OS or compiler optimization or memory
layout currently in existence but the const modifier means just that: the
const address given to a function points to memory that will not, ever, be
modified. Functions that need to make temporary modifications within such a
string must make a local copy first.
My .02 cents worth...
- Original Message -
From: Lutz Jaenicke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 08, 2000 10:08 AM
Subject: Re: Constification
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker
wrote:
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1, s2);
}
Is that right? Both of those have problems. The first because you
can't manipulate the result even if the strings you gave from the
start are non-const, and the second because you can't give it a 'const
char *' as first argument...
HP-UX says:
char *strstr(const char *s1, const char *s2);
I read this: s1 and s2 are passed to strstr(). strstr() will not modify
the locations s1 and s2 are pointing to, so the optimizer may safely
assume that they have not been changed after the call to strstr().
That does not make any statement about what the calling function does
with s1 (and hence the return value _must_not_ be "const char *").
Sorry, couldn't resist :-)
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication
The client app in the demo does not include certificates. Examine the server app code and cut and paste the certificate code. That will enable your client app to send a certificate. To create a new certificate, at least how I did it on WinNT, was to run testss.bat after modifying the appropriate .cnf files. Hope this helps... - Original Message - From: Lakshminarayanan Venkatesan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 02, 2000 3:37 PM Subject: Client Authentication Hi, This problem may be old, but i am using SSL for the first time the demo client/server program inder openssl-0.9.6/demos/ssl directory is not authentication the client certificate. Please let me know how to create the certificate file for the client which gets authenticates at the server side when the server calls the client_cert = SSL_get_peer_certificate(ssl); The SSL_get_peer_certificate(ssl) at the server side returns NULL and so the server says "Client does not have the certificate." Pls help me resokve this problem. Waiting for ur reply asap. Thank you, --Laks __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL versioning change
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] [snip] Well, I'd say that a proof-of-concept does not lie in the version number, but rather in the use of the package and it's stability and feasability (sp?). One can look at a number of products out there with major version numbers higher than 1 that are full of features but unstable and unreliable. My suggestion is that you try to get away from the version number discussion, that's a lost battle already... [snip] Thank you for your succinct and well-thought reply. I am in agreement with you 100 percent! It is indeed simply a marketing-mentality issue I'm attempting to address. My apologies to yourself and others for not making myself clearer. I was hoping that a change in version would not have had the huge impact on binary or backward compatibility as I now know is the case. Perhaps I was simply looking for the easy answers and simple solutions. I now realize that it will take a little more persuasion and evangelism(sp) on my part! Again, thank you! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL versioning change
Gentlemen, Please accept the following suggestion for discussion. As a developer for a large financial institution I am attempting to determine the feasibility of using the functionality provided by the OpenSSL libraries in our commercial applications. I'm sure you are already aware that large corporations are reluctant to implement open-sourced products due to perceived accountability issues. This is a battle I am prepared to take on. However, to help in this regard I'm proposing a change of version to the next release of OpenSSL. To remain consistent with existing versioning schemes I would like to see a version scheme using a MAJOR.MINOR.BUILD whereas the next release of OpenSSL is not v0.9.7 but v1.1.0. The main reason for this request is due to the perceived "beta status" of any product with a major version of zero (0). This would help me tremendously in obtaining buy-in from corporate management. Finally, a MAJOR version of 1 and a MINOR version of 1 would indicate that included in this release are additional features (Rijndael) as well as bug fixes. Any bug fixes to a MINOR release should have the BUILD part incremented to reflect the latest "stable" release of that product. I'm hoping that you can accommodate this request and see that it will help in publicizing the project. I'm sure that once the version number is changed and a press release follows that the OpenSSL project will receive the increased interest and attention that you all deserve. Thank you.
Re: OpenSSL versioning change
Pointing out who has been using OpenSSL for how long should provide confidence in the software. If not, you surely can get a more appropriately numbered library from RSA Data Security. Allow me to restate my position. I am determing the feasibility of using open-source software within a commercial environment that typically has been opposed to shareware or open-source products. Understand that I am in favor of open-source development and am attempting to persuade non-technical types of the validity of open- source. Your comment appears to fluff off a valid concern of developers in the commercial sector attempting to make use of open-sourced software. We could indeed persue the route of obtaining the RSA library license as you previously appear to advocate. We could also persue obtaining licenses from Baltimore Technologies or various other commercial organizations selling SSL technology. Finally, any corporation, ours included, could even develop this technology in-house. However, the purpose of this discussion thread is not to determine the use of a particular software library based solely upon version number but rather to help those of us, in the trenches, trying to establish the open-source concept within a closed-source environment. By suggesting the version change to the OpenSSL library, I'm simply trying to address the preconceived notion of major releases with a version number of zero implying beta status by non-techies. In fact, questions regarding my proof-of-concept application with using OpenSSL as opposed to RSA have already surfaced. Again, please understand that I am in favor of open-source development and am asking for your help in trying to pursuade these individuals. You do not need to convince me of the technical merits of OpenSSL. I'm on board with you. I too know products which make use of it. Simply put, every little bit that you can do to help address some of the fears and preconceived notions is another step up the ladder for those of us trying to put open-source in it's rightful place. Thank you. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_load_verify_locations - can't get error string
I too experienced this behavior when attempting to use
ERR_print_errors_fp(),
but I encountered it while attempting a TLSv1 connection to an SSLv3 server
that subsequently caused that same exception in my server. I don't think
our
incidents are separate but rather perhaps a bug in the ERR_print_errors_fp
function???
- Original Message -
From: mail.s4u.local [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 19, 2000 10:58 AM
Subject: SSL_CTX_load_verify_locations - can't get error string
I am loading list of trusted CAs to client program. If it is not
successful
I want to print out errors simply like this:
/* Visual C++ 6.0, OpenSSL 9.6.0 */
if (! SSL_CTX_load_verify_locations(m_pSSL_Context, "cacert.pe_", NULL)) {
ERR_print_errors_fp(stderr);
}
When file can't be found, ERR_print_errors_fp(stderr) crashes:
First-chance exception in test_com.exe (NTDLL.DLL): 0xC005: Access
Violation.
In other cases this way of printing errors works fine.
--
Kamil
PS: what does the function SSL_CTX_set_default_verify_paths(SSL_CTX *) as
I
can see it in s_client.c??
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
TLSv1/SSLv3 error
Gentlemen, While testing OpenSSL functionality with a client and serverapp I wrote, I encountered the following issue: If the server code is using the SSL_METHOD SSLv3_server_method and the client is using TLSv1_client_method, the server fails tonegotiate connection. This does not happen when the server uses SSLv23_server_method. The .pod documentation states that SSLv3_server_method should successfully negotiate this connection but I cannot get this to work. I'm testing this on WinNT v4.0 service pack 5, using OpenSSL v0.9.6. Is anyone else aware of this problem?
