[SOLVED] 'http_server=' parameter - SSL redirect? [TLDR solution: ssl_helper not working]

Post bug reports related to either the kiosk ISO or the kiosk wizard here.
Forum rules
Porteus Kiosk section of the forum is unmaintained now. Its kept in a 'read only' mode for archival purposes.
Please use the kiosk contact page for directing your queries: https://porteus-kiosk.org/contact.html
LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

[SOLVED] 'http_server=' parameter - SSL redirect? [TLDR solution: ssl_helper not working]

Post#1 by LuxZg » 19 May 2021, 10:22

Not sure if this should be in the requests, or bugs, but here it goes...

I'm experimenting with PXE boot of latest 5.2.0 Kiosk, and I'm not sure what's the exact issue...
I have an image that was made with these parameters:

Code: Select all

http_server=10.20.30.40:80/porteus/520
kiosk_config=http://10.20.30.40/porteus/pxe/pxeboot.txt
Now, that works fine on HTTP / port 80, but after tests were done, I started to slowly migrate everything to HTTPS / SSL.
In the process I tried simply redirecting (on the server side):
- from : 10.20.30.40/porteus
- to : https://my.local.name/porteus
Note that I'm redirecting to HTTPS and also redirecting to FQDN (so that certificate can be valid), but it is the same exact server and folder as before.

I can see that initial requests are coming to web server hosting the files, but Porteus Kiosk boot fails.
If I keep xzm/docs redirect to HTTPS then it just hangs, tries fetching folder listing over port 80/HTTP and after receiving redirect just gives up (or so it seems)
If I exclude xzm/docs folders from redirect, then it boots to wallpaper, but then fails on fetching config file as if file was not found
When both xzm/docs folders and kiosk config file are excluded, then it boots fine.

So I'm assuming that curl (or wget?) is fetching .xzm, config, and other files, but one of these is unsupported:
- doesn't follow redirects
- doesn't support HTTPS

Now, normally I'd make new boot images several times with different combinations, and keep rebooting until it starts working, but I'm a bit short on time :sorry:

So I'd appreciate confirmation on a few of these:
- does 'http_server=' support SSL or not?
- does binary using 'http_server=' supports following redirects or not?
- does 'kiosk_config=' support SSL or not?
- does binary using 'kiosk_config=' supports following redirects or not? (for this last one I believe that this works, as I vaguely remember trying redirect of pxeboot.txt to pxeboot.php, both still on HTTP/80, and I think it used to work with Kiosk 4.7.0)

I'd appreciate some clarification, thanks, it would save me dozens of reboots and several image creations, probably taking whole day to deduct by myself...
Last edited by LuxZg on 24 May 2021, 10:44, edited 1 time in total.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

'http_server=' parameter - SSL redirect?

Post#2 by fanthom » 19 May 2021, 13:33

Hello LuxZg,

Maybe its a permissions problem on your PXE server?
Its strange that the kiosk is able to download certain files only (that still confirms the SSL works).

1) 'kiosk_config=' parameter does support SSL and redirects.

2) 'http_server=' parameter operates super early (at the initrd stage of booting) and may have troubles with supporting SSL (redirects should be ok i believe) as we use crippled wget version from busybox and also the SSL helper binary to handle HTTPS conenctions.

You mat unpack the initrdpxe.xz and:
a) copy /bin/ssl_helper to /bin folder of Ubuntu (or any other linux)
b) copy 'busybox' binary to Ubuntu

Now you should be able to run:
./busybox wget https-URL

and check if you are able to download something using our utilities.

If not then you may need to upgrade busybox and SSL helper in your initrdpxe.xz and use it instead of the stock one.

Thanks
Please add [Solved] to your thread title if the solution was found.

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#3 by LuxZg » 21 May 2021, 11:54

Hi Thomas,

It is not permission problem.
Kiosk doesn't actually download anything when it is redirected:
from

Code: Select all

"http_server=10.20.30.40:80/porteus/520"
to

Code: Select all

"https://my.local.name/porteus/520"
It just logs a request to web server on port 80 (eg. it's request to

Code: Select all

http://10.20.30.40:80/porteus/520/default.jpg
), and when server responds with 301 redirect it moves on to next wget command due to unknown/silent error.

In effect it doesn't even try to access "kiosk.sgn" or "version" as those are in same wget command.
Also, after it logs request to

Code: Select all

