search

caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
57.25k stars 4k forks source link

run: adapting config using caddyfile: hostname appears in more than one automation policy, making certificate management ambiguous #4176

Closed zhanjw closed 3 years ago

zhanjw commented 3 years ago

seems to work fine on both v2.3, but the following error occurs on 2.4.0, 2.4.1

2021/05/24 17:16:40.465 INFO using provided configuration {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""} 2021/05/24 17:16:40 [WARNING] Unnecessary header_up ('X-Forwarded-Proto' field): the reverse proxy's default behavior is to pass headers to the upstream run: adapting config using caddyfile: hostname appears in more than one automation policy, making certificate management ambiguous: *.xxx.com

How to fix? Thanks.

{
    https_port 8443
    admin off
    servers :8080 {
        listener_wrappers {
            proxy_protocol
        }
        protocol {
            allow_h2c
        }
    }
}

:80 {
    redir https://{host}{uri} permanent
}

https://*.xxx.com:8443 https://xxx.com:8443 {
  tls xxx@gmail.com {
    ciphers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    alpn http/1.1 h2
    dns cloudflare xxx
  }
}

http://test.xxx.com:8080 {
  header {
      Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  }
  encode gzip
  reverse_proxy localhost:33001 {
    header_up Host {http.reverse_proxy.upstream.hostport}
    header_up X-Real-IP {http.request.remote}
    header_up X-Forwarded-For {http.request.remote}
    header_up X-Forwarded-Port {http.request.port}
    header_up X-Forwarded-Proto {http.request.scheme}
  }
}

http://xxx.com:8080 http://*.xxx.com:8080 {
  header {
      Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  }
  root * /var/www
  file_server
   log {
     output file         /var/log/caddy/access.log
     format single_field common_log
   }
  redir / /blog/
  encode gzip
  php_fastcgi localhost:9000
  handle_errors {
    rewrite * /error/HTTP{http.error.status_code}.html
    file_server
  }
}
mholt commented 3 years ago

Thanks for opening an issue! We'll look into this.

Is that your real config file? (You own xxx.com?) We'll need the full, unredacted config in order to help you. It's not immediately clear to me what is going on, so I'll need your help to understand it better.

Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.

This template will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1: I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

```
paste here
```

### 1b. Caddy version (run `caddy version` or paste commit SHA)

```
paste here
```

### 1c. Go version (if building Caddy from source; run `go version`)

```
paste here
```

## 2. Description

### 2a. What happens (briefly explain what is wrong)

### 2b. Why it's a bug (if it's not obvious)

### 2c. Log output

```
paste terminal output or logs here
```

### 2d. Workaround(s)

### 2e. Relevant links

## 3. Tutorial (minimal steps to reproduce the bug)

Instructions -- please heed otherwise we cannot help you (help us help you!)

  1. Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

  2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.

    • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
    • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
    • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

  3. Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

    • Start with an empty config. Add only the lines/parameters that are absolutely required to reproduce the bug.
    • Do not run Caddy inside containers.
    • Run Caddy manually in your terminal; do not use systemd or other init systems.
    • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
    • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
    • Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file: ``` { ... } ``` Open terminal and run Caddy: ``` $ caddy ... ``` Make an HTTP request: ``` $ curl ... ``` Notice that the result is ___ but it should be ___.
zhanjw commented 3 years ago

This is my real config, forgive me for not being able to give the unmodified version, which has my cloudflare account and other personal information. The basic situation is that port 443 is occupied by another program, which will send the request to port 8080. I need caddy's automatic deployment and certificate acquisition functions, so I specified port 8443, which is only used to obtain certificates. It should be noted that port 8080 cannot participate in the establishment of tls, this process will be completed in another program, only need to return to the plain text information

1. Environment

1a. Operating system and version

NAME="CentOS Linux" VERSION="7 (Core)" kernel 5.10.11-xanmod1

1b. Caddy version (run caddy version or paste commit SHA)

v2.4.0 h1:yHnnbawH2G3ZBP2mAJF4XBLnJanqhULLP/wu01Qi9Io=

1c. Go version (if building Caddy from source; run go version)

