Problem running my site with caddy


(Mattias Palm) #1

I’m trying to use Caddy as a reverse proxy for my docker images…

Before I can start that I test run caddy.exe on my W7 machine where the stuff is installed. I can’t get it to work really :frowning:

I’m using caddy 0.11.0,
this is my caddyfile:

mysite.duckdns.org {
	tls mymail@gmail.com
	proxy /hass 127.0.0.1:8123
}

this is the result I get:
Activating privacy features… 2018/08/18 17:39:30 [mysite.duckdns.org] failed to get certificate: [mysite.duckdns.org] error presenting token: presenting with standard HTTP provider server: Could not start HTTP server for challenge -> listen tcp :80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

port 80 and 443 are opened on the router and firewall,
I DO run IIS with this site running live, should I not be able to run the site with IIS and then get https from Caddy, am I missunderstanding?

If I use tls off this is the result:

Activating privacy features… done.
http://mysite.duckdns.org:2015

The site does not work with :2015, it does work as usual if I just use http:/mysite.duckdns.org


(Matthew Fay) #2

IIS and Caddy are both web servers, and to run a website from them, they’ll need port 80 and 443. They can’t share them, so you can only run one at a time on the standard ports. You can run one on non-standard ports, of course… with the obvious downsides associated with that.

I use https://certifytheweb.com/ for the Windows Server I’m responsible for that needs IIS running for an application (but if I could run Caddy instead and ditch IIS entirely, I would).


(Mattias Palm) #3

ok,
I have removed the site from IIS.

Now I try with just home-assistant in docker that I want to run with SSL and a ddns.

this is the Caddyfile
mysite.ddns.net {  
    proxy / http://localhost:8123 {
        transparent
	    websocket
    }
    tls mymail@gmail.com
}

I get this errormsg:
2018/09/11 20:35:33 [WARNING] Sending telemetry (attempt 1): telemetry server replied with unknown content-type: 'text/plain; charset=utf-8' and HTTP 502 Bad Gateway - backing off and retrying

Don’t understand the error. I test with localhost:8123 and the container is working


(Matthew Fay) #4

It’s not an error, per se, just a warning.

I understand the telemetry server has had a hard time of things lately, on account of some pretty massive transient traffic spikes. Telemetry is optional and not integral to the core webserver functionality, you can safely ignore this warning.

Caddy should occasionally retry the connection to the telemetry server until it succeeds, so you might see a few - no more than one an hour, I think.

https://caddyserver.com/stats


(Mattias Palm) #5

ok, I removed the ca-flag and it seems to give no warnings now.

Activating privacy features... done.


http://mysite.ddns.net


2018/09/16 17:02:03 http://mysite.ddns.net


https://palmhierta.ddns.net


2018/09/16 17:02:03 https://mysite.ddns.net


2018/09/16 17:02:06 [INFO] Sending telemetry: success

But when I try to reach the site I get 403 and certs seems to not be where the should.

This is my Caddyfile:

mysite.ddns.net {
    log stdout
    errors error.log
    proxy / localhost:8123 {
        transparent
		websocket
    }
    tls mymail@gmail.com
}

(Matthew Fay) #6

Nothing in your Caddyfile is issuing Status 403 to your client.

The response must be coming from the upstream server at localhost:8123.

I’m not sure what you mean by “certs seem to not be where the should”, sorry?


(Mattias Palm) #7

Sorry for my english is hard to understand,

when I try to browse the site I get the “your connection is not secure” message. Therefore I was thinking the certs are not there or something similar


(Matthew Fay) #8

https://palmhierta.ddns.net/ is currently presenting a self-signed certificate.

The certificate is signed by/for VMware:

