Memory leaks in d2i_X509_CRL and X509_CRL_free?
Hi, I'm testing loading a large CRL file into a X509_CRL structure then free it. but after X509_CRL_free, there are still some mysterious memory consumption. pmap reports that total memory consumption is 105608KB right after the CRL file was loaded, and 88920K after X509_CRL_free was called. here is my test code: // gcc -o a -g a.c // ./a testcrl.pem // the crl file size is about 30M bytes, and itsformat is PEM #include stdio.h #include string.h #include sys/time.h #include time.h #include sys/syslog.h #include errno.h #include sys/vfs.h #include errno.h #define _GNU_SOURCE 1 #include math.h #include stdlib.h #include unistd.h #include openssl/objects.h #include openssl/evp.h #include openssl/x509.h #include openssl/bio.h #include openssl/pem.h void test4(const char* filename) { X509_CRL* crl = NULL; BIO* in = NULL; in = BIO_new_file(filename, r); if (!in) { return; } crl = PEM_read_bio_X509_CRL(in, NULL, NULL, NULL); if (!crl) { BIO_reset(in); crl = d2i_X509_CRL_bio(in, NULL); } BIO_free(in); // pmap: total 105608K if (crl) { X509_CRL_free(crl); // pmap: total 88920K } } int main(int argc, char* argv[]) { test4(argv[1]); return 0; } I am wondering why not all of the memory are freed, and how can I free those lost memory. Thanks very much. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Memory leaks in d2i_X509_CRL and X509_CRL_free?
the openssl library version is 1.0.1c, the operation system is debian linux. On Fri, Oct 26, 2012 at 8:05 PM, Zhuang Yuyao mli...@gmail.com wrote: Hi, I'm testing loading a large CRL file into a X509_CRL structure then free it. but after X509_CRL_free, there are still some mysterious memory consumption. pmap reports that total memory consumption is 105608KB right after the CRL file was loaded, and 88920K after X509_CRL_free was called. here is my test code: // gcc -o a -g a.c // ./a testcrl.pem // the crl file size is about 30M bytes, and itsformat is PEM #include stdio.h #include string.h #include sys/time.h #include time.h #include sys/syslog.h #include errno.h #include sys/vfs.h #include errno.h #define _GNU_SOURCE 1 #include math.h #include stdlib.h #include unistd.h #include openssl/objects.h #include openssl/evp.h #include openssl/x509.h #include openssl/bio.h #include openssl/pem.h void test4(const char* filename) { X509_CRL* crl = NULL; BIO* in = NULL; in = BIO_new_file(filename, r); if (!in) { return; } crl = PEM_read_bio_X509_CRL(in, NULL, NULL, NULL); if (!crl) { BIO_reset(in); crl = d2i_X509_CRL_bio(in, NULL); } BIO_free(in); // pmap: total 105608K if (crl) { X509_CRL_free(crl); // pmap: total 88920K } } int main(int argc, char* argv[]) { test4(argv[1]); return 0; } I am wondering why not all of the memory are freed, and how can I free those lost memory. Thanks very much. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Trouble with Windows DLL
1. Pardon my ignorance. So _Applink is a generic Windows facility, not OpenSSL-specific? Can you point me to a link or something that explains. I could not find anything. 2. While searching, I did find this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).as px It's a definitive explanation of a topic that was discussed here recently (this thread?): how does Windows determine which copy of a DLL to use? One thing of note: it is decidedly NOT true that if you put the DLL in the same folder as the EXE that is the one that will always get used. Ridiculously complex, but a definitive explanation, FWIW. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 25, 2012 2:00 PM To: openssl-users@openssl.org Subject: RE: Trouble with Windows DLL From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Wednesday, 24 October, 2012 19:08 The code for uplink looks to me like it looks for _Applink ONLY in the .exe It *HAS* to be a .exe? OpenSSL has logic that depends on what type of executable is calling it? If I had a .exe that worked with OpenSSL I could not necessarily turn it into a .DLL that exported services to calling programs? No, OpenSSL on Windows does not have logic that depends on the caller, that's why this DOESN'T work. The simplest upward dynamic lookup in Windows looks only in the .exe. In order to look in the .dll, OpenSSL would need more complicated code to figure out is that was called from a .dll and not the .exe, and WHICH particular .dll because you could have multiple .dll's compiled differently, and lookup there. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Creating X509 certificate subject alt name in C
On Thu, Oct 25, 2012, Ken Goldman wrote: I've managed to parse the odd X509 certificate I received. Now I have to create one. It should look like the below. X509v3 extensions: X509v3 Subject Alternative Name: critical DirName:/2.23.133.2.1=id:57454300/2.23.133.2.2=NPCT42x/NPCT50x/2.23.133.2.3=id:0391 X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: critical 2.23.133.8.1 I'm almost there with this code, but I don't know how to code the NID_subject_alt_name DirName extension. add_ext(x, NID_basic_constraints, critical,CA:FALSE); add_ext(x, NID_ext_key_usage, critical, 2.23.133.8.1); You first need to create an X509_NAME structure with the relevant field values in it. The function X509_NAME_add_entry_by_txt() is probably the easiest way to do that: you can then use that numerical OID form for the fields. Once you have that X509_NAME structure you need to add it to a GENERAL_NAMES_structure which is associated with Subject Alt Name. Finally you add that structure to the certificate using X509_add1_ext_i2d(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: sslv3 alert bad certificate:s3_pkt.c:1065:SSL alert number 42
From: owner-openssl-us...@openssl.org On Behalf Of Anamitra Dutta Majumdar (anmajumd) Sent: Thursday, 25 October, 2012 02:48 We are getting the following error when running the s_client. We are on openssl 0.9.8l What could be the possible cause of this error snip 4955:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: s3_pkt.c:1065:SSL alert number 42 4955:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure: s3_pkt.c:530: The server doesn't like the client certificate (chain) you sent. It didn't use one of the more specific alert codes to say what it disliked. Either ask the server operator(s) what it disliked, or if they have a stated policy about what certs they accept, examine your cert chain and compare to that policy. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_do_handshake() failed on openssl version 1.0.1c
Requested privately, but since I can't do much I'm throwing out what I can for anyone else to add to. -Original Message- From: Yan, Bob Sent: Wednesday, October 24, 2012 1:48 PM To: openssl-users@openssl.org Subject: RE: SSL_do_handshake() failed on openssl version 1.0.1c Dear Sir/Madam, I have used SSL_negotiate() and SSL_do_handshake() function to move the SSL connection into renegotiate state in my server side code. It works fine in openssl 1.0.0.a release. But after I upgraded the openssl library from version 1.0.0a to 1.0.1c, this code does not work. Basically the second call on SSL_do_handshake() function was failed with the error: error:0001:lib(0):func(0):reason(1). Following is my sample code: There is no SSL_negotiate in 1.0.1c, or any other version I have. There is SSL_renegotiate (and SSL_renegotiate_abbreviated, and SSL_renegotiate_pending) but not documented and I haven't used them and I don't have time to go through the code. I do see s_server.c has two cases of SSL_renegotiate followed by SSL_do_handshake, one followed by SSL_write (which I'd guess forces any needed handshake as it does for initial) and one not obviously followed by anything. All in parts of the program where there is a connection, see below. SSL *ssl_con = SSL_new(ssl_context); SSL_negotiate(ssl_con); SSL_do_handshake(ssl_con); ssl_con-state = SSL_ST_ACCEPT; SSL_do_handshake(ssl_con); Failed: error:0001:lib(0):func(0):reason(1). If that's actually SSL_renegotiate, it makes no sense. Renegotiation can only occur after a SSL connection exists, with a socket and an initial handshake. Directly changing things in an SSL object is almost always wrong. If there isn't an API that makes the change(s) you want, it probably is impossible, disallowed, unsupported or broken. That error doesn't look like an openssl error. It looks like a return code, or conceivably an OS/file error. Could somebody please show me how to resolve this issue? If it were me I'd look at -- and maybe debug -- s_server, which presumably works, to see what it does and how it works. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: sslv3 alert bad certificate:s3_pkt.c:1065:SSL alert number 42
Hi Dave, This is a close box without a server operator. Is there a way to determine why the cert chain was Disliked. Thanks, Anamitra On 10/26/12 3:14 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Anamitra Dutta Majumdar (anmajumd) Sent: Thursday, 25 October, 2012 02:48 We are getting the following error when running the s_client. We are on openssl 0.9.8l What could be the possible cause of this error snip 4955:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: s3_pkt.c:1065:SSL alert number 42 4955:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure: s3_pkt.c:530: The server doesn't like the client certificate (chain) you sent. It didn't use one of the more specific alert codes to say what it disliked. Either ask the server operator(s) what it disliked, or if they have a stated policy about what certs they accept, examine your cert chain and compare to that policy. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org