laragon and https

[roberto21350]

it seems I am not able to have laragon working in my system, I keep getting (Chrome, Brave)

"This site can’t provide a secure connection
testem.test sent an invalid response.
ERR_SSL_PROTOCOL_ERROR"

Apache ssl is enabled, laragon.crt is added to the trust store, and still it does not work. I admit I am not very expert, but on my previous computer everything was working fine. Here I had to change port 80 to 88 because port 80 is used by a system process (pid 4) and, as far as I know and my experience allows, cannot be changed. Can this be the reason? and if so, what can I do?
Note that on Firefox browser the error is
Error code: SSL_ERROR_RX_RECORD_TOO_LONG

[leokhoa]

@roberto21350 : I will take a look at this. Will keep you posted.

[roberto21350]

Managed to remove system process from port 80 thanks to a suggestion found on the web. Restored listening port for apache to 80, now laragon works fine again , site is marked as secure by chrome. So it looks like the port assignment to 80 is mandatory. This does not appear to be correct anyway: if you allow to select the port for apache, the choice of a port other than 80 should not prevent laragon from working. PLease advise. It seems that the same problem also happens on xampp and wamp.

[ppfoong]

Don't mess up with well-known ports, which their port number is in the range of 0-1023.

The well-known ports have specific service.

Port 80 is HTTP, port 88 is Kerberos, and you should use port 443 for HTTPS.

[roberto21350]

I don't think I understood completely. Are you saying that I should have left system process (PID 4 with description NT kernel & system) to 80? All right, but in this case how can I make Laragon (or xampp, or wamp) to work? They all seem to expect port 80 to be free. I don't want to "mess up" anything. I only remarked that if you allow Laragon to change port 80 to another port, this should not prevent Laragon from working. If 80 is mandatory, say so; and if port 80 is taken by a system process, Laragon does not work. End of story.

[ppfoong]

You can change port 80 to a number between 1024 and 65535, such as 8888.

After you have changed the port, your URL needs to follow accordingly, eg. http://yourhost:8888

You can download and run TCPView from this URL to check what are the services running on your computer:
https://learn.microsoft.com/en-my/sysinternals/downloads/tcpview

Past the screenshot here.

[roberto21350]

I believe you have not read my posts .Anyhow, I tried again, selecting port 8888 for Apache (443 remain untouched, of course). Unfortunately, I am back to the usual error: url testem.test:8888 results in

This site can’t provide a secure connection
testem.test sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Restoring 80 to Apache eliminates the error. So, as I said, Laragon (xampp, wamp) for some reason needs port 80 for ssl (https) to work. As I said, I am not that expert, but this is the conclusion I am forced to accept. If there is something I am missing or some solution to the problem, I will be more than happy to learn it.

[ppfoong]

If port 443 remains untouched, try:
https://testem.test

Also, try using web browser incognito mode. If you have any web filtering antivirus software running, try disable the web filtering feature.

I tested in my computer and it works well, nothing wrong.

[roberto21350]

https://testem.test (and https;//testem.test:8888) do not work in chrome and similar browsers, not even in incognito mode. As you probably know, Chrome forces https, and there appears no way you can force http. Firefox, on the other end, gives the error : SSL_ERROR_RX_RECORD_TOO_LONG

but of course the conclusion is the same: laragon does not work with port other than 80. I am glad it works well on your pc (I assume you mean that works with port 8888 for Apache: with port 80 everything works also for me). I have no problem with the antivirus, so I am short of other things to try. Can it be some quirk of windows 11? Anyway, Leokhoa said he would look into the matter, he may very well explain the mystery.

[leokhoa]

@roberto21350 : I noticed you had already resolved the issue, so I didn't reply earlier. Your solution - stopping the PID 4 process - is perfectly fine and poses no risk.
For reference:
Port 80 is being used by System (PID 4). What is that?

[roberto21350]

Well, Leokhoa, I did not resolve the issue, I just bypassed it. The issue remains: is port 80 mandatory for Laragon? And, if so, would not be better to state it clearly and eliminate the possibility of choosing a different port?
If this is not the case (assuming instead that Laragon works with port other than 80, as ppfoong seems to imply), why doesn't it work in my pc? It seems peculiar that Laragon needs port 80 for ssl, but I am not knowledgeable enough to understand the problems involved. Thank you both for the interest and patience

[leokhoa]

@roberto21350 : When you enable SSL in Laragon, it automatically sets Apache to use port 443/https by default. Port 80/http is not required for Laragon to function properly. However, if you're experiencing issues and suspect another process is using port 80/443, you can troubleshoot by navigating to Tools > Netstat in Laragon to identify any conflicting processes.

