Using Valid SSL on limited network

Hi Everybody
Sorry Im just studing and my question is not related directly to specific CA or LetsEncrypt and I hope found any answer in my first post :slight_smile:

We have a local lab in our university with more than 100 client but this network is limited to access just defined web sites or IP’s and certificates will not validate on it.

I want to know how is possible to use a valid ssl (From trusted CA not SelfSign) on a local network taht it have limited internet? (We can ask from admin to open specified URL/IP)
If Im not making mistake normally a certificate need access to CA or somewhere like that for validate root chain. is there any way to ad CA or any IP/URL in network gateway to and have valid certificate in local network that internet access is limit?

Your clients should be able to validate certificates and encrypt connections even if they were not connected to the public Internet at all, as long as the necessary root certificate is installed on the machine.

If you are experiencing validation errors on clients with limited or no Internet connectivity, it is possible that the necessary root certificate is missing. The DST Root CA X3 that Let’s Encrypt certificates chain up to was not included with earlier versions of Windows, but typically new root certificates are downloaded from Windows Update on a weekly basis. If your Windows clients are prohibited from doing this, it’s possible they are missing many common root certificates in use today.

The URLs that need to be accessible are listed here:

https://support.microsoft.com/en-us/help/2677070/an-automatic-updater-of-untrusted-certificates-is-available-for-window

It’s also possible for your network administrator to install missing root certificates on computers managed by a Windows Server via Group Policy.

Additionally, client software will connect to CA servers to check if the certificate has been revoked. Most browsers ignore it when they fail to connect to servers for such revocation checks, but this could potentially cause issues as well.

1 Like

Another consideration about such a network is the names of machines. The public CAs are forbidden from issuing certificates for names that can’t be part of the public Internet, such as hplaserjet, fileserver.local or lab.example.corp. To have publicly trusted certificates a computer needs to have a fully qualified domain name that could exist on the public Internet, even if perhaps in fact the computer is not connected to the Internet. The certificate applicant will need to demonstrate that they control this name, or if it doesn’t exist, that they would control it if it did.

Let’s Encrypt further requires that not only the names could exist, but they actually must exist on the public Internet. It’s still not necessary that the machines named can connect to the Internet, but their names must exist there.

1 Like

There are two main directions you can take:

  1. internal PKI/CA - you define a trusted CA and install its (root) certificate to all servers inside your network. This is the way enterprises take as they don’t want anyone else to see into their internal networks. Depending on your sweat/money ratio, you can either do the whole thing with “openssl” - create self-signed root cert & key, and use it to sign certificates for your servers (sweat), or use a PKI system (e.g.) EJBCA from PrimeKey with nice UI (I mention it as you can test it free with our PKI service - https://instantpki.com).
  2. external, .e.g, Let’s Encrypt - easy as you don’t have to run your own PKI system, but you need to figure out the way to authorize certification requests. LE is harder for this but you could set up your DNS record to point to a (web) server, where you will generate keys and certificates and copy them to your actual servers. An alternative is to use DNS-based authorizations. If you’re happy to pay for certificates, you could then use either API, or customer account at one of public PKI vendors. It involves some manual operations, but you don’t need to expose your “internal” domain names.

Don’t forget to monitor expiry your certificates.

2 Likes

Thanks for perfect answers.
I decide to test it with a comercial CA and a cheap DV cert from unizeto. but they told me its not possible: "Unfortunately we cannot issue a certificate for internal domain, it need to be a domain with an external access"
I have now a windows server on local network and admin can just let access to some specific URLs do you think I can have certificate from public CA?

Are they (or you) confusing internal networks with internal domain names?

Let's Encrypt can issue a certificate if you have a network with internal IP addresses (like 192.168.0.0), or a network that can't be reached from the outside, but not if you have internal domain names (like .local, .lan, and so on). The domain validation can be harder when you can't receive inbound connections because you can only use the DNS-01 challenge type.

The first question you need to answer is whether you want to be able to access your domain names from outside or only from within your internal network. The latter is easier as you can simply set a port forwarding from outside to a single machine (regardless of the domain name), which will authorize certification requests.

If you want to be able to access those servers from outside as well, you will need to configure routing properly. One way is to use HA proxy to redirects per domain name (easy to google, here's the first hit I got - HAProxy - route by domain name | Sean McGary )

If you want to use LE and don't want to copy private keys between servers, you can setup haproxy to redirect ".well-known ...." requests to a server you will use to authorize certification requests. Once an authz is created, you have 7 days to request a new certificate from any server (if it uses the same account key) as the request is pre-authorized.

The bottom line is to get right the network routing between internet and your local network.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.