TYPO3 Core

I have exactly the same error on my system..

Additional information about my case:
- New installation, no update
- PHP 5.2.11
- I tried different storage directories for rsaauth extension without success

My server also uses PHP 5.2.11

I tried with a new installation on another machine which uses PHP 5.2.9 and it works perfectly.

So may it be possible, that this error is caused by PHP itself?

To copy my reply from the mailinglist:

• PHP is compiled without openssl extension AND
• openssl binary is not accessible via CLI (open_basedir activated?)

rsaauth needs either access to the openssl binaries via cli calls or PHP compiled with PHP's openssl extension.

Thx, but I already knew that.

phpinfo() in the Installer tells me:
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.8k 25 Mar 2009
open_basedir no value

Just for info: This is a Mittwald hosting account.

Maybe you could please answer them on the mailinglist, that this seems not to be the problem.

To be honest. I'm quite disappointed that nobody takes care about this bug here in the bugtracker!

By the way, this is the result of phpinfo() on the other machine with PHP 5.2.9 I mentioned above:
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
open_basedir no value

I'd really like to help you but I'm simply unable to reproduce. Described setup works for me.
My environment:
PHP 5.2.4 on Ubuntu (FastCGI), open_basedir enabled, suhosin patch applied; ext/openssl (OpenSSL 0.9.8g 19 Oct 2007)

For further debugging check isAvailable() method both in
typo3/sysext/rsaauth/sv1/backends/class.tx_rsaauth_cmdline_backend.php and
typo3/sysext/rsaauth/sv1/backends/class.tx_rsaauth_php_backend.php

I guess they are returning false in your cases. These methods are used in tx_rsaauth_backendfactory::getBackend() that should return an instance of a backend.

In case they would both return true, you could go on with method createNewKeyPair() in above mentioned files.

Ok thx for this answer.

Did you try it on PHP 5.2.11?
Moreno has the same problem with exactly this version.

As I wrote above: 5.2.9 does work too.