http://10.20.30.40:80/porteus/520/xzm/
(folder) it doesn't proceed downloading *.xzm files as it never asks for data at HTTPS/443 and thus there is nothing to parse with rest of the init script.
part #2 - testing busybox wget
I did try unpacking the files next and moving them to test Linux machines.
I actually did tests on Ubuntu and on Porteus Kiosk client itself.

When I try your busybox version of wget from initrdpxe.xzm (without the "-q" flag obviously) I get error:

Code: Select all

./busybox wget https://my.local.name/porteus/520/docs/default.jpg
Connecting to my.local.name (10.20.30.40:443)
SSL_connect failed
wget: error getting response: Connection reset by peer
Likewise if I try to access the initial HTTP with redirect to HTTPS, I do get redirected part ok but SSL error is same:

Code: Select all

./busybox wget 10.20.30.40/porteus/520/docs/default.jpg
Connecting to 10.20.30.40 (10.20.30.40:80)
Connecting to my.local.name (10.20.30.40:443)
SSL_connect failed
wget: error getting response: Connection reset by peer
But if I try the same with normal wget, on same client (this is from your own Porteus Kiosk, so wget build that's being shipped with 5.2.0) I get normal download result:

Code: Select all

wget https://my.local.name/porteus/520/docs/default.jpg
--2021-05-21 13:08:14--  https://my.local.name/porteus/520/docs/default.jpg
Resolving my.local.name... 10.20.30.40
Connecting to my.local.name|10.20.30.40|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1258241 (1.2M) [image/jpeg]
Saving to: 'default.jpg'

default.jpg                                                 100%[========================================================================================================================================>]   1.20M  --.-KB/s    in 0.09s

2021-05-21 13:08:14 (13.2 MB/s) - 'default.jpg' saved [1258241/1258241]
So HTTPS and permissions are all ok, firewalls, routes, DNS resolving, etc.

But ssl_helper included in PXE script obviously can't work correctly. I tried downloading other HTTPS sites (not local ones, normal websites) and I'd get same error.

Likewise, same error on Ubuntu with your busybox/wget. Example of fail and example of success with normal wget, on ubuntu, and with www.google.com:

Code: Select all

 ./busybox wget https://www.google.com
Connecting to www.google.com (172.217.23.100:443)
SSL_connect failed
wget: error getting response: Connection reset by peer

wget https://www.google.com
--2021-05-21 13:46:56--  https://www.google.com/
Resolving www.google.com (www.google.com)... 172.217.23.100, 2a00:1450:4001:830::2004
Connecting to www.google.com (www.google.com)|172.217.23.100|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html                                                      [ <=>                                                                                                                                     ]  13.06K  --.-KB/s    in 0.003s

2021-05-21 13:46:57 (4.01 MB/s) - ‘index.html’ saved [13371]
All in all, seems that ssl_helper in initrdpxe.xz is not much of a helper at all :sorry:

I just wonder how come noone ever tried PXE booting over HTTPS in all these years, I mean, it's not huge security risk in closed environment, but any file can be intercepted and modified by attacker, not to mention if you have some sensitive data in one of the *.xzm modules (eg. you pack a rd.0 script in it with something special or whatever).

I'll see what I can do about creating my own initrdpxe.xz module, if it's just picking up busybox from Ubuntu I could do that, but if it requires recompiling on my own... that's a bit over my Unix knowledge. (Edit: I did try to just copy binary, and as expected - error.)

Edit #2: just tried with https://busybox.net/downloads/binaries/ ... box-x86_64 ; quick test from client that's already booted = works, and now on to make new initrdpxe.xz

Edit #3: seems I'm stuck till Monday... initrd.xz and initrdpxe.xz don't use same way of compressing as .xzm (I always thought it was just a styling with xzm as m-module). For modules I'd do something like:

Code: Select all

unsquashfs 003-settings.xzm
...
mksquashfs opt/ windows-chrome-update.xzm -comp xz -b 256K -Xbcj x86 -noappend -keep-as-directory
What's the process for .xz? Search brings nothing of value... I tried "unxz" and "xz --decompress" but both create a single file instead tree structure

Edit #4: never give up :P

Code: Select all

xz --decompress initrdpxe.xz
mkdir uncpio-pxe
cd uncpio-pxe/
cpio -idv < ../initrdpxe
cp ../busybox-x86_64 busybox
find | cpio -H newc -o | xz --check=crc32 --x86 --lzma2 > ../initrdpxe-new.xz
references: Re: how open & close initrd.xz (Post by brokenman #53718) && Re: [SOLVED] Modify Default Files, etc. (Post by fanthom #12193)

Now to try to test remotely

Edit #5: seems that I did manage to create new initrdpxe.xz correctly, but it failed following redirect to HTTPS, when first two files (jpg) failed, I quickly removed redirect and rest of .xzm files were downloaded soon after, but it still faled, probably because it already didn't fetch the kiosk.sgn (same onliner with default.jpg)... now I killed my only test client and I'm trully locked until Monday.
I can only assume that the "busybox-x86_64" I've downloaded requires something else for working SSL, something that was present on Porteus Kiosk 5.2.0 once it fully booted, but not available in init phase...

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

'http_server=' parameter - SSL redirect?

Post#4 by fanthom » 21 May 2021, 18:58

1) I think you are right - redirections are not supported by the busybox's wget applet

2) Kiosk site works ok with busybox wget + SSL helper:

