Failed to get certificate


(Mike Park (Parkie)) #1

I’m trying to start Caddy and then use it as a simple reverse proxy.

I’m using the following download
https://caddyserver.com/download/windows/amd64?license=personal&telemetry=on

I’m running on Windows 10 x64
I’m try to register my ddns hostname, myusername.asuscomm.com
Caddy has been extracted to c:\caddy
running with c:\caddy\caddy.exe -host myusername.asuscomm.com
my router has port 80 and 443 forwarded to my main desktop PC where I have apps running I wish to access externally using things things like

caddy file C:\caddy\Caddyfile

myusername.asuscomm.com {
proxy /myapp 127.0.0.1:38081
}

Activating privacy features… host failed to get certificate: host error presenting token: presenting with standard HTTP provider server: Could not start HTTP server for challenge -> listen tcp :80: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

if I try

192.168.1.2 {
proxy /myapp 127.0.0.1:38081
}

then I get output

C:\caddy>caddy.exe
Activating privacy features… done.
http://192.168.1.2:2015

but accessing http://localip/myapp/ then gives me a 404

Stupid question, should I be using the DDNS server name or the IP local of my machine?

I have honestly read the documentation but clearly I’m missing something obviously and need a little help :slight_smile:

Thanks advance


(Matthew Fay) #2

Hi @mikeparkie, welcome to the Caddy community.

This part is most important:

In plain English, you’ve got another program running and it has port 80 reserved for its use; you can’t run two programs listening to the same port of the same interface.

When you change the site label to 192.168.1.2, you can see that Caddy outputs http://192.168.1.2:2015 on startup. Accessing that would work, but not http://192.168.1.2/, because there’s an implicit :80 on the end there (the assumed default port for HTTP).

The 404 you’re getting from http://localip/myapp/ will be from whatever other program you have running on port 80. It might be another Caddy, or perhaps IIS. Using curl -I http://localip/ or the inspector console on your browser to get the headers might tell you which - all the major web servers announce themselves with the Server header.


(Mike Park (Parkie)) #3

@Whitestrake cheers fella,

I couldn’t for the life of me work out what else was running on port 80, I used netstat and then saw it was EventGhost (webserver plugin addon), completely forgot about that. Thanks for pointing me in the right direction.

I’ve been able to start Caddy :slight_smile:
caddy.exe
Activating privacy features… done.
https://myusername.asuscomm.com
http://myusername.asuscomm.com

I’m very new to using reverse proxies, I was playing with ngnix, I had that working for the most part until I read about Caddy on Reddit and it’s ability so provide SSL from the get go, so I choose to explore it some more.

In a bit more deal, heres what I’m trying to achieve.
I want to be able to secure several webapps running on one PC using SSL
I want to access the pages internally / externally
I want to redirect calls from 80 straight to 443, I will just port forward 443 on my router to my machine
I need some assistance in getting the syntax correct in my caddyfile to achieve this

Here’s the config I had working from ngnix config into Caddy’s. Here is what I had setup for gninx

location /sabnzbd {
proxy_pass http://127.0.0.1:38081;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /sonarr {
proxy_pass http://127.0.0.1:38082;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /radarr {
proxy_pass http://127.0.0.1:38083;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /nzbhydra {
proxy_pass http://127.0.0.1:38084;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header Scheme $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_redirect off;
}

Here is my current Caddyfile now file. Basic I know, hence asking for help.

From what I read all of the proxy header stuff is now handled by transparent, so I don’t need to mention it in the caddyfile?

https://myusername.asuscomm.com, http://myusername.asuscomm.com {                       

gzip 
           
proxy /sabnzb 127.0.0.1:38081 {          
    transparent
}
  
proxy /sonarr 127.0.0.1:38082 {          
    transparent
}

proxy /radarr 127.0.0.1:38083 {          
    transparent
}
   
proxy /nzbhydra 127.0.0.1:38084 {        
    transparent
}

I’m just testing on the first link at the moment
https://myusername.asuscomm.com/sabnzbd directs to http not https when accessing it from my PC. Using the localhost link loads correctly which it should. Clearly I’m missing something. I’ll carry on playing and hopefully I’ll work it out. But if someone could help me get my caddyfile in order I’d be greatful.

Thanks


(Matthew Fay) #4

Looks good. You might change:

https://myusername.asuscomm.com, http://myusername.asuscomm.com

to:

myusername.asuscomm.com

which Caddy will take as a cue to automatically handle both protocols, redirecting HTTP requests on port 80 over to HTTPS on port 443.

This shouldn’t happen at all - Caddy will never downgrade from HTTPS automatically, and you haven’t explicitly configured it to do this either. If you’re getting redirected from HTTPS to HTTP, something else is happening (another reverse proxy in the middle?).


(Mike Park (Parkie)) #5

Sorry, I’ve been out of the country for a week…

Not sure exactly what was causing my issue, I turned it off and on again :slight_smile: and now it’s working. Also updated my Caddyfile to file as your described, and it’s now directing to HTTPS as you said it would. I’ve gone a little further and added caddy to run as a service. Pretty happy with the implementation now.

I’ve got another couple of (probably) stupid questions to ask:

Do I have to keep port 80 forwarded on my router? will HTTP forward to HTTPS if it can’t get to port 80 to start with? I just wan’t to lock things down as much as possible.

I know it’s my choice, but is it better to secure an app with it’s own auth or use caddy auth? I guess with app auth I’d have a username and password for 4 apps as opposed to one at the caddy level. Also reading through the docs, there seems to be serveral auth options, basic auth / http.authz, what’s the best approach (in your opinion).

Thanks again for the replies.


(Matthew Fay) #6

Yes. Someone who’s never visited in the past won’t have the redirect cached by their browser, so they’ll actually attempt to connect on port 80, and a failure will be treated like an error.

Impossible to say. The majority of Caddy’s auth systems seem well implemented. I’m not sure how secure the apps are, though.

You’ll only need one at the Caddy level because your apps appear to be on the same domain. If you were to use subdomains, for example, basicauth would require you to enter your password each time you browse to a new subdomain.

I like the jwt/login because it lets me keep a single authentication valid across multiple subdomains. I fiddled with it for some time to get it exactly right for my purposes, and I settled on configuration like this:

(secure) {
  jwt {
    path /
    redirect /login?backTo={uri}
  }
}

my.example.com {
  # Landing page config

  # Loginsrv
  login {
    login_path /login
    logout_url my.example.com
    redirect_check_referer false
    cookie_domain example.com
    htpasswd file=/etc/.htpasswd
    jwt_expiry 12h
  }
}

foo.example.com {
  proxy / foo:1234
  import secure
}

bar.example.com {
  proxy / bar:4321
  import secure
}

The login plugin seems quite versatile.