Re: overflow when calling X509_gmtime_adj() on 32-bit systems
Hi On 02.02.2013 23:55, Alexander Hollerith wrote: The php openssl library implements a function named openssl_csr_sign() and inside that function one can find the following line: X509_gmtime_adj(X509_get_notAfter(new_cert), (long)60*60*24*num_days); This obviously provokes an overflow in cases of large values of num_days, say 36500 (representing 100 years), on 32-bit systems where usually sizeof(long) = 4. The bug report I opened in the php bugtracker was closed with not a bug pointing to the openssl API. The php people correctly pointed out that X509_gmtime_adj() needs a long value as parameter. with OpenSSL on 32-bit systems you can't generate a certificate thats validity goes above 19 jan. 2038; the linux time is only 64-bit on 64-bit systems; I found that OpenSSL Cert creation example code (https://github.com/cloudmeter/openssl/blob/master/demos/x509/mkcert.c) has that very same line in it and should therefore be subject to the same issue: X509_set_version(x,2); ASN1_INTEGER_set(X509_get_serialNumber(x),serial); X509_gmtime_adj(X509_get_notBefore(x),0); X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days); X509_set_pubkey(x,pk); After searching around a bit I assume that with newer versions of OpenSSL using OPENSSL_gmtime_adj() or X509_time_adj_ex instead of X509_gmtime_adj() would maybe resolve this obvious limitation. its not an resolve by newer versions, its an resolve by 64-bit systems; in C/C++ long can be 64-bit on 64-bit systems; it cannot be assumed that generally datatype long is 32-bit; as strange it sounds, a newer OpenSSL version on a 32-bit Linux has these limitations (e.g. OpenSSL 1.0.0 on CentOS 6.3), but not an older OpenSSL version on a 64-bit Linux (e.g. OpenSSL.0.9.7 on CentOS 4.x); so migrating to 64-bit will be a neccessary step. Greetings Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: overflow when calling X509_gmtime_adj() on 32-bit systems
On Sat, Feb 02, 2013, Alexander Hollerith wrote: Hi, The php openssl library implements a function named openssl_csr_sign() and inside that function one can find the following line: X509_gmtime_adj(X509_get_notAfter(new_cert), (long)60*60*24*num_days); This obviously provokes an overflow in cases of large values of num_days, say 36500 (representing 100 years), on 32-bit systems where usually sizeof(long) = 4. The bug report I opened in the php bugtracker was closed with not a bug pointing to the openssl API. The php people correctly pointed out that X509_gmtime_adj() needs a long value as parameter. I found that OpenSSL Cert creation example code (https://github.com/cloudmeter/openssl/blob/master/demos/x509/mkcert.c) has that very same line in it and should therefore be subject to the same issue: X509_set_version(x,2); ASN1_INTEGER_set(X509_get_serialNumber(x),serial); X509_gmtime_adj(X509_get_notBefore(x),0); X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days); X509_set_pubkey(x,pk); After searching around a bit I assume that with newer versions of OpenSSL using OPENSSL_gmtime_adj() or X509_time_adj_ex instead of X509_gmtime_adj() would maybe resolve this obvious limitation. Unfortunately I'm not able to immediately see how (my C skills are rather limited and I'm not experienced with using OpenSSL). Could somebody on this list maybe be so kind and point me in the right direction? This is indeed a limitation with X509_gmtime_adj. In older versions of OpenSSL it also relied on the system time functions and so was sensitive to overlflows in the time_t type. In OpenSSL 1.0.0 some OS independent time functions have been added with some additional functions that overcome the limits but still retaining the old ones for compatibility. In that above code example if you do: X509_gmtime_adj_ex(X509_get_notAfter(x), days, 0, NULL); that should resolve your problem. 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: overflow when calling X509_gmtime_adj() on 32-bit systems
On Sun, Feb 3, 2013 at 7:01 PM, Dr. Stephen Henson st...@openssl.org wrote: In that above code example if you do: X509_gmtime_adj_ex(X509_get_notAfter(x), days, 0, NULL); that should resolve your problem. Maybe it should be better: X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL); __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: overflow when calling X509_gmtime_adj() on 32-bit systems
On Sun, Feb 03, 2013, Dongsheng Song wrote: On Sun, Feb 3, 2013 at 7:01 PM, Dr. Stephen Henson st...@openssl.org wrote: In that above code example if you do: X509_gmtime_adj_ex(X509_get_notAfter(x), days, 0, NULL); that should resolve your problem. Maybe it should be better: X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL); Yes sorry it should, that's a typo. A bit early in the day for me... 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: RFC 3161 GUI Inspector
Take a look at this JAVA client (based on Bouncy Castle). http://www.postsignum.cz/jakym_zpusobem_sluzbu_vyuzivat.html If is it usable with other TSA - try to test. Remark: the generated TS reply is not whole TS reply, bud just subtree - TS token. BTW - I thing, that to make own GUI app should be possible even for no-programmer. What about access via web form ? --kapetr Dne 1.2.2013 23:55, Jaime Hablutzel Egoavil napsal(a): Hi, maybe this question is a little bit off topic but I can't find anywhere to ask it. Do you know a RFC 3161 (time-stamp protocol) GUI that allows to create a timestamp token easily for testing purposes? Maybe receiving a file reference, a TSA url and nothing more, clic on a button and then you can download the response or inspect it from a GUI. Have you ever saw something like that? I know there exists the command openssl ts but sometimes I would prefer a clickable GUI. -- Jaime Hablutzel - RPC 987608463 (tildes omitidas intencionalmente) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: overflow when calling X509_gmtime_adj() on 32-bit systems
On 03.02.2013, at 12:28, Dr. Stephen Henson st...@openssl.org wrote: On Sun, Feb 03, 2013, Dongsheng Song wrote: On Sun, Feb 3, 2013 at 7:01 PM, Dr. Stephen Henson st...@openssl.org wrote: In that above code example if you do: X509_gmtime_adj_ex(X509_get_notAfter(x), days, 0, NULL); that should resolve your problem. Maybe it should be better: X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL); Yes sorry it should, that's a typo. A bit early in the day for me... Steve. Thanks a lot! I'll pass that information on to the php people, maybe they are willing to make the effort and look into it. Alex__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Java Key Store (JKS) verses just PKCS12 files
I store my cert and private key in PKCS12 files; I then add these PKCS12 files to Java Key Store. If I need to perform some security functions I extract the PKCS12 from the Java Key Store by alias and perform all sorts of openssl commands. And so why do I want to use a Java Key Store other than for a bag for my PKCS12s (as repository of security certificates) ? The alias is nice to access which ones I need and have to replace also its one file (JKS file) that can be backed up; thats all I see. Is there a standard well excepted measure to manage your sec certs, in other words is is wrong to just have PKCS12 files? I imagine the process which is performing all sorts of signing of documents would simply load the security certs in memory for quick usage be it from the Keystore or just the raw PKCS12s and periodically check for updates. Any comments on this. -- View this message in context: http://openssl.6102.n7.nabble.com/Java-Key-Store-JKS-verses-just-PKCS12-files-tp43476.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
Re: Java Key Store (JKS) verses just PKCS12 files
On 2/3/2013 2:14 PM, redpath wrote: I store my cert and private key in PKCS12 files; I then add these PKCS12 files to Java Key Store. If I need to perform some security functions I extract the PKCS12 from the Java Key Store by alias and perform all sorts of openssl commands. And so why do I want to use a Java Key Store other than for a bag for my PKCS12s (as repository of security certificates) ? The alias is nice to access which ones I need and have to replace also its one file (JKS file) that can be backed up; thats all I see. Is there a standard well excepted measure to manage your sec certs, in other words is is wrong to just have PKCS12 files? I imagine the process which is performing all sorts of signing of documents would simply load the security certs in memory for quick usage be it from the Keystore or just the raw PKCS12s and periodically check for updates. Any comments on this. The common methods are either: - Trust some (semi-)closed source vendor (Oracle or Google binary Java or Microsoft binary cryptoapi) to safely store things in their choice of private storage pool. JKS is easy to backup, MS storage has gone overboard in preventing backups (because they cannot detect the difference between backups and someone stealing your keys). - Use a perfectly ordinary file storage mechanism (file system, tar.gz file, signed jar file etc.) to store one PEM file per certificate and one encrypted PEM key file (.key) per private key. Use your chosen nickname as the file name and use subdirectories for certificate types (e.g. cacerts/, incerts/, contacts/, owncerts/). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
