Hi On 02.02.2013 23:55, Alexander Hollerith wrote:
with OpenSSL on 32-bit systems you can't generate a certificate thats validity goes above 19 jan. 2038;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.
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