HTTPS in Local Network not working

FuturApp · November 4, 2021, 6:16pm

1. Caddy version (`2.4.5`):

2. How I run Caddy:

I run caddy in my home network, the main computer ip is 192.168.1.100, and I have another computer wit the ip 192.168.1.78.
I have my node server runnig on main pc at 192.168.100:2021, this is the server I want to https to my other computer.

a. System environment:

Windows 10 with caddy.exe

b. Command:

caddy run

c. Service/unit/compose file:

Not using

d. My complete Caddyfile or JSON config:

192.168.1.100:2020 {
  reverse_proxy 192.168.1.100:2021
}

3. The problem I’m having:

SSL is not working from the other computer to my main, certified is not valid, I understand that the certified is only for 192.168.1.100, but how can I use it from any computer???

4. Error messages and/or full log output:

In the browser the https is crossed and it says that the cerfied is not valid and its a security risk.

5. What I already tried:

I’ve tried doing this:

server.local {
  reverse_proxy 192.168.1.100:2021
}

192.168.1.100:2020 {
  reverse_proxy 192.168.1.100:2021
  tls internal
}

But my other computer cant connect to this types of url, only ip’s.

Also messing with tls, but my knowledge is not to great. And the caddy didnt start.

I’ve tried everything in the link below.

6. Links to relevant resources:

https://www.google.com/search?q=caddy+cannot+access+a+lan+stackoverflow+site:stackoverflow.com&sxsrf=AOaemvLOiRzxb1ufm4m_WmSQRKA5MDaL8Q:1636048746657&sa=X&ved=2ahUKEwjMjoTDpP_zAhWJxoUKHScBDNgQrQIoBHoECAcQBQ&biw=1920&bih=937&dpr=1

agrajag · November 4, 2021, 10:22pm

The configurations that you are showing are not going to work, in that you are setting up rules for caddy on your “main computer” to listen on 192.168.1.100 on port 2020, and then “reverse proxy” (send the traffic to) the same computer on port 2021 in the configuration example you gave (both hosts are listed as 192.168.1.100).

Consider the following “structure” to the configuration rule you are attempting

host_ip_caddy_will_listen_on:port_on_caddy_host  {
             reverse_proxy  host_ip_of_the_other_computer:port_on_that_other_host
}

so for the configuration you are describing in your opening statement it should look more like this, note that you can specify https:// for the rule so caddy knows to use its local root and intermediate CA to issue a certificate to be used when clients connect to that host over https.

https://192.168.1.100 {
        reverse_proxy http://192.168.1.78:2021
}

Note the following

Caddy in its default configuration can NOT provide a certificate for the 192.168.1.78 host if its running on the 192.168.1.100 host. The connection from the caddy server back to the second (192.168.1.78) server will need to be HTTP not HTTPS. You could set up caddy on both hosts and have caddy provide a TLS certificate for https on each host, but that looks to be overly complex for what you are trying to do.
Your browser WILL NOT TRUST the Certificate Authority (CA) that is issuing the TLS certificate caddy is using, unless you are running the browser on the 192.168.1.100 host. You will receive a certificate trust error on connection to the 192.168.1.100 host if its a different machine, no matter what. You would need to import the caddy local root CA certificate into your local trust store on the computer your browser is running on for it to work without trust warnings. Caddy on windows will install its root CA automatically into the windows user trust store, so you would need to export it from there and then import it on the computer your browser is running on. (I’m not 100% sure on windows where caddy stores its root.crt file or if its only ephemeral as its imported into the windows local user’s trusted authority store).
Why all the complexity here? What is the benefit of 2 computers serving what is a single web server here and the need for 2 separate HTTPS listeners. A far simpler configuration would be to have caddy running on the same host (192.168.1.78) with a configuration like so:

https://192.168.1.78:2020 {
     reverse_proxy https://localhost:2021
}

Watch the following guides to understand the basics HTTPS, Certificate Authorities, certificates and trust. Realize that caddy server is acting as the CA for issuing a certificate on demand to itself for the host you are configuring it on. When it does this on windows it installs the CA into the local windows user’s trust. But that locally installed trust wont work if you are running your browser on a different computer.

Intro to digital certificates

Digital Certificates: Chain of Trust

Then read caddy’s documentation on local automatic https

One fundamental thing to understand is that each individual host (the main computer and the other computer) would need a TLS certificate issued to protect the host name / IP address. Caddy takes care of setting up a local Certificate Authority and issuing certificates to protect hostnames and IP addresses for the system it is running on by default.

francislavoie · November 5, 2021, 12:11am

As on Linux, it will be stored in Caddy’s default storage location. Starting Caddy with the --environ flag will reveal where the AppData location is for Caddy in the logs. It depends how it’s being run and what under which user Caddy is being run. Then in the storage, the CA cert will be at pki/authorities/local/root.crt

agrajag · November 5, 2021, 2:13am

Thanks @francislavoie!

So @FuturApp, what that means is on the server you are running caddy on 192.168.1.100, that you should start caddy with the configuration based on the example I gave

https://192.168.1.100 {
        reverse_proxy http://192.168.1.78:2021
}

You would run from the command line caddy run --environ --config <file> to identify caddy’s configuration path, and then use file explorer to [that path given by the caddy --environ command]\pki\authorities\local\root.crt. Note that the --config <file> would point to the Caddyfile you are passing your configuration statement in for the server and reverse proxy statement we talked about above.

Copy root.crt to the computer you are running your browser on (if its not 192.168.1.100) and then you can follow these instructions to install that root.crt Certificate Authority (CA) certificate in your browser. Depending on your browser type you might need to google for specific instruction, but if you are using chrome you can follow this guide to install trust in your windows desktop login:

https://intercom.help/yukon/en/articles/1003595-securly-ssl-certificate-manual-install-in-chrome

There are more detailed ways to do this (for example installing trust for all users in the local machine rather than specific user account)

or if on mac OS

Or ubuntu

Note that this certificate authority certificate will NOT give you https on your 192.168.1.78 server. If you watched the material I shared you should understand at this point the difference between a CA certificate (what we are talking about now) vs a Private key and certificate issued to the host IP or FQDN which is what would be required to ALSO have HTTPS for the server on the 192.168.1.78 host.

Watch the videos, read the docs, let us know if you have any further questions.

FuturApp · November 5, 2021, 6:35am

Wow… Thx guys for all this information and your time, Im going to read all of this and try everything, then I’'ll give some feedback, thx again.

agrajag · November 16, 2021, 3:14am

How goes it? Any questions on what you have reviewed so far?

system · December 4, 2021, 6:17pm

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