go version go1.15.5 linux/amd64

2. Description

2a. What happens (briefly explain what is wrong)

work fine on v2.3.0, but the following error occurs on 2.4.0, 2.4.1

2021/05/24 17:16:40.465 INFO using provided configuration {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""} 2021/05/24 17:16:40 [WARNING] Unnecessary header_up ('X-Forwarded-Proto' field): the reverse proxy's default behavior is to pass headers to the upstream run: adapting config using caddyfile: hostname appears in more than one automation policy, making certificate management ambiguous: *.xxx.com

2b. Why it's a bug (if it's not obvious)

work fine on previous version

2c. Log output

caddy.HomeDir=/root
caddy.AppDataDir=/root/.local/share/caddy
caddy.AppConfigDir=/root/.config/caddy
caddy.ConfigAutosavePath=/root/.config/caddy/autosave.json
caddy.Version=v2.4.0 h1:yHnnbawH2G3ZBP2mAJF4XBLnJanqhULLP/wu01Qi9Io=
runtime.GOOS=linux
runtime.GOARCH=amd64
runtime.Compiler=gc
runtime.NumCPU=1
runtime.GOMAXPROCS=1
runtime.Version=go1.16.4
os.Getwd=/etc/caddy

CLOUDFLARE_API_KEY=xxxxx
XDG_SESSION_ID=28
HOSTNAME=ip-xxx.ap-southeast-1.compute.internal
TERM=xterm-256color
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=120.229.14.115 47758 22
SSH_TTY=/dev/pts/3
USER=root
LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.axa=38;5;45:*.oga=38;5;45:*.spx=38;5;45:*.xspf=38;5;45:
MAIL=/var/spool/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
PWD=/etc/caddy
CLOUDFLARE_EMAIL=xxx@xxx.com
LANG=zh_CN.UTF-8
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=120.229.14.115 47758 172.26.9.64 22
LESSOPEN=||/usr/bin/lesspipe.sh %s
XDG_RUNTIME_DIR=/run/user/0
_=/usr/bin/caddy
OLDPWD=/etc
2021/05/24 21:10:01.078 INFO    using provided configuration    {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
2021/05/24 21:10:01 [WARNING] Unnecessary header_up ('X-Forwarded-Proto' field): the reverse proxy's default behavior is to pass headers to the upstream
run: adapting config using caddyfile: hostname appears in more than one automation policy, making certificate management ambiguous: *.xxx.com``

2d. Workaround(s)

use 2.3.0

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

amd64

sudo curl -o /usr/bin/caddy -L "https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com%2Fcaddy-dns%2Fcloudflare&p=github.com%2Fmastercactapus%2Fcaddy2-proxyprotocol&idempotency=41494179211350"

Suppose we only need to access the plain text http connection, and then another port is used to obtain the certificate. Build a similar configuration

{
    https_port 8443
    admin off
    servers :8080 {
        listener_wrappers {
            proxy_protocol
        }
        protocol {
            allow_h2c
        }
    }
}

:80 {
    redir https://{host}{uri} permanent
}

https://xxx.com:8443 {
  tls xxx@gmail.com
}

http://xxx.com:8080 {
  root * /var/www
  file_server
}

I was able to run this configuration normally in the previous version, but it couldn't run normally after the update.

I want to know if you have any suggestions for my configuration?

mholt commented 3 years ago

forgive me for not being able to give the unmodified version

We do require domain names at least, which are public information. For now I'll assume we're working with example.com but please follow the directions in the future. You don't have to post credentials, but domains are required.

I'm not 100% convinced I'm convinced that it's a regression. I think it's part of a valid bug fix. The problem is that you're telling Caddy to serve two sites with the same domain name but while managing their TLS differently. This isn't possible, since it can't manage the certificate for example.com with an email address of xxx@gmail.com and also without an email address at the same time.

I'd suggest either putting tls xxx@gmail.com in your other site config or removing it entirely and putting email xxx@gmail.com in your global options.

mholt commented 3 years ago

Upon closer inspection, this is fixed in 05656a60b3b089ce1735a1ebb02539cca9f68fb4.