HEADS UP: OpenSSL 1.0.1_4 (1.0.1c), OpenVPN, and ipsec-tools, and others.
-
Whenever I create an internal CA with Lifetime 36500 and then test it on the pfsense box afterwards I get something like this:
/home/alex(3): /usr/local/bin/openssl x509 -in x.cert -noout -enddate
notAfter=Dec 2 14:44:37 1976 GMTSince I'm using the 1.0.x binary to test I assume that something must have provoked the 2038 bug while creating the cert and that lead me to believe that openssl 0.9.8 was used for creation. I might completely overlook something here, since I'm not an expert with openssl and Certs…
php indeed uses OpenSSL 1.0.1c (see below) - which leaves at least the following options:
- I'm doing something wrong
- the year 2038 bug is still present in 1.0.1c on i386
I might come back to this at some point, but for now I'll just create my Certs on some other machine (which is a bit of a shame since the pfsense Cert Manager is one of the most comfortable tools I have seen when it comes to Certs)
/home/alex(64): php -i | grep OpenSSL
SSL Version OpenSSL/1.0.1c
OpenSSL support enabled
OpenSSL Library Version OpenSSL 1.0.1c 10 May 2012
OpenSSL Header Version OpenSSL 1.0.1c 10 May 2012 -
There is a third option and that is that the 2038 bug is present in PHP's OpenSSL interface code.
(Or, fourth, somewhere in between those layers…) -
There is a third option and that is that the 2038 bug is present in PHP's OpenSSL interface code.
(Or, fourth, somewhere in between those layers…)Seems that option three it is, from the php openssl library code:
/* {{{ proto resource openssl_csr_sign(mixed csr, mixed x509, mixed priv_key, long days [, array config_args [, long serial]])
Signs a cert with another CERT /
PHP_FUNCTION(openssl_csr_sign)
{
zval ** zcert = NULL, **zcsr, **zpkey, args = NULL;
long num_days;
…...
X509_gmtime_adj(X509_get_notAfter(new_cert), (long)606024*num_days);
......Assuming that "sizeof(long) = 4" on i386 and "sizeof(long) = 8" on amd64 (as it usually is, if I remember correctly) the experienced behavior would be explainable.
Thanks for pointing me into the right direction - and now on to a 64-bit environment :)
-
I'm not completely sure if this is related to OpenSSL too, I have issues with LDAPS authentication after upgrading:
-
Updated from: Mon Jan 28 16:55:26 EST 2013, Last commit: b0059636a9ccba5708152cb9548633e2f44c38d1
-
Checking the commit dates I'm positive this was a build must have contained OpenSSL 1.0.1c (1.0.1c was merged on 25th, but I wasn't able to check before updating.
-
Update to latest available snapshot: Thu Feb 7 18:03:44 EST 2013, last commit: dfac167caa70ca76dfee8101571eeedd0e034406, /usr/local/bin/openssl version says 1.0.1d
Issue:
-
Previously LDAP autentication (mainly used for admins) worked with and without SSL LDAP communication
-
When LDAP was unavailable I was able to fall back to local authentication
-
Now testing LDAP only works with plaintext LDAP communication (I had to viconfig the config.xm, and disable LDAP auth to break into the Web interface with local admin)l
-
It can bind with LDAP, but fails to fetch the OUs, previously this worked too
-
When LDAPS was enabled, local authentication on the Web-UI was not possible
We had to install a root certificate from our AD CA and have a certificate for the pfSense box issued from this CA. I'm positive that the certificates are fine since I tested it with pointing LDAP config to a CNAME of our DC and it failed since the certificate on the AD DC didn't contain it in its name (which BTW is well done guys since I know a couple of applications who just don't validate certificate data!)
While our AD/LDAP servers yet accept non-SSL LDAP communication, I'd consider it ugly to go back to non-SSL LDAP authentication (and I'm yet unsure if LDAP auth yet even works right now).
Can I provide you with some valuable debug data - is it even OpenSSL related, ? -
-
I don't recall what handles that specifically, it may yet be openssl, or not. It should give some details/error in the system log though.
-
Thanks Jim, hope to get more info after weekend. (better not completely break things before) ;-)
-
I wonder if it's related to this…
http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081259.htmlThey say 1.0.1e is coming soon because 1.0.1d was broken in various ways.
-
Jim, concerning LDAP - the weird thing is that it can't get the LDAP OU even without SSL so I'm not sure whether it's only an OpenSSL issue.
But first I need to get onto a snapshot with fixed OpenSSL & working route addition (other thread) before I dare test LDAP again. ;-) -
I was just sitting here thinking how important it be that my CAs be valid in 2038…
Because we all will be on the stuff we build today in 2038. -
Dont know if this has been reported.
Trying to create a new Internal-CA
Key Length 4096
Hash SHA512
Days 3650
CountryCode: MilFill in the rest of the fields and you will get this error message.
The following input errors were detected:openssl library returns: error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long
If you dont choose Mil you can create an internal CA.
FWIW.