[roberto21350]

I had already used netstat, but I repeat here what I have already done. Remember that I have already freed port 80 from the NT-kernel system process. Now, with Apache listening on port 8888, port 80 does not appear in the netstat list at all; with Apache listening on port 80,, port 80 is indeed linked to Apache (see following list). In both cases, port 443 is correctly assigned to Apache, even though with Apache on port 8888 Laragon ssl does not work. So, if I have to trust netstat, 80 is only used by Apache

Proto Local Address Foreign Address State PID Path
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 26680 D:\laragon\bin\apache\httpd-2.4.54-win64-VS16\bin\httpd.exe
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 2100
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 26680 D:\laragon\bin\apache\httpd-2.4.54-win64-VS16\bin\httpd.exe
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:2008 0.0.0.0:0 LISTENING 6012
.................
TCP [::]:80 [::]:0 LISTENING 26680 D:\laragon\bin\apache\httpd-2.4.54-win64-VS16\bin\httpd.exe
TCP [::]:135 [::]:0 LISTENING 2100
TCP [::]:443 [::]:0 LISTENING 26680 D:\laragon\bin\apache\httpd-2.4.54-win64-VS16\bin\httpd.exe
TCP [::]:445 [::]:0 LISTENING 4
TCP [::]:3306 [::]:0 LISTENING 18672 D:\laragon\bin\mysql\mysql-8.0.30-winx64\bin\mysqld.exe

[ppfoong]

Can you paste the last 30 lines of this file here?
D:\laragon\bin\apache\httpd-2.4.54-xxxxxx-win64-VS16\logs\error.log

Also, do you see anything abnormal in access.log in the same folder?

[roberto21350]

logs.zip

[ppfoong]

From this error message, it seems that you have a problematic Rewrite Rule, probably in .htaccess setting or header function call in PHP script: "Request exceeded the limit of 10 internal redirects due to probable configuration error. ".

Also, this error message indicate permission issue, probably in the setting of httpd.conf: "client denied by server configuration".

access.log showing that you are using WordPress. To check whether this issue is WordPress related or Apache related, you can create a new file inside testem, name it as info.php, with the following content:

<?php phpinfo(); ?>

Are you able to run it:

1. using local domain name?
2. using IP address?

If info.php can be run without problem, the your issue is WordPress related. If info.php also having problem running, you will need to check your .htaccess, httpd.conf and other related Apache config.

[roberto21350]

I am not sure I understood completely what I am supposed to do. Of course, writing
https://testem.test/info.php
results in the same error when apache is set to 8888, whereas it works fine when apache is set to port 80. Is this the test you asked for? When you say "using ip address", do you mean
localhost/testem/info,php
If so, the result is the same: does not work with apache set to 8888, works fine with apache set to 80.
The .htaccess file is genuine wordpress:

BEGIN WordPress

The directives (lines) between "BEGIN WordPress" and "END WordPress" are

dynamically generated, and should only be modified via WordPress filters.

Any changes to the directives between these markers will be overwritten.

RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase /testem/ RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /testem/index.php [L]

END WordPress

I would not know how to " check your httpd.conf and other related Apache config"....

If the issue is wordpress related, it remains to be seen why the exact same site works OK in the field. I am using laragon as a sort of backup and for some tests, so the site is an exact copy (backup/restore using updraft) of the real site.

[roberto21350]

I have news.
With Apache set to listen on port 8888, selecting Menu->www->testem results in the address testem.test:8888 in the browser address line and in the usual error:

This site can’t provide a secure connection
testem.test sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

So far nothing new. But, if I remove the :8888 and leave testem.test, everything seems to work fine: no error, site "secure". The same withb localhost/testem instead of localhost/testem:8888. I did not think of this because I assumed that getting to the site via Laragon menu was correct by definition. It looks like this is not the case. I don't pretend I undesrtood what is going on here, but at least it seems we have a solution.

[ppfoong]

I assume port 8888 is normal http. If you try to access normal http port with https protocol, depends on your server config, there are several possible responses:
Scenario 1: your server will auto-redirect the access to its https port (port 443) and your connection is "secured".
Scenario 2: the redirection is not happening, and you get an error, such as "ERR_CONNECTION_REFUSED".

I tested with my Laragon. If you access the webpage through Menu->www->website, it will access using the http (non-SSL) protocol and not the https protocol.

Your https (port 443) seems to work fine, as you are saying you are able to access the "secured" page.

I guess you have a mechanism to redirect all your http access to https, and that redirect setting only works on port 80. That setting is probably inside .htaccess

Open your .htaccess file with Notepad or any text editor, if you see something like this:

