How to get SSL behind a shared public IP

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: I don't have one. Getting a domain wouldn't be an issue

I ran this command: Haven't ran a command

It produced this output: n/a

My web server is (include version): n/a

The operating system my web server runs on is (include version): n/a

My hosting provider, if applicable, is: not hosting, my ISP is TELMEX in Mexico

I can login to a root shell on my machine (yes or no, or I don't know): n/a

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Seems I have more general questions. Since I am a total newbie at this I don't know the keywords so I am not able to find the answers by searching the community posts.

I am trying to setup my local ZoneMinder install to run with signed SSL so I can then run ZM Event Server. I am not really interested in accessing my system from outside, except my HomeAssistance setup, which I am able to access remotely via an ngrok tunnel.

Last time I researched how to access my network behind a NATed connection (shared public IP) there wasn't an easy solution. I was mostly interested in getting into my HA remotely and that is how I found ngrok solution. I also learned that some ISPs with shared public IP4 are giving individual public IPs via IP6, TELMEX isn't doing that yet either.

Have things changed the last 3 years or so? If I am behind a NAT what are my options?

2

Hello @CancunManny welcome to the Let's Encrypt community. :slightly_smiling_face:

Let’s Encrypt offers Domain Validation (DV) certificates.

First step get a Domain.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Thank you for assisting us in helping YOU!

2 Likes
3

There are three challenge types used by Let's Encrypt (see Challenge Types - Let's Encrypt for more info) and two of them require an open incoming port to the host (port 80 or port 443). If that isn't possible, the only option you have is to use the dns-01 challenge.

See DNS providers who easily integrate with Let's Encrypt DNS validation for a thread trying to summarise DNS hosting providers which can be used easily with Let's Encrypt.

There are also free domain names available (e.g. from Freenom), but as a free service, those DNS servers might sometime perform less well.

5 Likes
4

Thank you for your time. It seems there are many steps involved which is why I might be having problems finding the right place to ask the question.

I checked the list you provided and DuckDNS is on the list. In a nut shell I would have to first get DuckDNS working to point to my server with a domain name I might registered with them. Once that is set up I would then add the SSL to that right?

Wouldn't DuckDNS need access to my port 80 or 443? Since I am behind a NAT I am not able to forwrad those ports. Is there a work around that you might know of?

1 Like
5

You have 2 general options:

  1. Use a self-signed certificate, and have your computers/devices trust it. IMHO, if this is possible it is going to be your best option because you will just "set it and forget it" once.

  2. You can obtain a SSL Certificate from LetsEncrypt for a domain of your choice, but you will need to update the certificates every 2-3 months – as there is a 90 day maximum lifetime. So you will need to either have a fully automated solution for renewing the cert and restarting affected services.

2 Likes
6

