Caddy on_demand ask sending IP address not the domain name

Help
1

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

service caddy start

a. System environment:

Ubuntu 20.04.4 LTS

b. Command:

service caddy start

d. My complete Caddyfile or JSON config:

{
  admin off

  on_demand_tls {
      ask      http://localhost:2501/check
      interval 5m
      burst    1
  }
  
  auto_https off

  debug
}

:80 {
  log
  
  handle {
    redir https://{host}{uri}
  }
}


:443 { 
  
  tls {
    on_demand 
  }
  

  handle {
    reverse_proxy localhost:2501
  }

}

3. The problem I’m having:

  on_demand_tls {
      ask      http://localhost:2501/check
      interval 5m
      burst    1
  }

When i open the domain e.g. https://site.com caddy sends the IP address “/check?domain=172.31.40.160” it should send the domain name

4. Error messages and/or full log output:

2022/04/25 19:34:04.968 DEBUG tls.handshake no matching certificates and no custom selection logic {“identifier”: “172.31.40.160”}
2022/04/25 19:34:04.973 DEBUG http.stdlib http: TLS handshake error from 172.31.44.175:22832: certificate for hostname ‘172.31.40.160’ not allowed; non-2xx status code 401 returned from http://localhost:2501/check

5. What I already tried:

I tried to debug in everyway it’s not working. When I send the request directly to my golang app I can clearly get the hostname fine fmt.Println("The URL: ", c.Request.Host+c.Request.URL.Path) but when I send request using Caddy to my golang app it sends the IP address not the domain name

6. Links to relevant resources:

2

That doesn’t sound right, can you show us evidence of that? Paste a curl-v command (and its output) like the instructions recommend, please. :slight_smile: Only very old clients these days don’t send SNI with domain names.

3

I am not sure how to CURL and show the evidence ?
This is the actual domain https://a3.jeoga.com/

FYI: I am using AWS Elastic Load Balancer In Between

4

Are you using ELB in TCP mode? If not, you should. ELB shouldn’t be terminating TLS.

Are you sure the clients making requests with IP addresses are legitimate? If you’re seeing some requests with IP addresses and others with domains, then it’s likely because you’re getting hit by bots crawling the internet. You can safely ignore those.

1 Like
5

Looks like this site is serving a certificate for producttutor.com, not its own domain. Are you sure you have DNS properly configured to point to the right server?

$ curl -v https://a3.jeoga.com/
*   Trying 54.156.251.8:443...
* Connected to a3.jeoga.com (54.156.251.8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=producttutor.com
*  start date: Apr 25 00:00:00 2022 GMT
*  expire date: May 24 23:59:59 2023 GMT
*  subjectAltName does not match a3.jeoga.com
* SSL: no alternative certificate subject name matches target host name 'a3.jeoga.com'
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'a3.jeoga.com'
1 Like
6

@francislavoie

  1. It’s totally a new server setup so there is no bots or crawling issue
  2. I am using ELB in HTTP Model let me try setup Network Load Balancer in TCP Mode

Yes DNS is properly configured 100% it’s just a default certificate required by AWS without adding any Default Certificate we cannot create a load balancer.

7

Right, because HTTP ELB will terminate TLS. You can’t use HTTP mode if you want Caddy to manage TLS, you have to use TCP mode.

If you care about tracking the remote IP addresses, you’ll need to turn on proxy protocol as well, and build Caddy with GitHub - mastercactapus/caddy2-proxyprotocol

1 Like
8

@francislavoie Thank you very much without your help I could not solve this issue.

TCP worked like a charm.

I am so very grateful for your time.

Screenshot 2022-04-26 at 2.33.28 AM
Screenshot 2022-04-26 at 2.33.28 AM1154×702 67.8 KB

3 Likes
9

@francislavoie
I am getting one more weird error.

When I run using this command caddy run --config /etc/caddy/Caddyfile the site https://a4.jeoga.com/ loads fine over HTTPS without any issues

But when I run using service caddy start command I am getting ERR_SSL_PROTOCOL_ERROR

Apr 25 21:43:13 ip-172-31-40-160 caddy[22613]: 2022/04/25 21:43:13 [ERROR] While deleting old OCSP staples, unable to load staple file: open /mnt/pt/caddy/data/ocsp/a4.jeoga.com-5cb51643>
Apr 25 21:43:13 ip-172-31-40-160 caddy[22613]: 2022/04/25 21:43:13 [ERROR] Listing contents of certificates/acme-v02.api.letsencrypt.org-directory: open /mnt/pt/caddy/data/certificates/a>
Apr 25 21:43:13 ip-172-31-40-160 caddy[22613]: {"level":"info","ts":1650922993.3171828,"logger":"tls","msg":"finished cleaning storage units"}
10

Your logs are truncated. Find the right command to check your logs here:

When running as a service, the caddy user needs permission for the files. If you ran as a different user or as root with caddy run then the files will have been created with the wrong user.

Don’t mix running as a service and running directly.

1 Like
11

Thanks. It worked. I have corrected the permissions

1 Like
12

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