Failed to get certificate

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

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.

@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

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?).

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.

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.

Thanks for answering my questions.

I think I will try the plugin you suggested.

I’ve update the caddy build to include the http.jwt plugin and I’ve updated my Caddyfile which looks like this. I’m doing something wrong as Caddy is failing to start, could you check my syntax please?

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

myusername.asuscomm.com {

Landing page config

Loginsrv

login {
login_path /login
logout_url myusername.asuscomm.com
redirect_check_referer false
cookie_domain myusername.asuscomm.com
htpasswd file=/etc/.htpasswd
jwt_expiry 12h
}
}

myusername.asuscomm.com {
proxy / username:password
import secure
}

myusername.asuscomm.com {

#sabnzbd

proxy /sabnzb 127.0.0.1:38081 {
transparent
}

#sonarr

proxy /sonarr 127.0.0.1:38082 {
transparent
}

#radarr

proxy /radarr 127.0.0.1:38083 {
transparent
}

#nzbhydra

proxy /nzbhydra2 127.0.0.1:38084/ {
transparent
header_upstream X-Forwarded-Host {host}
}
rewrite / {
regexp ^/nzbhydra2$
to /nzbhydra2/
}

What does Caddy say when it fails to start? Ninety-nine times out of a hundred, Caddy will tell you (usually in close to plain English) exactly what’s going wrong.

My guess is because you configure myusername.asuscomm.com twice. Can’t have that ambiguity, how would Caddy tell which definition to use?

Also, you seem to be proxying / to username:password, which I hope isn’t a real host… That won’t stop Caddy from starting, it’ll just confuse the $#!^ out of Caddy when you try to use the proxy.

One other thing - I noticed you wrote that you included http.jwt, but neglected to mention including http.login. The latter is also an optional extra plugin which needs to be explicitly added, in case you haven’t already.

I have the following plugins included in my Caddy build: https://caddyserver.com/download/windows/amd64?plugins=hook.service,http.jwt,http.login&license=&telemetry=off

My Caddyfile currently looks like this (which also errors as above):

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

myusername.asuscomm.com {

  login {
    login_path /login
    logout_url myusername.asuscomm.com
    redirect_check_referer false
    cookie_domain myusername.asuscomm.com
    htpasswd file=/etc/.htpasswd
    jwt_expiry 12h
  }

gzip
log logs\access.log
errors logs\errors.log

#sabnzbd
	
  proxy /sabnzb 127.0.0.1:38081 {          
  transparent
  import secure
  }

#sonarr
  
  proxy /sonarr 127.0.0.1:38082 {          
  transparent
  import secure
  }

#radarr

  proxy /radarr 127.0.0.1:38083 {          
  transparent
  import secure
  }

#nzbhydra

  proxy /nzbhydra2 127.0.0.1:38084/ {
  transparent
  import secure
  header_upstream X-Forwarded-Host {host}
  }
  rewrite / {
  regexp ^/nzbhydra2$ 
  to /nzbhydra2/
  }

Clearly it’s not going to work as I have some errors in the syntax which I’m not sure how to correct.

“path /” what do I specify? I don’t have a login page, I just want to be prompted for a username and password when attempting to access my apps.

“logout_url” again I don’t have anything to specify here, do I just specify the hostname?

“htpasswd file=/etc/.htpasswd” do I need to create a file called .htpasswd and store a password in here and save it in /etc/ ? current error when running Caddy is The system cannot find the path specified.

I’ve looked through the documentation but I’m finding it difficult on what I need to configure, so I am sorry if you’re shaking your head at me :slight_smile:

I’m only seeing one error above in the forum thread:

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.

Is this the error you’re getting with that Caddyfile?

Going off the docs:

By default every resource under path will be secured using JWT validation.

caddy-jwt/README.md at master · BTBurke/caddy-jwt · GitHub

Also check out the examples further down that page, they show a few different options for /path and further demonstrate how it works.

The docs for loginsrv explain this one:

-logout-url URL or path to redirect to after logout

loginsrv/README.md at master · qvest-digital/loginsrv · GitHub

If you don’t have anything to specify, don’t specify it. It’s an optional subdirective.

Only if you want to use .htpasswd as your login backend. loginsrv supports:

If you do want to use .htpasswd, go ahead and make one.


I should stress that I posted my very specific jwt / login setup, and that my configuration is NOT going to be copy+paste plug ‘n’ play in your environment. It was just an example, and you’re most likely better off removing that example from your Caddyfile and configuring it yourself from scratch, piece by piece, so you have a good understanding of the moving pieces and what’s going on.

Thanks man, I’ll carry on trying to get it right, I appreciate your time.

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