[Windows 7] Your connection is not private NET::ERR_CERT_AUTHORITY_INVALID for all HTTPS sites

Recently, Windows 7 users reported an error that they could not access the websites "Your connection is not private", "NET::ERR_CERT_AUTHORITY_INVALID". This error is encountered in all browsers on the machine. And it is encountered only when accessing websites with https. In other cases, the website displays a blank page because the static content files cannot be loaded. This error is encountered because the customer's Windows 7 operating system is not fully updated with security patches.

SSL certificate error on all browsers, for all HTTPS sites

Solved

To fix this, If you are using windows 7, please install security update KB3004394 from Microsoft.

You can download the KB3004394 package from the official Microsoft website using the following link:

KB3004394 Update for Windows 7 X86 (32 Bit)

KB3004394 Update for Windows 7 X64 (64 Bit)

To install the update successfully, Windows must have the Windows Update feature enabled.

After installing the update above, please clear your browser's browsing history data and restart your computer. HTTPS sites can now be accessed normally.

In addition, you should also install all the latest updates for your windows 7 operating system through the Windows Update feature. This will help keep your computer safe and less prone to problems.

Done !

Read More

[Solved] SSH and Gitlab negotiate error "no matching host key type found"

When using new Linux operating systems like Ubuntu 22.04 you may have trouble with SSH when you want to connect to old Linux servers.

Unable to negotiate with ***.***.***.*** port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

This error can be encountered when you directly access an old server via SSH. Or when you use Git, SVN, or any other software that uses the SSH protocol.

Reason

To be able to make an ssh connection, the Server and the client need to negotiate a secure connection encryption method. That is to find an encryption method that both the server and the client support. OpenSSH in older OS versions like Centos 6 only supports the old encryption standards ssh-rsa and ssh-dss. These 2 encryption standards are outdated and potentially dangerous. Therefore, the new version of OpenSSH disables these encryptions by default. Newer encryption commonly used is ssh-ed25519, ecdsa-sha2 ...

Solved

To solve this error, you need to configure ssh on the new server to accept the old encryption standards as ssh-rsa or ssh-dss (just 1 is enough). We suggest 2 solutions to do just that.

Solution 1:

Enable dss or rsa encryption for ssh on your new server.

To do so open the file "~/.ssh/config"

vi ~/.ssh/config

Then add the following content to the file (change ssh-rsa to ssh-dss if your old server only support it)

Host *

HostkeyAlgorithms +ssh-rsa

PubkeyAcceptedKeyTypes +ssh-rsa

Done ! Now you can connect ssh to old servers via terminal normally. However, if you are using Git over ssh with a privateKey file, this will not work (to solve see solution below).

Tip: you can also restrict opening this encryption method only to a certain ip by substituting that ip in the "Host: oldserverIP" section. This will make your server more secure.

Solution 2:

Enable dss or rsa encryption only when a connection is needed by adding a parameter to the ssh connect statement.

Ex: 

ssh 123.123.123.123

become

ssh -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedAlgorithms=+ssh-rsa 123.123.123.123

Done !

Fix negotiate error for Git/Gitlab via ssh privateKey file

With git or edit the config file as follows

vi yourProjectPath/.git/config

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
sshCommand =  ssh -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedAlgorithms=+ssh-rsa  -oIdentitiesOnly=yes -i /yourPath/privateKeyFile.ppk -F /dev/null
...

Done ! Your Git can now connect to the server normally and it automatically uses the privateKey file to log in instead of having to enter a password.

Read More

Laravel 9 Error: Undefined constant Illuminate\Http\Request::HEADER_X_FORWARDED_ALL

Solve the error when upgrading the system to laravel 9 or 10. "Undefined constant Illuminate\Http\Request::HEADER_X_FORWARDED_ALL"

Reason: 

As of Laravel 9, the framework switched to using a built-in middleware to handle proxy queries instead of Fideloper\Proxy\TrustProxies. So when upgrading from lower versions like laravel 5.8, laravel 8 to laravel 9 we also need to edit to replace this middleware. If you don't make changes you will get an error when you run "composer update" and you won't be able to access the website

Solve the problem:

Step 1: Edit your current TrustProxies Middleware (app/Http/Middleware/TrustProxies.php)

Step 2: Update middleware according to the following example

<?php
namespace App\Http\Middleware;
use Illuminate\Http\Middleware\TrustProxies as Middleware;
use Illuminate\Http\Request;
class TrustProxies extends Middleware
{
    /**
     * The trusted proxies for this application.
     *
     * @var array<int, string>|string|null
     */
    protected $proxies;
    /**
     * The headers that should be used to detect proxies.
     *
     * @var int
     */
    // Before...
    // protected $headers = Request::HEADER_X_FORWARDED_ALL;
    // After...
    protected $headers =
        Request::HEADER_X_FORWARDED_FOR |
        Request::HEADER_X_FORWARDED_HOST |
        Request::HEADER_X_FORWARDED_PORT |
        Request::HEADER_X_FORWARDED_PROTO |
        Request::HEADER_X_FORWARDED_AWS_ELB;
}

Step 3: Remove Fideloper TrustProxies from composer file

composer remove fideloper/proxy

Step 4: Done ! run "composer update" to complete update

Read More