How to issue identity certificates on LAN for internal services in IIS (not self-signed)?

Question

IIS

Good afternoon.
It is necessary to configure IIS certificates on one of them in a local network from computers based on Windows 10 Pro , united in a workgroup (not in a domain) and not glowing on the Internet in such a way that access from other computers through a browser, the latter confirm the authenticity of the certificate and did not display a warning about an untrusted site.
I would not want to use Self-signed certificates, since copying them to all the remaining computers on the network is not an option (there may be many of them, new machines can be added, etc.)
Ideally, when installing the service in IIS, the installer will ask (issue, generate?) a new certificate (if one is not already installed in IIS) that will be trusted for other machines on the local networkwithout copying this certificate to all machines.
There is no domain on the network, there is no windows server either, only all Windows 10 Pro.
My knowledge is not enough to correctly understand how to properly implement such a system. I would just like to get general information about what needs to be done / installed, then I can figure it out myself.
From the information found at the moment, it seemed to me that it was necessary to deploy a PKI service on the local network and request (API) certificates through it (or at least manually generate and transfer to the server). If so, then:
- Should this server have its own certificate to sign those it issues to other servers?
- if it must first be copied to all client machines, then this is also not an option, since it does not differ from self-signed and then copied to all machines? Or can I use any of mine with Let's Encrypt and generate child ones from it further down the chain?
- Should the PKI service be running all the time so that browsers on other machines can query it for the validity of internal certificates?
- will a certificate issued by PKI be issued to a server name on the intranet (for example: SERVER001 or SERVER001.local)?
- PKI should run on WINDOWS 10 (docker, VM is not an option, I'm afraid)
Or there are other solutions to this problem.
Thanks for the advice

Answer 1

All root CA certificates are self-signed. Surprise, right? :-) If on the fingers, then trust is based on the fact that "well, this is a self-signed certificate, but this is a respected office ...". Therefore, in the OS and in some browsers (Firefox, it uses its storage. Chrome or IE - they use system ones, on Windows, at least) there is a storage of root certificates of certification centers that (certificates) are trusted.
There are CAs whose certificates are signed by other CAs. But at the very top of the chain of trust are self-signed certificates anyway.
You need your own PKI, that's a fact. If there is no desire / opportunity to make a CA based on Microsoft Certification services, take the easyrsa package, sign certificates with it.
According to feng shui, the scheme is done like this - a corporate root CA (root certification authority) is created, with a self-signed certificate, on some, for example, old laptop. Then another key is generated - for the subordinate CA (sub-CA). This key is signed by your root CA certificate (from the laptop), after which the laptop is turned off and hidden in a safe. But with the sub-CA certificate, you sign all the certificates for your servers and services. Keys and CSRs should only be generated on the hosts where they will be used. This is if Feng Shui. But if you just need a lock in the address bar and the absence of swearing, you can get by with one root CA, without sub-CA, and you can generate keys with the same easy-rsa, then transferring the key and certificate to the servers you need with IIS.
The certificates of your root CA and sub-CA will need to be installed in the stores of all your desktop computers, servers, etc. And also in the browser stores if you use browsers that do not look into the system stores. This is easily done by domain policy, but since you don't have a domain, you can also script it. Use certutil, for example (if we are talking about Windows, again).
And you have IIS there, Apache or nginx, or other services that can handle TLS - this is the tenth thing, this does not change the scheme for generating and issuing certificates.

Answer 2

There is no concept of "IIS certificate". There is an SSL certificate that someone creates. The chain is always the same - there is or is being created a CA whose certificate is copied to all machines in the trusted root certificate store - You will have to do this manually if there was a domain, this is done by politicians.
After that, certificate requests are created and the certificates themselves are issued. You - only collective farm on OpenSSL for Windows, if there was a domain, it would be possible to raise the service. This would not eliminate the need for a collective farm, but it would greatly reduce its complexity.
Oh sure. You - collective farm it with your hands, if you have a domain, it is generated automatically
Necessary. And not just copy it, but install it in the store of trusted root certificates
No. No global CA will give you a subCA certificate
In general, there is such a thing, OCSP is called, but this is not about you. If you really need validity - insert CDP and post CRL
As you write, so be it.

Answer 3

Ideally, when installing the service in IIS, the installer will request (issue, generate? ) a new certificate (if this is not already installed in IIS), which will be trusted for other machines on the local network without copying this certificate to all machines.

there is no super simple solution
another issue is that certificate replication can be scripted. although in a domain it would all be easier and safer.
you can raise an offline certificate-server. but its public key still needs to be included in the number of trusted certifying centers on each client computer. the same me .. balls in profile - scripts. and again simpler and more reliable in the
ps domain

If so, then:
- Should this server have its own certificate to sign those it issues to other servers?

yes . and let it not be a surprise - just like IIS, it generates a self-signature for itself. unless of course you buy a signature for it from MS, VeriSign, etc..
there is only one principle - if the chain of certifiers does not reach the list of root trusted centers (which in modern OSes are part of the distribution, and are updated with other system patches) * - then everything the rest is self-subscription
* - or those additions by handles. from which you want to escape