Local Area Network - SSL Certificate

Issuance Policy
1

Hey,

We have Redhat Linux Server and on it we are using nginx web server. this server inside LAN network. we have DNS in our LAN.

We need to enable HTTPS in nginx and we need SSL certificate for that and we have the following questions:

  1. Can we build our Root CA and get our Root CA certificate signed by letsencrypt so that we can generate our SSL certificate from our Root.

  2. Since our web servers are in LAN. Once we create the Key pair & CSR, how can we get them signed by letsencrypt since we cannot connect to internet from our LAN.

  3. Can we use IP adress of the web server as CN in the SSL Certificate or only domain name of the server can be used as CN.

Thanks.

Reagrds,

1 Like
2

Unless you're a full blown real certificate authority, it's probably not gonna happen.[quote="yjabbary, post:1, topic:24822"]
Since our web servers are in LAN. Once we create the Key pair & CSR, how can we get them signed by letsencrypt since we cannot connect to internet from our LAN.
[/quote]

You'll need a way for PUBLIC proof of ownership of a domain name. If the domain name itself isn't public, non of the required validation methods will work.[quote="yjabbary, post:1, topic:24822"]
Can we use IP adress of the web server as CN in the SSL Certificate or only domain name of the server can be used as CN.
[/quote]

Nope, Let's Encrypt doesn't offer domain validated certificates for IP addresses, nor can it include them among other SAN domain names.

2 Likes
3

If the Fully Qualified Domain Name of the nginx web server appears in the Internet’s public DNS system, even if it’s not possible to connect to this machine from the Internet, it will be possible for Let’s Encrypt to issue a certificate to you for this name, though it may prove tricky to arrange this depending on your exact requirements.

If the name could appear, but doesn’t, for example you have www.example.com on the Internet, and this server is internal.private.example.com and none of the private.example.com names are visible from the Internet, then you may be able to purchase certificates from another public CA, you should investigate resellers to find a good price.

If the name isn’t an Internet DNS name at all, for example example.corp or myserver.local then no public CA is permitted to issue certificates for these names since there is no single public authority on who owns them. You will need to use a private CA, either your own or one from a famous brand like Entrust or Symantec.

It is possible to have certificates for IP addresses, but Let’s Encrypt does not issue such certificates. Another public CA will only be permitted to issue for global IP addresses on the public Internet (not 127.0.0.1 nor 10.20.30.40, or similar) and only where they can establish you have enduring control over that address, for example because it was directly assigned to you by an Regional Internet Registry such as ARIN or RIPE. Most organisations cannot qualify under this rationale. Also, an IP address certificate is only useful on the web when you specify the IP address (not a name) in the URL, as this part of the URL must exactly match the name in the certificate.

1 Like
4

hi yjabbary

sounds like what you are after is an internal CA. if your servers arent internet reachable then public validation isnt as useful.

you will need to distribute your intermediate certificates to the machines that need to access your servers so they trust your internal CA.

its quite common for companies to run a combination of internal CAs and publicly trusted CAs (symantec, letsenctrypt, etc)

5

If you are using a REAL domain name that you registered you can use “ACME DNS challenge” validation instead of the more typical http challenge. This will require that you have a (partial at least) public DNS setup for the domain. The public DNS only needs to have TXT records in place while the challenge is taking place and can be otherwise empty, no public A / AAAA records needed which it sounds like you use your internal (non-public) DNS “in our LAN”. Your internal secure servers can then use non-routable IPs like 192.168.0.10.

I currently use this kind of setup for several internal secure servers using a domain registered and (public) DNSed at hover.com and the bash LE client https://github.com/lukas2511/dehydrated with a DNS challenge plug-in I wrote myself https://github.com/mscalora/hover-cli, there are dehydrated plug-ins for many DNS providers (usually registrars) and some DNS open source servers.

1 Like
6

To piggy back on what Osiris said, per the CAB Forum, as of Oct 2016, all public CAs were supposed to revoke all certificates that used an IP address (either IPv4 or IPv6, both publically routable [e.g. 8.8.8.8] and publically nonroutable [e.g. 192.168.1.1]) or an intranet domain (e.g. nicks-pc.local). So you won't find any public CA doing it. Back in the day one used to be able to do it and many did for nonroutable IPs that were used on intranets. It was a huge MitM waiting to happen since there's 0 validation that can be done.

7

I would be very interested to learn where this idea came from. The actual text in the BRs says
"Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name."

Publicly routable IP addresses continue to be plausible Subjects for certificates in the Web PKI. They aren't a good choice for most people, and Let's Encrypt doesn't offer them, but they are not prohibited.

8

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