Code: Select all

./busybox wget https://porteus-kiosk.org
Connecting to porteus-kiosk.org (195.154.133.73:443)
index.html           100% |*****************************************************************************************************************************************************************| 22649   0:00:00 ETA
So the SSL helper works ok (maybe not in every case but still).

3) You may try packing a static binary wget (if you find it somewhere, if not you will need to compile one) into initrdpxe.xz and modify init script from standard initrd.xz to use it instead of calling busybox wget. That should resolve your problem.

Thanks
Please add [Solved] to your thread title if the solution was found.

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#5 by LuxZg » 21 May 2021, 20:44

Thanks, that's my next try I guess, the standalone wget, and changing init script. I did have a go at similar solution, but bricked second test PC. Colleagues will reboot them so I get connectivity again, will try tomorrow. Tonight I'll look for correct wget binary

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#6 by LuxZg » 22 May 2021, 12:22

I've done a correct conversion of init/initrd+initrdpxe with static wget binary, first tested with HTTP/80 and rebooted client, and it correctly rebooted. So my script and .xz file conversion process was OK. Then I turned on redirect and - fail. Well, it is better, now I have all files being requested and redirected (all 3 files in that buysybox wget oneliner get requested, not just first one), but they don't request at HTTPS/443 after that.

I'm thinking that I've skipped on testing :oops: ... bit too much... probably need some flag or something so I can force wget to follow redirect from 10.20.30.40 to my.local.name .. but I bricked my test client again. Hopefully someone works Sundays later today..

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#7 by LuxZg » 22 May 2021, 20:53

I did one more try with curl from here:
https://github.com/moparisthebest/static-curl

And again, with HTTP and my modifications test client boots fine, but once I force HTTPS it hangs.

When client hangs I see requests to those 5-6 files via 80, and server response to each with 301 redirect, bit neither file gets requested via HTTPS after that

Now if I upload same binary to client that's already booted, and run same exact lines, I get the file, and web server log shows same HTTP requests, same 301 redirects, and then HTTPS requests. All fine.

Is my expectation of these statically linked binaries flawed? Are they self contained binaries or do they still have their separate requirements and dependencies?

As it looks now, I'd say everything is fine, until these replacement binaries have to switch to HTTPS, and then they lack something that allows them to use SSL. Yet all three replacements specifically mentioned SSL/HTTPS in their builds, and neither is mentioning that I need to include additional files (libs, or other binaries) for these to work.

Edit:
I just noticed I did not say which wget I used...

WGET
https://github.com/yunchih/static-binar ... aster/wget
wget (Version 1.20.1, with SSL)
CURL
https://github.com/moparisthebest/static-curl
Currently it is a featureful build with OpenSSL, libssh2, nghttp2, and zlib, supporting most protocols.
...
curl 7.76.1
BUSYBOX
https://busybox.net/downloads/binaries/ ... arch-musl/
Support HTTPS using internal TLS code (FEATURE_WGET_HTTPS) [Y/n/?] y
Try to connect to HTTPS using openssl (FEATURE_WGET_OPENSSL) [Y/n/?] y
...
Busybox version: 1.31.0
...
CONFIG_FEATURE_WGET_HTTPS=y
CONFIG_FEATURE_WGET_OPENSSL=y

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

