Now working when using tls client certificate auth

[markhuang1212]

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

using forwardproxy toghther with caddy's built-in TLS client certificate auth. the same configuration works fine without that clients config/cert.pem line. The exact same configuration works fine when not using proxy (i.e., just website hosting)

3. What is your entire Caddyfile?

https://www.mywebsite.com

log server.log
gzip
root host    

tls /etc/letsencrypt/live/www.mywebsite.com/fullchain.pem /etc/letsencrypt/live/www.mywebsite.com/privkey.pem {
    clients config/cert.pem
}

forwardproxy

4. How is your client configured?

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

just run it in the bash

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

The proxy working. Client certificate and https proxy works fine when I use the software I wrote using nodejs with chrome, meaning chrome supports such configuration. so the problem is on the server side.

8. What did you see instead (give full error messages and/or log)?

chrome gives me ERR_PROXY_CONNECTION_FAILED.

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. generate a tls key-cert pair, transform these into a .p12 file
2. using the same caddy configuation, add some static files to host folder and the certificate generated at step 1 to the config folder
3. add the .p12 file to chrome (OS dependent)
4. you should be able to access the page, but there will be error when using it as proxy

NOTE: in practice I don't use chrome directly with the proxy, but that doesn't matter since the error occur anyway.

[markhuang1212]

One more thing, when i use the nodejs client that i write instead of chrome, the tls connection can be established, its just that nothing will happen after that.

[sorz]

Log from my caddy server:

[ERROR] https://caddy.example.com - strict host matching: SNI (caddy.example.com) and HTTP Host (destination.example.com) values differ

[mholt]

By default, Caddy doesn't allow domain fronting when using client auth because of the obvious problem: clients could send a ServerName with the TLS handshake for an unprotected domain, then make HTTP requests with a Host header of a protected domain on that connection, thus bypassing authentication.

Caddy 2 allows you to disable this protection. Caddy 1 might too but I can't remember how without looking. 😅

[danlsgiga]

@mholt, I was looking for a way to disable StrictHostMatching. My scenario is I'm using Caddy as a sidecar for my applications to do mTLS. The caddy receiving the TLS client auth has only 1 TLS listener and host being served, so the concerns about the SNI + Host header matching do not apply. Is there a way for me to disable StrictHostMatching? Browsing through the code I couldn't find it.

Note: Caddy v1.0.4

[mholt]

Hmm, there's not in v1 I don't think, but we can do this pretty easily in v2!

[danlsgiga]

Gotcha... unfortunately v2 is still a no go for us since we rely entirely on DNS SRV for upstream discovery. Hence why I'm having the StrictHostMatching issue on v1 😄 . I have my upstream set as srv+https://myapp.service.consul and, obviously, that is not the same hostname that is in the Host header.

[mholt]

@danlsgiga We can change that, would your company be open to sponsoring that feature's development? I won't be working on v1 much anymore.