whitestrake at apollo in ~
❯ echo | openssl s_client -showcerts -servername palmhierta.ddns.net -connect palmhierta.ddns.net:443 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 14177236238379900396 (0xc4bfa93e9d6dddec)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, L=Palo Alto, OU=VMware, CN=VMware/emailAddress=none@vmware.com
        Validity
            Not Before: Jul  3 12:40:30 2018 GMT
            Not After : Jul  3 12:40:30 2019 GMT
        Subject: C=US, L=Palo Alto, OU=VMware, CN=VMware/emailAddress=none@vmware.com

And another quick check for headers:

whitestrake at apollo in ~
❯ curl -kIL palmhierta.ddns.net
HTTP/1.1 301 Moved Permanently
Connection: close
Content-Type: text/html; charset=utf-8
Location: https://palmhierta.ddns.net/
Server: Caddy
Date: Sun, 16 Sep 2018 23:07:46 GMT

HTTP/1.1 403 Forbidden
Date: Sun, 16 Sep 2018 23:07:48 GMT
Connection: close
Content-Type: text/plain; charset=utf-8
X-Frame-Options: DENY
Content-Length: 0

Tells us, in the first block, that Caddy is listening on HTTP port 80, but not on HTTPS port 443 (note the missing Server header and the added X-Frame-Options header, which you didn’t specify in your Caddyfile, present in the second block).

This leads me to believe that your HTTPS port (443) is forwarded incorrectly, probably to your VM and not the Caddy host.


(Mattias Palm) #9

thank you, what should I do then you think?
I’ve checked firewall and router portforwarding seems to be working.
Im running docker toolbox on win7 machine I have checked so the ports are also open in virtualbox.

If I try with traefik I can get the http forwarding working but also have problem there with https.


(Matthew Fay) #10

The port forwarding is definitely not working as expected.

I’d suggest you remove it entirely, verify that it’s removed (by getting timeouts when connecting to HTTPS), then add it again, pointing it to the IP/port that Caddy is serving HTTPS on.


(Mattias Palm) #11

ok nice, Now I seem to get the cert right but gives a 502 bad gateway instead:

image

Opened up the firewall but don’t know the next step


(Matthew Fay) #12

That’s Caddy generating that response, so we’ve overcome one hurdle at least.

The 502 error occurs when Caddy can’t get a response out of the proxy upstream server (localhost:8123).

To find out why it’s not responding properly to Caddy, you can try running curl -IL localhost:8123 from a shell inside the Caddy container.


(Mattias Palm) #13

ok interesting,

I got this when I ssh into the docker-machine:

docker@default:~$ curl -IL localhost:8123
curl: (7) Failed to connect to localhost port 8123: Connection refused

(Matthew Fay) #14

What do you get from netstat -tulpn | grep :8123?


(Mattias Palm) #15

I can run netstat -tulpn not with | grep :8123

docker@default:~$ netstat -tulpn
netstat: can't scan /proc - are you root?
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 :::9000                 :::*                    LISTEN      -
tcp        0      0 :::2376                 :::*                    LISTEN      -
tcp        0      0 :::80                   :::*                    LISTEN      -
tcp        0      0 :::22                   :::*                    LISTEN      -
tcp        0      0 :::443                  :::*                    LISTEN      -
tcp        0      0 :::2368                 :::*                    LISTEN      -
docker@default:~$

(Matthew Fay) #16

Looks like there are no programs running at localhost:8123, based on the results. Caddy can’t proxy to whatever it is, because nothing is there listening.


(Mattias Palm) #17

I thought about that, so I changed the caddyfile to proxy to the image at :9000 instead but still gives the 502 :frowning:


(Matthew Fay) #18

Alright, so what do you get from curl -IL localhost:9000?


(Mattias Palm) #19
docker@default:~$ curl -IL localhost:9000
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=31536000
Content-Length: 2748
Content-Type: text/html; charset=utf-8
Last-Modified: Sat, 28 Jul 2018 17:49:30 GMT
Date: Tue, 18 Sep 2018 06:50:17 GMT

(Matthew Fay) #20

And do you get the same result when you run it inside the Caddy container?