'http_server=' parameter - SSL redirect?

Post#8 by fanthom » 23 May 2021, 07:43

Add 'sh' command to the init script before downloading the components and then you will get access to the shell during PXE boot and can debug downloading manually.

You will also need to comment out one or two commands at the very beginning of the init script to re-enable cursor (cant remember which ones).
With invisible cursor its hard to type.

Thanks
Please add [Solved] to your thread title if the solution was found.

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#9 by LuxZg » 23 May 2021, 08:14

Awesome suggestion! As soon as I'm back physically in the office I'll try that

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#10 by LuxZg » 24 May 2021, 09:12

Good morning,

just a quick update.

I tested again with original busybox/wget + ssl_helper as I wanted to confirm that downloads (sometime) work. And indeed, downloads from porteus-kiosk.org worked. But trying several other sites, it failed. I did notice that your site uses TLS 1.3 and others mostly use TLS 1.2, so could be that some of the encryption options do/don't work with currently used ssl_helper implementation.

Anyway, I've searched for alternative ssl_helper and current quick test on already booted client shows that indeed ssl_helper could be the issue. See below:

Code: Select all

root@BeeBox-LUPR2:/# ./busybox-initrdpxe-orig wget https://ip.index.hr/remote/indexnew.s3.index.hr/b3c2ed25-5270-4b62-a249-b60c221d268f.jpg
Connecting to ip.index.hr (104.19.139.57:443)
b3c2ed25-5270-4b62-a 100% |********************************************************************************************************************************************************************************************|   145k  0:00:00 ETA
root@BeeBox-LUPR2:/# ls -al /bin/ssl_helper
-rwxrwxrwx    1 root     root        231472 May 24 10:47 /bin/ssl_helper

root@BeeBox-LUPR2:/# ls -al /ssl_helper
-rw-r--r--    1 root     root        174144 Mar 20 11:54 /ssl_helper
root@BeeBox-LUPR2:/# mv ssl_helper /bin/ssl_helper
root@BeeBox-LUPR2:/# chmod 777 /bin/ssl_helper
root@BeeBox-LUPR2:/# ./busybox-initrdpxe-orig wget https://ip.index.hr/remote/indexnew.s3.index.hr/b3c2ed25-5270-4b62-a249-b60c221d268f.jpg
Connecting to ip.index.hr (104.19.141.57:443)
SSL_connect failed
wget: error getting response: Connection reset by peer

The original busybox from initrdpxe.xz (for Kiosk 5.2.0) is used in both, but in first test download I've used ssl_helper from busybox website (even though from 2016):

Code: Select all

https://busybox.net/downloads/binaries/ssl_helper-x86_64

ssl_helper-x86_64       2016-08-21 01:49  226K
And in second test I've reverted to original ssl_helper (from initrdpxe.xz for Kiosk 5.2.0).

Downloading from porteus-kiosk.org worked with both.

Size difference makes 2016. busybox.net version about 60kb larger.

I'm not in office yet, so I'll try to create new initrdpxe.xz with this ssl_helper and test remotely.

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#11 by LuxZg » 24 May 2021, 09:58

Hurrah!

So I used ssl_helper-x86_64 binary available from busybox.net download repository (dated: 2016-08-21 01:49) and created new initrdpxe.xz and client booted.

This is excerpt from web server logs:

Code: Select all

