Bug #14210

SSL - SSL Lock HTTPS Proxy ...

Added by Daniel Poetzinger over 17 years ago. Updated about 3 years ago.

Should have
Backend API
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


SSL Lock seems not to be ficed in 3.6.1

Only Configuration is:

if it is 0 you can log into the backend. If you try to log in with a https Domain (example https://www.xxx.de/typo3) and enter username and password correct Typo3 redirects you to an unsecure url (with http instead of https) The following browser error apperas: "You are about to be redirected to a connection that is not secure...."

If lock is to 1 or 2 you are unable to access the loginbox. If it is 2 Typo3 redirects you alway to index.php in an endless loop..

Maybe that is only for Host with SSL Proxy which means one SSL configuration is shared with diffrent virtual Host in the server with help of mod_rewrite..

Therefore you could dedect an SSL - Connetion with:
$_SERVER['REMOTE_ADDR']== $sslserverip && isset($_SERVER['HTTP_X_FORWARDED_FOR'])

My suggestion is to add more configurationvalues for SSL
For example an SSLURL where you could set the entry point for the backend, this had to be keept and not redirect to an unsecure url.
(for example in phpmyadmin one could set something like this for securityreasons which is what I mean:
$cfg['PmaAbsoluteUri'] = 'https://www.xxx.de/proxydomain.de/phpmyadmin/'; )

(issue imported from #M169)


0000169-sslproxy (2.19 KB) 0000169-sslproxy Administrator Admin, 2004-09-19 19:14
0000169-config_default_diff (1.73 KB) 0000169-config_default_diff Administrator Admin, 2004-09-29 16:03
0000169-t3lib_div_diffs (901 Bytes) 0000169-t3lib_div_diffs Administrator Admin, 2004-09-29 16:03

Related issues

Related to TYPO3 Core - Bug #15135: Typo3 backend does not work with reverse proxyClosedChristian Jul Jensen2005-10-20

Related to TYPO3 Core - Bug #16395: There is a error in detecting the ssl pageClosedMichael Stucki2006-07-22

Is duplicate of TYPO3 Core - Bug #18126: Proxy servers replace REMOTE_ADDR with their own IPClosedMichael Stucki2008-02-05


Updated by Daniel Poetzinger about 17 years ago

OK I add a new configuration value and changed SSL detection in t3lib_div in this way:

if (!strcmp(trim($GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']),'1') && isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
return true;
elseif (strcmp(trim($GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']),'0') && $GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']==$_SERVER['HTTP_X_FORWARDED_SERVER']) {
return true;
else {


Updated by Michael Stucki about 17 years ago

Can you make a patch of this?


Updated by Ingmar Schlecht about 17 years ago

What exactly does the environment variable HTTP_X_FORWARDED_SERVER contain?

According to google the only resources where that env variable is named in a TYPO3 context are the following:

I don't think this should go into 3.7, I still remember the fuss about the bug in the SSL detection code in 3.6.0... So it might not be wise to give this patch so few time for testing.


Updated by Daniel Poetzinger about 17 years ago

OK I will explain it exactly:
an SSL key for a webserver is only attached to one domain
as I know it is very difficult (perhaps impossible) to configure apache in the way that each virtual domain has an own ssl key....

The solution is "ssl proxy" it works like:
the webserver has one ssl key, say for domain https://www.secureconnetion.com/
but the server handled much virtual domains like www.domain1.com
- if you call https://www.domain1.com/ the SSL key did not match the domain
- SSL Proxy means you can access domain1.com for example with the secure connection https://www.secureconnection.com/domain1.de/
- in most cases it is implemented with a simple mod_rewrite on the server , an example is attached

Because people want to access TYOP3 Backend through SSL but have SSL-Proxy behavior on here server I submitted the patch:
(TYPO3 "thinks" the connection with SSL Proxy is unsecure, and so the SSL check fails and the reported behavior above appears...)

With the patch it is possible to access BE through such a secure connection, which is impossible now.

(the var HTTP_X_FORWARDED_SERVER is only set if the connection is through SSL-Proxy or something like that)

- the new configuration var "checkSSLProxy" can be 1 which means the SSL check returns true if HTTP_X_FORWARDED_SERVER is set (no matter what)
- if checkSSLProxy is something like "www.ssldomain.com" the ssl check returns true if HTTP_X_FORWARDED_SERVER is the same.

I tested it on my server ( 1und1 rootserver) and it works in both cases for this serverconfiguration.

If you aggree with it, how can I make a patch :-(

Beside why should it not go in 3.7:
If the configuration var is set to '0' or is empty nothing is changed in SSL detection?

bearbeitet am: 19.09.04 19:17


Updated by Michael Stucki about 17 years ago

Daniel, your patch is still missing.

After a short discussion we have decided to not include this in 3.7.0. I want to try to reproduce this first and then test the solution locally. Hopefully it will go into 3.7.1.


Updated by Daniel Poetzinger about 17 years ago

(Sorry time was rar.)
Hope the attached patches are ok.


Updated by Jochen Weiland about 17 years ago

I found a problem on some servers where "lockSSL = 2" would result in an endless loop and "lockSSL" redirects to an unsecure connection after login.
The problem is in the following line in t3lib:div.php:


This checks for HTTPS to have the value "on", however on the servers I use (managed servers from 1&1 and Schlund) the variable is "1" instead of "on". Changing the line accordingly fixes the problem.
I suggest to change the above line to check for either "on" or "1"



Updated by Alexander Maringer almost 16 years ago

At the current release 3.8.1 the problem is still not solved. Please solve this wih one of the two solutions. The solution of Jochen works well at the server I had to install. Thanks a lot.


Updated by Christian Boltz almost 16 years ago

see bug 1699 to get the correct paths ;-)


Updated by Axel Beckert almost 16 years ago

The patches attached to this bug report may fix the cases of SSL detection behind reverse proxies, but does not fix any of the more general reverse proxy bugs in Typo3 like e.g. #14229 or #14229.

IMHO there should be general feature to detect if Typo3 sits behind a reverse proxy (perhaps also via configuration), to get links, javascript and cookies work with the reverse proxies, not the backend Typo3 server.


Updated by Christian Boltz almost 16 years ago

I just uploaded an up-to-date patch to bug 1699 that also includes the code of the t3lib_div_diffs in this bug. See my comment there - and feel free to help ;-)


Updated by Sebastian Kurfuerst about 15 years ago



Updated by Henning Pingel almost 15 years ago


I would like to help on solving the related bugs 169, 1699 and 202. Regarding the reverse proxy capabilities (including SSL) I have started to write a tutorial. The work on this tutorial is necessary for me to understand the problem in depth.

I hope it is also helpful for solving this issue and finding a solution that can be part of the core.


Best regards,


Updated by Michael Stucki over 13 years ago

Please check out if the patch in #18126 will fix the problem.


Updated by Christian Jul Jensen about 13 years ago

duplicate according to Christian Kuhn


Updated by Benni Mack about 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF