[FWD] Question
Forwarded for public discussion. Best regards, Lutz - Forwarded message from Ramon Madera ramonjmad...@yahoo.com - DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Proper ty:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfe r-Encoding:Mime-Version; b=lamw1PkA937XuY1GyWBvtWcY2aI2hGOY1+feuVXQ9NcdoTtaTQ0ZgGWyPyb/yK6ZX1vs+u Fgx5zpiUyrTA9mPVKYwjlJxqZYfuV4QSsB7Knzclrz73Ql0P55BXtQRsE8WRsn4RsdPAr3sK nrfInPz5Q+z3LyjQOCngxcM5NLkN4= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1285948859; bh=CMZ0mN+PYlrmbzXopbtTrQmFMHRgA24oYJjvQZFQdzI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Subject:From :Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime -Version; b=EDG3/auYD/ap6sWcuhMbTpHTzdGR7DhsfA2By1ohu0GZlzDzA3SKZFttASLM7eBn3HsJmB mSUgUGxfQHAc9lbJ2jxJsnuVPjGZZNu1P+9u/FXwjW+dl260zMZiLVuiOUGNjMJKCFdGobQ7 BGEpPFMGQm3+x3dKBmX1D6Xj7A7m0= Subject: Question From: Ramon Madera ramonjmad...@yahoo.com Date: Fri, 1 Oct 2010 11:59:56 -0400 To: r...@openssl.org r...@openssl.org Hello, My Name is Ramon Madera and I have a question related to md5 Why Am I not getting the same digest result when running the same command in windows vs unix? See below. openssl dgst - md5 -out string.dgst string.txt Thank you for your attention to this issue. Ramon Madera - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: LNK4078 and LNK4210 linking with x64 static libs
Thanks a lot, Jakob! Adding rdata align=8 to the section declaration in tmp32/x86_64cpuid.asm helped. At least the warnings disappeared, and *OPENSSL_ia32cap_loc() is now EFFB instead of 0. So, the instructions to build on windows x64 would be: * call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86_amd64 or open a Visual Studio 2005 x64 Cross Tools Command Prompt * perl Configure VC-WIN64A --prefix=c:\some\directory * ms\do_win64a.bat * Edit tmp32/x86_64cpuid.asm so that the third line reads: section .CRT$XCU rdata align=8 * nmake -f ms\nt.mak * nmake -f ms\nt.mak install Could someone fix this permanently in the perl script in crypto/perlasm that generates the section directive? Again, thanks! /Per Jakob Bohm wrote: Update, According to the NASM manual at http://www.nasm.us/doc/nasmdoc7.html#section-7.5.1 The following change to the generated .asm file should fix this without having to modify .obj files: Current: section.CRT$XCU Fixed: section.CRT$XCU rdata align=8 I have not yet tested this. On 23-09-2010 16:05, Jakob Bohm wrote: Actually, that section (specifically, the DQ line) places a single pointer constant in a data section with the magic name .CRT$XCU. Background: The Microsoft linker, upon seeing a $ sign in a section name will merge this section with all other sections name .CRT or .CRT$whatever, but only after it has ordered the layout of that section alphabetically according to the non-truncated section name. Thus the constants in .obj section .CRT$XCU will be placed between anything in sections .CRT$XCT (or less) and anything in sections .CRT$XCV (or more). The Microsoft C runtime startup code contains declarations for dummy NULL variables in sections .CRT$XCA and .CRT$XCZ and a loop which treats the data between those sections (including the DQ placed there by this ASM file and any constructors for C++ global variables etc.) as an array of function pointers to be called before invoking main(). A similar method (with a different letter after X is used for functions to call after main() returns or during a call to exit()). The above description matches at least the C runtime in Visual Studio 2005 (look at the files VC\CRT\src\crt0init.c and VC\CRT\src\crt0dat.c). Error message analysis: The warning complains that something in section .CRT has been given the section attributes 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (meaning Read, contains initialized data). Thus my guess is that the line section .CRT$XCU is lacking some keywords to tell the assembler to mark that section as read-only data, not code. Unfortunately, I am not sure of the syntax to do that in the x86_64 version of MASM. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, Thanks for your suggestion! But as far as I see, the assembler code in x86_64cpuid.asm _is_ the reference to OPENSSL_cpuid_setup! The runtime will call the functions given in the .CRT$XCU section before calling the main() entry. And it seems to me that the OPENSSL_cpuid_setup function in crypto/cryptlib.c does have useful code on Windows platforms, and so should be called, shouldn't it? It initializes a static variable with some processor specific info, whose value may be taken via the OPENSSL_ia32cap_loc() function. I tried printf(%lu, *OPENSSL_ia32cap_loc()), which prints out 0 using the x64 code, while printing 2951479295 using 32-bit code, indicating that OPENSSL_cpuid_setup has only been executed with the 32-bit code. What's the impact of this? Isn't it a bug? Cheers, Per Jack Zhang wrote: I had got the same problem. I just simply deleted that section EXTERN OPENSSL_cpuid_setup section .CRT$XCU ALIGN 8 DQ OPENSSL_cpuid_setup section .text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows with VS2005, using nt.mak to get static libraries. With x64 I get warnings when linking applications, both openssl.exe and test programs like sha1test.exe. A snippet of output from nmake -f ms\nt.mak: link /nologo /subsystem:console /opt:ref /debug /out:out32\openssl.exe @C:\DOCUME~1\FRYKEN~1\LOCALS~1\Temp\nm3B3.tmp LIBCMT.lib(crt0init.obj) : warning LNK4254: section '.CRT' (6020) merged into '.rdata' (4040) with different attributes And when linking our own application on x64/Release platform: libeay32.lib(x86_64cpuid.obj) : warning
Re: LNK4078 and LNK4210 linking with x64 static libs
On Mon, Oct 04, 2010, per frykenvall wrote: Thanks a lot, Jakob! Adding rdata align=8 to the section declaration in tmp32/x86_64cpuid.asm helped. At least the warnings disappeared, and *OPENSSL_ia32cap_loc() is now EFFB instead of 0. So, the instructions to build on windows x64 would be: * call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86_amd64 or open a Visual Studio 2005 x64 Cross Tools Command Prompt * perl Configure VC-WIN64A --prefix=c:\some\directory * ms\do_win64a.bat * Edit tmp32/x86_64cpuid.asm so that the third line reads: section .CRT$XCU rdata align=8 * nmake -f ms\nt.mak * nmake -f ms\nt.mak install Could someone fix this permanently in the perl script in crypto/perlasm that generates the section directive? Please send a report to the request tracker so it doesn't get overlooked. 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: [FWD] Question
Hello, Apart from a question of version of openssl, ? could it be for an End Of Line management difference between the two worlds : \n on unix \r \n on Windows Tricks exist with sed or tr to convert between the two. Best regards, Pierre Delaage Selon Lutz Jaenicke jaeni...@openssl.org: Forwarded for public discussion. Best regards, Lutz - Forwarded message from Ramon Madera ramonjmad...@yahoo.com - DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Proper ty:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfe r-Encoding:Mime-Version; b=lamw1PkA937XuY1GyWBvtWcY2aI2hGOY1+feuVXQ9NcdoTtaTQ0ZgGWyPyb/yK6ZX1vs+u Fgx5zpiUyrTA9mPVKYwjlJxqZYfuV4QSsB7Knzclrz73Ql0P55BXtQRsE8WRsn4RsdPAr3sK nrfInPz5Q+z3LyjQOCngxcM5NLkN4= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1285948859; bh=CMZ0mN+PYlrmbzXopbtTrQmFMHRgA24oYJjvQZFQdzI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Subject:From :Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime -Version; b=EDG3/auYD/ap6sWcuhMbTpHTzdGR7DhsfA2By1ohu0GZlzDzA3SKZFttASLM7eBn3HsJmB mSUgUGxfQHAc9lbJ2jxJsnuVPjGZZNu1P+9u/FXwjW+dl260zMZiLVuiOUGNjMJKCFdGobQ7 BGEpPFMGQm3+x3dKBmX1D6Xj7A7m0= Subject: Question From: Ramon Madera ramonjmad...@yahoo.com Date: Fri, 1 Oct 2010 11:59:56 -0400 To: r...@openssl.org r...@openssl.org Hello, My Name is Ramon Madera and I have a question related to md5 Why Am I not getting the same digest result when running the same command in windows vs unix? See below. openssl dgst - md5 -out string.dgst string.txt Thank you for your attention to this issue. Ramon Madera - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ 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
Hello!
Hello everyone! My name's Irving and I'm new to openssl. I'm having an issue and I hope I can get help here. I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? I tried googling and searching the mailing list archive, but didn't find any pointers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
64bit BIOs and support in OpenSSL
Does BIO support 64 bit IO (large files)? If so would the rest of OpenSSL (such as the ssl itself) support those BIOs? I configured the build with 64bit support and didn't see any noticeable changes. Specifically, I'd like to know if BIO_tell() is able to return a 64bit value? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
On Mon October 4 2010, irivas wrote: Hello everyone! My name's Irving and I'm new to openssl. I'm having an issue and I hope I can get help here. I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? Mike I tried googling and searching the mailing list archive, but didn't find any pointers. __ 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
RE: Hello!
I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 64bit BIOs and support in OpenSSL
On Mon, Oct 04, 2010 at 10:37:55AM -0400, Jeff Saremi wrote: Does BIO support 64 bit IO (large files)? If so would the rest of OpenSSL (such as the ssl itself) support those BIOs? I configured the build with 64bit support and didn't see any noticeable changes. Specifically, I'd like to know if BIO_tell() is able to return a 64bit value? No, BIO_tell() is a macro: include/openssl/bio.h: #define BIO_tell(b) (int)BIO_ctrl(b,BIO_C_FILE_TELL,0,NULL) The (int) cast means that the result is never larger than INT_MAX. If the library is compiled on a machine with 64-bit longs, then the underlying BIO_ctrl() will return the value from lseek() or ftell() cast to a (long). This does not imply that 64-bit files will not break in some other way. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ 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
RE: Hello!
To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
ASN.1 encoding will require much more than a simple sprintf. If your resulting string is expected to be encoded in ASN.1, then there may be a problem there. Pierre Le 04/10/2010 22:02, irivas a écrit : To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ 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 __ 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
RE: Hello!
I don't even know where those errors come from. As I said before, the same code under Solaris runs alright. I'm only connecting to a regular webserver with ssl, nothing more, nothing less. I'm not consciously using anything other than plain http-- none of which is used up to that point. Calls made beforehand are: SSL_load_error_strings(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* bio = BIO_new_ssl_connect(ctx);//bio is a BIO* BIO_get_ssl(bio,ssl); //ssl is a SSL* SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY); BIO_set_conn_hostname(bio,buffer);//buffer is a string of the form host:portnumber Anything I should be doing? The error occurs immediately afterwards. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 4:15 PM To: openssl-users@openssl.org Subject: Re: Hello! ASN.1 encoding will require much more than a simple sprintf. If your resulting string is expected to be encoded in ASN.1, then there may be a problem there. Pierre Le 04/10/2010 22:02, irivas a écrit : To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ 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 __ 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OCSP Success even cert alredy expired
Hi all, i using openssl test tool by using this command openssl.exe ocsp -issuer issuer.pem -CAfile CACert.pem -cert Certificate.pem -url http://192.168.0.235:8080/myCA/publicweb/status/ocsp my CACert and issuer cert already expired. but it still return me respond verify OK. i see in my ca server. it show me error cannot found in database do i did a wrong command? -- View this message in context: http://old.nabble.com/OCSP-Success-even-cert-alredy-expired-tp29883947p29883947.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
VMS client ASN1 decoding error, was RE: Hello!
From: owner-openssl-us...@openssl.org On Behalf Of irivas Sent: Monday, 04 October, 2010 16:36 (I changed the subject to be more descriptive.) I don't even know where those errors come from. As I said before, the same code under Solaris runs alright. I'm only connecting to a regular webserver with ssl, nothing more, nothing less. I'm not consciously using anything other than plain http-- none of which is used up to that point. Calls made beforehand are: SSL_load_error_strings(); ERR_load_BIO_strings(); Aside: this is redundant. SSL_load_error_strings includes ERR_load_crypto_strings which includes all active modules which includes BIO. But it does no harm. OpenSSL_add_all_algorithms(); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* I assume foldername (without the stray ) is a VMS directory, which to my recollection doesn't have folders. Does the rehash procedure or an equivalent work on VMS, and was it done here? If not, that will cause verification errors later (but at present you're not even getting to verification). bio = BIO_new_ssl_connect(ctx);//bio is a BIO* BIO_get_ssl(bio,ssl); //ssl is a SSL* SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY); BIO_set_conn_hostname(bio,buffer);//buffer is a string of the form host:portnumber Anything I should be doing? The error occurs immediately afterwards. Unless the webserver is selectively misencoding, which seems very unlikely, there may be a problem with ASN.1 decoding, or possibly TCP/IP (but I hope not). I should warn you there doesn't seem to be nearly as much usage of OpenSSL on VMS as on various Unices, Windows, and I think even Mac. It's possible bugs got into at least some version(s), although a problem in something as basic as this seems unlikely. I used VMS a little long ago, but not with OpenSSL or even TCP/IP. What version of OpenSSL are you using, and did you build it or who did and how? If you have the commandline aka monolith available (I hope you do), do version -a. (On Unix you can give this on the command line like /path/to/openssl version -a, but on VMS you may need to do it interactively, I'm not sure.) Also in commandline, try s_client -connect server:port -msg (and if it connects, immediately give it EOF or interrupt). This will confirm where the failed operation is occurring, and show the data it's using for manual inspection. Note this will probably produce many screenfuls of data; I vaguely recall there is a way to capture it with something like SET /LOG, or perhaps the terminal emulator you are using can log. You might also do /path/openssl s_client -connect ... from the good (Solaris) system for comparison. As an additional data point for ASN.1, if you have a known good certificate file -- and anything you put in your verify_location (trust) directory should have been known good -- do commandline x509 -in certfile -noout and check it doesn't give an error, and x509 -in certfile -noout -text displays lots of info. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Use of IMPLEMENT_ASN1_FUNCTIONS()
Hi All,
I found a code snippet as follows:
ASN1_SEQUENCE(KDC_PRINCNAME) = {
ASN1_EXP(KDC_PRINCNAME, realm, ASN1_GENERALSTRING, 0),
ASN1_EXP(KDC_PRINCNAME, princname, KRB5_PRINCNAME, 1)
} ASN1_SEQUENCE_END(KDC_PRINCNAME);
IMPLEMENT_ASN1_FUNCTIONS(KDC_PRINCNAME)
Here ASN1_SEQUENCE implements the asn1 sequence of KDC_PRINCNAME, but
what is the functionality of IMPLEMENT_ASN1_FUNCTIONS(KDC_PRINCNAME)?
Is it compulsory to include this function after defining every
ASN1_SEQUENCE? Please guide me.
Regards,
Vinay
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
