You cannot obtain certificates in the Web PKI ("SSL Certificates" that "just work" in people's browsers) for private names like this "friendlymachinename". Public CAs are forbidden from issuing anybody such a certificate.

Such names are a bad idea for a wide variety of reasons and you should definitely look to give the machine a name from the Internet's DNS (even if the machine isn't accessible in any way from the public Internet), but assuming you cannot or don't want to for now:

You can use a variety of thin "reverse proxy" services to just wrap the HTTP service as HTTPS. Many such webapps won't care that this happened, as the maintainer you probably have a good sense of whether it could work (does the webapp use Javascript that cares about its own URLs for example because that could be a problem?). HTTPS servers such as nginx are well suited to this problem. Security between the wrapping proxy HTTPS server and your PHP on IIS setup is still zero in this setup but that might be acceptable.

As its internal, you'll need to look into setting up a PKI. You'll need to create a certificate authority that has its public cert installed on every host accessing the internal site, and then you use that CA to sign the certificate for the internal site.

This sounds like it could work. Since it's a workplace server and is only accessed internally by workplace-issued machines (which are always on the workplace VPN), I think there might be some sort of public cert already in place. Guess I just have to hunt down a certificate!

It's still preferable to use a real DNS name and a real certificate, if you possibly can, which means that nobody has to install a CA.

There's currently no way on any modern system, as far as I'm aware, to install a CA but limit it to only a specific domain and its subdomains; any CA you install can issue a certificate for any domain. (There are theoretically some certificate extensions that allow limiting a certificate to subdomains, but as far as I can tell, implementations don't reliably support those extensions.)

I'm currently using the DNS challenge of Lets Encrypt for something similar. My setup is a VM running docker with multiple sites. I just setup a DNS record (it only points to the IP of the VM which is a private (eg 192.168...) one) and setup traefik as the reverse proxy with the DNS challenge. Works really well except that my router blocked the DNS record at first.

The machine that's running this has no Internet connectivity though (which is a big reason why it's running that stack in the first place!), so I'm not sure if that approach would work?

It's a workplace server as well, so I don't really have the freedom to punch holes for outside access.

You can issue a certificate for it just via DNS challenge on another system, and then get the keys+cert to the actual system.

The crucial question is: do you control your users's DNS?

I had a setup like this in college, and wrote this: https://blog.sdslabs.co/2014/07/sdslabs-domain-working

You can use Let's encrypt and their DNS validation method, and set up a machine.internal.corp.com DNS entry pointing at its internal IP address.

Only problem is that you'll need to update DNS records every three months to get a new cert; some DNS providers have APIs that certbot can use.

You could run your own CA if everyone trusts you. Or you could set up DNS which is probably a better idea.

IIS 7.5?

Just checked, and it says IIS 8.5.