This is true, if you tried to use the ACME HTTP challenge (where Let's Encrypt would try to directly connect to the domain over port 80 and try to download a file). It wouldn't work because of CGNAT.

However, as Osiris mentioned, there is the ACME DNS Challenge. In this scenario, Let's Encrypt would only try to look up a public DNS record (hosted by e.g. DuckDNS), and no direct connection to your server would be required. Perfect for someone afflicted by CGNAT.

If you plan to run ZoneMinder on Linux, have a look at GitHub - infinityofspace/certbot_dns_duckdns: Plugin for certbot for a DNS-01 challenge with a DuckDNS domain. or other clients that support DuckDNS (like acme.sh).

5 Likes
7

Thank very much everyone that has taken time to reply to me.

The issue is that I seem to be confused as many services sortha have a very similar name.

Back when I could get a regular Public IP from my ISP, I used a service that used DNS on their name, but pretty sure it wasn't DuckDNS. With the service I could register a subname, ie mannyCPU.DNSservices.com I then ran a script on my computer (or router) that would send new public IP in case it changed. So whenever I pointed to mannyCPU.DNSservices.com it would translate to my current public IP and send me the traffic.

Now that I can't get a regular public IP I am stuck. To be honest I don't even now how to do self signed certs. I don't mind learning, but from what I understand if I use self signed certs i will run into some issues. For example seems ZMNinja Doesn't require signed certs itself, but when working with ZM Event Servers it does, but some other things work fine in Event Server without signed SSL.

I am trying to be proactive, and see if I can set up so that I can get signed certs via letsencrypt even if I have to manually update once every 3 months (might decide to go for paid version down the road).

When I google if I can access my router if I am behind a NAT most of the answers I get are two to three years old, and most say that it can't be done. Just trying to confirm if that is still the case or not.

1 Like
8

You don't need a public IP, unless you want to allow people to connect from the outside internet.

You could create a new domain called zoneminder.duckdns.org and point it to an internal IP address, like 192.168.1.123. It doesn't particularly matter. It will still work on your local network.

The key is: you can still get a Let's Encrypt certificate (see my previous links) by using the DNS Challenge in conjunction with DuckDNS. It will even be automatically renewing, if use an ACME client that supports DuckDNS.

Give it a try.

5 Likes
9

Everyone THANK YOU SO MUCH! I managed to get all my questions answered by a video made by a spanish guy in spanish. I also just realized I am able to open up ports. TELMEX gives shared public IP to DSL users, but those like us that actually have fiber we do get a public IP, and I was able to open port 80.

The key is CloudFare that someone suggested on a different forum. I did some quick reading on it, and it didn't seem to be what I was looking for, but after I watched the video it all made sense.

This is what I seem to understand now.

With CloudFare one can do many things, the two I am interested in at the moment is dynamic IP and tunneling.

If you have a dynamic IP you can use cloudfare with your own domain. If/when your public IP changes it automagically updates itself so it always points to the servers current public IP.

The other option is tunneling, that is a great solution for those that are behind a CGNAT like I thought I was. Here you run some type of process on the server (ie on a docker, via HA, etc), and then you can direct traffic using your local IPs. Pretty sure at that point SSL certs via letsencrypt wouldn't be an issue.

" You could create a new domain called zoneminder.duckdns.org and point it to an internal IP address, like 192.168.1.123 . It doesn't particularly matter. It will still work on your local network."

That is where I get a bit confused. How could I get zoneminder.duckdns.org cert to work with 192.168.1.123 if the domain itself doesn't point to the right direction. 10 different/seprate networks can each have 192.168.1.123 as the IP for the server. Could all those 10 different networks use the same SSL cert at the same time then?

1 Like
11

By using a DNS challenge to authenticate your control over that name.

They may use the same IP.
But they can't all use the same name.
Only one "person" should have the required control over that one name to obtain a cert for it.

They could use other names that all resolve to that same IP.

3 Likes
12

Hello Rg, and thank you for your reply.

I am still confused and it is not your fault. If I register Zoneminder.duckdns.org as my domain, and point it to 192.168.1.123, if my server has the same 192.168.1.123 it would work fine.

But what if I have 5 different physical locations, and each location has a webserver with local IP of 192.168.1.123 with its own ISP provider. Could I get all 5 locations to work with the one SSL cert tied to zoneminder.duckdns.org not to the actual servers?

I was under the impression that SSL was to make sure info was coming/going to the actual server it is meant to.

1 Like
13

DV certificates are Domain Validated. This means that they can be used to secure traffic to a matching domain name. Your hypothetical five locations wouldn't even need to use the same IP address, as long as the IP they used resolved from the name at the time of the connection.

5 Likes
14

In short: Yes.

Anyone with the public cert and private key could use that cert.

Furthermore, LE would issue up to five duplicate certs if they all chose to use DNS authentication to obtain their own copy of a cert with that exact same name.

4 Likes
15

Ty for your response. See what you are explaining is what I seemed to understand. I don't know the correct lingo, but in essence the SSL cert says this traffic is coming from the correct server that zoneminder.duckdns.org is pointing to. But how can we trust the server the domain is pointing to, if the domain can't reach the actual server.

1 Like
16

Trust is placed in the certificate system and the issuance process.
You "trust" the root certs and anything that have authorized.
In order to receive a valid trusted cert from a trusted root, one must prove ownership of a domain or control of an FQDN.
In this case, control of the name (via IP) can't be verified; As the IP is not routable over the Internet.
So, it must be verified via DNS.
Only persons with DNS control of that name can pass the "test".
So....
If such a cert is presented, you can be sure it was obtained using a verified method.

3 Likes
17

The SSL Cert is saying that traffic is coming from the domain and is encrypted. The concept of a "server" or which server is irrelevant.

Domain names can be resolved to IP Addresses by public DNS Systems, ISP DNS Systems, Network DNS systems and even local DNS systems (and more!). Domain names can be resolved to many different servers, whether it's a split-horizon system that handles local and public ips differently, a private/local address, or even load balanced or round-robin DNS systems. There is no one-to-one relationship between domains and IP addresses. A domain can be served off of multiple ip addresses, and a single ip address can serve multiple domains.

The role of a SSL Certificate is to ensure that, no matter where your DNS is resolved and whatever IP Address it points to, that Server is securely associated with the domain. So the IP address and server are completely irrelevant - the SSL Certificate just proves that whatever server(s) are providing info for a domain are authorized and authenticated to do so.

5 Likes
18

This in turn is done using cryptography, because the client connecting to a service can see what cryptographic key the service presented, and see whether that key matches one in a certificate that the service presented. If the service possesses a public key and a certificate that says that that public key can be used with that domain name, a client will agree that the connection is secure if it trusts the authority that issued that certificate.

In modern practice with domain validation, the certificate authority may not actually know very much information about the service or its operator. It is basically reporting on what it saw with methods that attempt to prove control over a domain name at a point in time, confirming that someone who possessed a particular cryptographic key, and wanted to use that cryptographic key for services that would be associated with a domain name, also completed challenges that indicate that that person was in control of that same domain name.

This is fairly limited assurance, but it helps prevent governments, ISPs, and hackers who have taken control of network infrastructure from being able to invisibly intercept or tamper with people's connections, which they would otherwise be able to do routinely.

6 Likes
19

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