2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/default.jpg - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/default.jpg - 443 - 10.20.31.102 Wget - 200 0 0 41
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/kiosk.sgn - 80 - 10.20.31.102 Wget - 301 0 0 3
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/kiosk.sgn - 443 - 10.20.31.102 Wget - 200 0 0 7
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/version - 80 - 10.20.31.102 Wget - 301 0 0 2
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/version - 443 - 10.20.31.102 Wget - 200 0 0 4
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/kiosk.jpg - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/docs/kiosk.jpg - 443 - 10.20.31.102 Wget - 200 0 0 34
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/xzm - 80 - 10.20.31.102 Wget - 301 0 0 3
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/xzm - 443 - 10.20.31.102 Wget - 301 0 0 5
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/xzm/ - 443 - 10.20.31.102 Wget - 200 0 0 4
2021-05-24 09:38:40 10.20.30.40 GET /porteus/520/xzm/000-kernel.xzm - 80 - 10.20.31.102 Wget - 301 0 0 3
2021-05-24 09:38:43 10.20.30.40 GET /porteus/520/xzm/000-kernel.xzm - 443 - 10.20.31.102 Wget - 200 0 0 2136
2021-05-24 09:38:43 10.20.30.40 GET /porteus/520/xzm/001-core.xzm - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:46 10.20.30.40 GET /porteus/520/xzm/001-core.xzm - 443 - 10.20.31.102 Wget - 200 0 0 3142
2021-05-24 09:38:46 10.20.30.40 GET /porteus/520/xzm/002-chrome.xzm - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/002-chrome.xzm - 443 - 10.20.31.102 Wget - 200 0 0 4238
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/003-settings.xzm - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/003-settings.xzm - 443 - 10.20.31.102 Wget - 200 0 0 28
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/004-wifi.xzm - 80 - 10.20.31.102 Wget - 301 0 0 1
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/004-wifi.xzm - 443 - 10.20.31.102 Wget - 200 0 0 56
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/08-ssh.xzm - 80 - 10.20.31.102 Wget - 301 0 0 4
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/08-ssh.xzm - 443 - 10.20.31.102 Wget - 200 0 0 32
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/windows-chrome.xzm - 80 - 10.20.31.102 Wget - 301 0 0 2
2021-05-24 09:38:50 10.20.30.40 GET /porteus/520/xzm/windows-chrome.xzm - 443 - 10.20.31.102 Wget - 200 0 0 3
Note how each file is first accessed on port 80 (HTTP), to which server replies with 301 (redirect), after which same file is delivered via port 443 (HTTPS) with success (200).

Now to test the "kiosk_config=..." as well.

Anyway, I'd suggest replacing ssl_helper in current builds of initrdpxe.xz with something newer, as obviously a lot of websites aren't compatible with current ssl_helper implementation. I did not deduct exact issue, but you can test yourself with widely available websites such as google.com or microsoft.com (or in case above, index.hr, local news portal). Out of 6-7 websites I've tried - only portues-kiosk.org worked with with current implementation :D

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

'http_server=' parameter - SSL redirect?

Post#12 by LuxZg » 24 May 2021, 10:43

OK, seems that kiosk_config works.

I have it setup as:

Code: Select all

kiosk_config=http://10.20.30.40/porteus/pxe/pxeboot.txt
Then server forces redirect to:

Code: Select all

https://my.local.name/porteus/pxe/pxeboot.txt
And I get correct results in web server's log:

Code: Select all

2021-05-24 10:25:09 10.20.30.40 GET /porteus/pxe/pxeboot.txt kiosk=A-AB-BCC-DD-EE 80 - 10.20.31.102 Wget - 301 0 0 2
2021-05-24 10:25:09 10.20.30.40 GET /porteus/pxe/pxeboot.txt kiosk=A-AB-BCC-DD-EE 443 - 10.20.31.102 Wget - 200 0 0 26
As with the boot sequence, config file is first accessed on port 80 (HTTP), to which server replies with 301 (redirect), after which same file is delivered via port 443 (HTTPS) with success (200).

Client boots and is online and functioning correctly.

I'm not going to test anymore, I got it working, that's all that's important :celebrate3:
But I could swear kiosk_config had issues with redirect to SSL before I changed ssl_helper in initrdpxe.xz ... I don't know if it replaces one used in the configuration script, didn't dig that deep. But if it does, that would explain it. Which would suggest that some binaries need to be changed in next Porteus Kiosk 5.x.x as well.

Thank you for your help with pointers :thumbsup:

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

[SOLVED] 'http_server=' parameter - SSL redirect? [TLDR solution: ssl_helper not working]

Post#13 by fanthom » 25 May 2021, 07:45

Will do some testing and if everything is ok then update SSL helper in next kiosk release.

Thank you for reporting and debugging.

EDIT://
New SSL helper seems to work ok so i have updated initrdpxe.xz component for 5.2.0 release.
Please add [Solved] to your thread title if the solution was found.

LuxZg
White ninja
White ninja
Posts: 26
Joined: 11 Dec 2020, 23:19
Distribution: all kinds

[SOLVED] 'http_server=' parameter - SSL redirect? [TLDR solution: ssl_helper not working]

Post#14 by LuxZg » 26 May 2021, 08:19

Awesome news, thanks Tomasz!

P.S. Glad to help :)
P.P.S. Sorry for writing your name wrong name couple days ago ;D

Locked