NameVirtualHost *:80
<VirtualHost *:80>
ServerName testem.test
Redirect permanent / https://testem.test/

Change the two 80 in the file (in the top 2 lines in above code) to 8888, that should fix the issue.

[roberto21350]

There are no such lines in my .htaccess, Do you think 8888 is a special (http) port? I don't know. I changed 8888 to 7654 and the behaviour is exactly the same. It seems there is no need to mess with .htaccess, it is enough to remove the port number from the address. If this is the solution, so be it: that does not mean I understand what is happening here...

[ppfoong]

I checked the files in my Laragon, and I think I found where is the config likely to be in.

Are you able to see a conf file related to your website in this folder?
D:\laragon\etc\apache2\sites-enabled

Opening that file, are you able to see something like this?

<VirtualHost *:80>
DocumentRoot "${ROOT}"
ServerName ${SITE}
ServerAlias *.${SITE}
<Directory "${ROOT}">
AllowOverride All
Require all granted

<VirtualHost *:443>
DocumentRoot "${ROOT}"
ServerName ${SITE}
ServerAlias *.${SITE}
<Directory "${ROOT}">
AllowOverride All
Require all granted

SSLEngine on
SSLCertificateFile      D:/laragon/etc/ssl/laragon.crt
SSLCertificateKeyFile   D:/laragon/etc/ssl/laragon.key

These files should be auto-generated by Laragon. If you changed port 80 in Laragon setting, it should reflect here in VirtualHost too.

By the way, your issue seems to be SSL keypair or certificate related. The easiest way is to regenerate a set of new SSL files.

You can stop Laragon, then go to D:/laragon/etc/ssl/ and create a new folder D:/laragon/etc/ssl/backup/ then move the 3 files laragon.crt, laragon.csr and laragon.key into the backup folder.

Run Laragon again, a new set of SSL files should be auto-generated. Then you can test whether the issue still happen or not.

[roberto21350]

Yes, I do have the file auto,testem.test.conf in that directory, containing

define ROOT "D:/laragon/www/testem"
define SITE "testem.test"

<VirtualHost *:7654>
DocumentRoot "${ROOT}"
ServerName ${SITE}
ServerAlias *.${SITE}
<Directory "${ROOT}">
AllowOverride All
Require all granted

<VirtualHost *:443>
DocumentRoot "${ROOT}"
ServerName ${SITE}
ServerAlias *.${SITE}
<Directory "${ROOT}">
AllowOverride All
Require all granted

SSLEngine on
SSLCertificateFile      D:/laragon/etc/ssl/laragon.crt
SSLCertificateKeyFile   D:/laragon/etc/ssl/laragon.key

As per your second suggestion, I moved the files in the backup folder, but running Laragon failed with the error

[MackSix]

On the largon menu, go to Apache>>SSL and add laragon.crt to Trust Store.

If that works, it's a bug that I already reported. You may have to do this each time you add a new project until the bug is fixed.

[ppfoong]

Yes, I do have the file auto,testem.test.conf in that directory, containing

define ROOT "D:/laragon/www/testem" define SITE "testem.test"

<VirtualHost *:7654> DocumentRoot "${ROOT}" ServerName ${SITE} ServerAlias *.${SITE} <Directory "${ROOT}"> AllowOverride All Require all granted

<VirtualHost *:443> DocumentRoot "${ROOT}" ServerName ${SITE} ServerAlias *.${SITE} <Directory "${ROOT}"> AllowOverride All Require all granted

SSLEngine on
SSLCertificateFile      D:/laragon/etc/ssl/laragon.crt
SSLCertificateKeyFile   D:/laragon/etc/ssl/laragon.key

As per your second suggestion, I moved the files in the backup folder, but running Laragon failed with the error

It seems that new set of files are not generated.

Try move back the 3 files from backup to original location, then run the add laragon.crt to truth store as suggested by MackSix.

[roberto21350]

I am not sure what should work after adding laragon.crt to truth store. If you mean the test suggested by ppfoong, the result is the same: apache could not start etc. ,etc.

[MackSix]

Do what ppfoong just said in his latest reply.

[roberto21350]

That is exactly what I did.

1. restore files to ssl folder
2. add laragon.crt to truth store
3. move files again to backup folder
4. start laragon
   as I said the result was the same: apache could not start

[ppfoong]

You don't need step 3.

I thought when the files are not found (moved to backup folder), Laragon will generate a new set of files. But it seems the generation of new set of files did not happen. Therefore, need to place back the files in the backup folder to its original location.

[roberto21350]

I don't get it: is it a bug (files should be regenerated if missing) or not?
and if ", your issue seems to be SSL keypair or certificate related" the issue is still present ?