wget: "Unable to locally verify the issuer's authority" - Fetching updates from gitlab.com relies on root certificate which might be missing on the host

The included wget.exe/wget64.exe use the Windows Certificate Store instead of a standalone certificate bundle. So the ability to verify the server certifiactes depends on the root certificates in the Windows Certificate Store. This is a bigger problem than one might think, because the Windows Certificate Store contains only a few root certificates by default. Missing root certificates are downloaded from Microsoft and installed in the Windows Certificate Store on the fly, e. g. when visiting a website in Internet Explorer or Chromium based browsers (which also uses Windows Certificate Store). This behavior is described in https://docs.microsoft.com/en-us/previous-versions//cc751157(v=technet.10)#how-root-certificate-distribution-works and can be observed in Windows Event Viewer, source CAPI2, event ID 4097. In most situations, this works without an issue.

But a problem arises, when the included wget binaries used. It looks like wget does not trigger the automatic root certificate download in the background. So depending on the previously validated certificates (and automatically installed root certificates) on the host, wget might fail to validate the connection. Especially Firefox users might be affected, because Firefox primarily relies on it's own certificate store and thus browsing the web in Firefox does not trigger the automatic root certificate download/installation in the Windows Certificate Store.

This is the result on a fresh Windows 7 install:

>wget https://gitlab.com/
--2020-08-24 21:12:54-- https://gitlab.com/
Resolving gitlab.com (gitlab.com)... 172.65.251.78
Connecting to gitlab.com (gitlab.com)|172.65.251.78|:443... connected.
ERROR: cannot verify gitlab.com's certificate, issued by 'CN=Sectigo RSA Domain
Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=
GB':
Unable to locally verify the issuer's authority.
To connect to gitlab.com insecurely, use `--no-check-certificate'.

Visiting https://gilab.com/ (or any other website, which relies on the same root certificate "AAA Certificate Services") in Internet Explorer or a Chromium based browser, installs the required certificate and retrying in wget afterwards succeeds:

>wget https://gitlab.com/
--2020-08-24 21:14:12-- https://gitlab.com/
Resolving gitlab.com (gitlab.com)... 172.65.251.78
Connecting to gitlab.com (gitlab.com)|172.65.251.78|:443... connected.
HTTP request sent, awaiting response... 302 Found

Running WSUS Offline Update on a host without installed "AAA Certificate Services" root certificate causes at least the following problems:

1. Misleading message about an available update when running the generator.
2. Downloading mkisofs fails rather silently (you have to inspect the log).
3. Downloading static definition updates fails rather silently (you have to inspect the log).

To reproduce the issue, try WSUS Offline Update Community Edition on a freshly installed Windows 7 system (other versions currently untested) or check for and if applicable delete the "AAA Certificate Services" from certmgr.msc, Third-Party Roots Certification Authorites folder

I am unsure how to solve this problem in the best possible way. Maybe by including a CA cerificate bundle and using it in wget instead of the Windows Certificate Store. Just using (effectively pinning) "AAA Certificate Services" might break anytime when gitlab decides to change the CA.