I can confirm this locally, as I use a non-TLD self signed server config and the following error is shown:

Requesting 'https://matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F' resulted in an error: curl_exec: operation timed out after 2001 milliseconds with 0 bytes received. hostname requested was: matomo. As a result, tracking Heatmaps and Session Recordings may not work. You may need to change your webserver configuration to allow access to this file via the Internet or Intranet.

A quick hack to disabling the CURL_VERIFYPEER and CURL_VERIFYHOST options on the request allows the check to complete successfully, so this error is probably caused by CURL rejecting the self signed certificate.

Although the HSR check could be changed make the request with the $acceptInvalidSslCertificate parameter, I don't think we'd want to accept invalid certs by default.

It might be better to have a config option to always allow self signed certificates for specific named hosts so internal server setups with https can be supported.

Something like:

[General]
ignore_invalid_ssl_certs_for_hosts[] = "matomo"

Then sendHttpRequestBy() could disable CURL_VERIFYPEER and CURL_VERIFYHOST options if the request if for a host in that list.

Could this maybe be resolved by using a custom certificate bundle then? There is a config option for it: https://github.com/matomo-org/matomo/blob/4.x-dev/config/global.ini.php#L833

FYI not sure if the user is seeing the same error message as you do:

Error: The URL '$MATOMO_URLplugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F' seems to be not accessible from the Internet or Intranet. As a result, tracking Heatmaps and Session Recordings may not work. You may need to change your webserver configuration to allow access to this file via the Internet or Intranet.

Looks like it's a different issue from ssl certs then. That message is shown if there was a response but it didn't include the string piwik.heatmapsessionrecording, unfortunately the HSR check doesn't write a debug log with the exact response.

What is shown if https://matomo-site/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F is accessed with a web browser?

It's shows the expected output:

wget an cURL return the same response as well when executed from the Matomo server:

root@vmt-webstat-01:/tmp]# wget 'https://webstat-tst/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F'

--2021-12-17 11:02:36-- https://webstat-tst/matomo/plugins/HeatmapSessionRecording/configs.php?idsite=1&trackerid=5lX6EM&url=http%3A%2F%2Ftest.test%2F

Resolving webstat-tst (webstat-tst)... 172.26.X.X

Connecting to webstat-tst (webstat-tst)|172.26.X.X|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [application/javascript]

Saving to: 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F'

configs.php?idsite=1&trackerid=5lX6EM&url=http: [ <=> ] 116 --.-KB/s in 0s

2021-12-17 11:02:36 (85.6 MB/s) - 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F' saved [116]

[root@vmt-webstat-01:/tmp]# cat 'configs.php?idsite=1&trackerid=5lX6EM&url=http:%2F%2Ftest.test%2F'

Piwik.HeatmapSessionRecording.configuration.assign({"heatmaps":[],"sessions":[],"idsite":"1","trackerid":"5lX6EM"});

The output looks okay and there clearly isn't any issue with server itself accessing it. I think we'll need to see details of the response or error to work out why the check code is failing.

Would it be possible to temporarily add the following line to plugins/HeadmapSessionRecording/Diagnostic/ConfigsPhpCheck.php on line 80 just after the try/catch block then try ./console diagnostics:run?

\Piwik\Container\StaticContainer::get(\Psr\Log\LoggerInterface::class)->error("Response:".json_encode($response)." Error: ".$error);

That should spit out an error showing the exact response and any possible exception message.

If that's not appropriate then I could submit a PR for the HSR plugin to add some detailed debug logs for when this check fails, but that would only be available in the next plugin release.