Catch 22? Blocked by CORS policy: Same server, internal/external IP, no SSL

Question

My apologies if this is a duplicate. I can find a million results about CORS policy issues, but not about this specific one:

I developed a simple "speed test" site for my users (wfh employees of my company) to access. It tests speeds across the public net to different datacenters we utilize, and via the users' VPN connection to one of our DCs.

There are more complicated elements, but for a basic round-trip "ping" I have an extremely simple PHP script on the server that contains:

<?php
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: *');

if ($_GET['simple'] == '1')
    die('{ }');
?>

It is called like this:

$.ajax({
        type: 'GET',
        url: sURL,
        data: { ignore: (pingCounter.start = new Date().getTime()) },
        dataType: 'text',
        timeout: iTimeout
    })
    .done(function(ret) {
        pingCounter.end = new Date().getTime();

[...] (additional code omitted for brevity)

(I know this has additional overhead other than the raw round-trip network traffic timing, but I don't need sub-ms accuracy. I just need to be able to tell users "the problem is on your end" or "ah yes, the problem is the latency between your house and this particular DC".)

The same server running that PHP code is addressable at the following URLs at the DC wherein our VPN server lies:

http://speedtest-int.mycompany.com/ping.php
http://speedtest-ext.mycompany.com/ping.php

Public DNS resolves like this:

speedtest-int.mycompany.com  IN  A  1.1.1.1 (Actual public IP redacted)
speedtest-int.mycompany.com  IN  A  10.1.1.1 (Actual internal IP redacted)

If I access either URL from my browser directly, it loads fine (which is to say it responds with { }).

When loading via the JS snippet above, the call to http://speedtest-ext.mycompany.com/ping.php works fine.

The call to http://speedtest-int.mycompany.com/ping.php fails with "The request client is not a secure context and the resource is in more-private address space 'private'".

Fair enough, the solution is to add Access-Control-Allow-Private-Network: *, right?

EXCEPT that apparently can only be used with SSL:

https://developer.chrome.com/blog/private-network-access-update/

I have a self-signed cert on there, but that obviously fails by policy for that reason.

I could just get a LetsEncrypt cert for multiple subdomains. EXCEPT it will never validate the URL http://speedtest-int.mycompany.com because the LetsEncrypt servers won't be able to reach that to validate ownership, as it's a private IP.

I have no control over most of my users' machines, so I can't necessarily install trusted internal certs or change browser options. Most users use Chrome.

So is my solution to buy a UCC or wildcard cert?

I feel like I'm in a catch-22, and I don't want to spend however-much on a UCC cert for an internal app that will be very very very occasionally used by one of our 25 home-based employees when I want to prove that their home "internet is bad" and not the corp network.

Thanks in advance; I'm sure there's a stupidly obvious solution I'm not seeing.

(I'm considering pushing a /32 route to my VPN users for another real public IP to be used in place of the internal IP. Then I can have the "internal" test run against an otherwise publicly accessible IP which could be validated by LetsEncrypt, but VPN users would hit it via the VPN. Is that silly?)

Edit: If anyone is curious -- or it helps to clarify my goal here -- this is the output when accessing the speedtest page:

http://s.co.tt/wp-content/uploads/2021/12/Internal_Speedtest_Example-Redacted.png

It repeats for 20 cycles (or until stopped) and runs each element a varying number of times per cycle, collecting the average time for each. It ain't pretty, but it work(ed).