Nevertheless, even if both of these isAvailable() methods return false (I couldn't check by now), I cannot appreciate the behaviour that this results in a Fatal Error (!!!). I'd suggest to print out any error message, but it's not a good programming style to make method calls to non-objects...

I'll report back, if I find the root of all evil.

It's not a problem of PHP version, but more of OpenSSL Version!

I switched back to PHP 5.2.9 but left OpenSSL at version "0.9.8k 25 Mar 2009" and the error did not disappear.

So there must be a change from "0.9.8e-fips-rhel5 01 Jul 2008" (which works) to "0.9.8k 25 Mar 2009" (which does not work) that causes this error!

Stay tuned...

Markus, I use PHP 5.2.11 with OpenSSL 0.9.8k (25th Mar 2009) enabled and BE login with RSA works.
And I see that the server seems to have another module of OpenSSL installed (version .0.9.8f).

I just tried again and reactivated RSA security for BE logins.

And surprise surprise, suddenly it works!

Don't know if the guys from Mittwald changed something on the servers or if the update to 4.3.1 made it work.

So from my point of view you can close this issue as I don't have any possibility now to dig further into this problem.

@all review the other poor souls around: if you updated to 4.3.1 as well please also give it a try and let us know, if problems are gone!

Just had a closer look at the duplicate issue.
Roger says he's using 4.3.1 so maybe it's not related to core version.

That's true! For me it doesn't work with 4.3.1!

It worked for a while but after an update of some components by my provider it stopped working.

Same problems here with TYPO3 4.3.2, PHP Version 5.2.6 and OpenSSL 0.9.7a Feb 19 2003. To fix it we've changed in "rsaauth/sv1/backends/class.tx_rsaauth_php_backend.php" @ Line 52:

- $privateKey = @openssl_pkey_new();

+ $privateKey = @openssl_pkey_new(array('private_key_bits'=>1024));

So it seems this is a lack of openssl.cnf.

Another question is: Why is this function call prefixed with @? I think seeing the error message would be quite helpful in this case.

As one, not possessing his own server, usually is not able to modify openssl.cnf I'd suggest to introduce an additional configuration option, where one can specify his own values for $configargs parameter.

I had this problem on several servers and - for me - it was always of PHP's openssl library not finding openssl.cnf, because of badly configured paths. I solved it everytime by using appropriate symbolic links.

This issue cannot be solved on the TYPO3-side, but there's something that could be done to help: in the extensions's configuration, we could have a user-defined field which tests whether it can create a RSA key or not. If it fails, it should report that SSL setup on the server is not complete and that RSA authentication cannot be used.

If I read it right, I found an old comment by Dmitry saying that such a check existed in an early version.

Is there any easy way to reproduce this error with a simple PHP program? I'd like to check if it's a PHP misconfiguration to be able to correct it ... .

@Francois Suter Suter: Do you mind sharing where you created your symlinks, so anyone can benefit?

@Roger Bunyan Hueppin: call openssl_pkey_new without any arguments and see if it return anything other than false, if it does, your configuration is fine.

@Lucas: in my case I was running a ZendServer setup located in /usr/local/zend/. This is where PHP was expecting to find a "ssl" folder (as was indicated by the compilation configuration --with-openssl IIRC). So I created the following symlink:

ln -s /opt/local/etc/openssl/ /usr/local/zend/ssl

The paths will certainly be different for you.

The following reference helped me: http://www.php.net/manual/en/openssl.installation.php

Yep, that did the trick, thank you.
My configuration was --with-openssl=/usr/local/openssl-0.9.8k , and symlinking the openssl.cnf to /usr/local/openssl-0.9.8k/ssl/openssl.cnf worked.

But shouldn't there be some kind of configuration parameter where you can tell rsaauth where to look for the config file? Would be a nice feature, I guess.

Glad it worked for you.

I don't think it's possible to tell rsaauth where the OpenSSL configuration is, because that's really a PHP issue.

What would be feasible however is to try and create a key pair in the extension's configuration (using a user-defined field) and report about failure.

Well, you could implement a configuration parameter which rsaauth passes on to every openssl php function which needs the location of the openssl.cnf file.

http://www.php.net/manual/en/function.openssl-csr-new.php

"You can also specify an alternative openssl configuration file by setting the value of the config key to the path of the file you want to use."

This error disappeared to me after an apache restart. Don't know if this problem was caused by a memory shortage on my vserver, as I also kill some unused processes before the restart.

Imo, thats unlikely. I'd say you changed something in your server configuration which was loaded when you restarted apache.

We've seen the same behaviour: After a reboot of the whole server, the Backend was not accessible due to this error. While trying to figure out what helps, we discovered that restarting just the Apache Webserver "solves" the issue and logging in get's possible again. We assume it's a sort of dependency with something else that is not yet ready when Apache comes up during system boot, but is then ready during the secont Apache startup. (on CentOS)

"Since this error hasn't been experienced in the last year, this one can be closed!"

I don't think so, Tim!

Occurs sometimes with TYPO3 4.5.X, on a nearly regular basis every couple of weeks.

Restarting apache resolves symptoms.

The problem itself can't be solved by restarting the webserver.
It's not that great, having to restart webserversoftware to log into backend.

php -v:
PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Sep 24 2009 13:44:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
with the ionCube PHP Loader v3.3.20, Copyright (c) 2002-2010, by ionCube Ltd.

Have the same issue and haven't yet understood the complexity of that problem.
The hint of Francois has been the best now but I'm still struggling with my NAS to get all required settings done.
Rejecting and/or ignoring this problem maybe logical as its not a TYPO3 problem but is unacceptable for me cause its a lack of usability and documentation.
Some Settings in the Installtool may be required concerning this problem and the current state with the two encryption-extensions beside documentation is IMHO devastating.

Hi David,
please use the mailing lists (I'm only on the english one), and we'll help you.
Regards
Markus