The Wayback Machine - https://web.archive.org/web/20201126135412/https://github.com/caddyserver/caddy/issues/3589
Skip to content

/ caddy

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

reverse-proxy CLI with internal TLS #3589

Open
p3lim opened this issue Jul 20, 2020 · 6 comments
Open

reverse-proxy CLI with internal TLS #3589

p3lim opened this issue Jul 20, 2020 · 6 comments
Labels
feature request good first issue

Comments

@p3lim
Copy link

@p3lim p3lim commented Jul 20, 2020

I really like being able to use caddy reverse-proxy for development purposes, and it would be incredibly useful if it could also serve over HTTPS without LE ACME (e.g. using the internal CA).

I'm suggesting something along the lines of caddy reverse-proxy --internal --from example.com:443 --to 192.168.0.100:8080, where Caddy would generate a certificate internally, like it would with this Caddyfile:

example.com:443 {
    tls internal
    reverse_proxy 192.168.0.100:8080
}
@mholt
Copy link
Member

@mholt mholt commented Jul 20, 2020

--internal seems a bit ambiguous, maybe --internal-certs or something instead?

Note that Caddy uses its own ("internal") certificates by default if the hostname is like localhost or foo.local` or an IP address, so... is this flag really that useful/necessary? Why not just use localhost or .local or IP address?
@p3lim
Copy link
Author

@p3lim p3lim commented Jul 20, 2020 •
edited

While using localhost or .local might work for something running on the same machine, but for something running on another system or has expectations, that is too limiting. As an example, bitwarden_rs requires HTTPS to work, even if you're just testing it, and if you're testing it in an existing infrastructure (e.g. any cloud or kubernetes setup) then you can't use domains local to the host it's running on.

As for the flag name, anything that works is fine.
@divbhasin
Copy link

@divbhasin divbhasin commented Sep 1, 2020

I can work on this. Since I'm still trying to find my way around the codebase, is there a Slack where I can ask questions if needed?
@mholt
Copy link
Member

@mholt mholt commented Sep 1, 2020

@divbhasin Yeah there is. Although I can probably just answer the question of where in the code base to look right here. :) This whole file is the reverse-proxy command, specifically its flags:

caddy/modules/caddyhttp/reverseproxy/command.go

Lines 57 to 63 in 24f3478

Flags: func() *flag.FlagSet {
fs := flag.NewFlagSet("reverse-proxy", flag.ExitOnError)
fs.String("from", "localhost", "Address on which to receive traffic")
fs.String("to", "", "Upstream address to which to to proxy traffic")
fs.Bool("change-host-header", false, "Set upstream Host header to address of upstream")
fs.Bool("insecure", false, "Disable TLS verification (WARNING: DISABLES SECURITY, WHY ARE YOU EVEN USING TLS?)")
return fs
@divbhasin
Copy link

@divbhasin divbhasin commented Sep 6, 2020 •
edited

@mholt So I have the flag added, but I don't know how to set up the internal certificate. I see that tls internal is handled according to the following snippets:

caddy/caddyconfig/httpcaddyfile/builtins.go

Lines 99 to 102 in 24f3478

case 1:
if firstLine[0] == "internal" {
internalIssuer = new(caddytls.InternalIssuer)
} else if !strings.Contains(firstLine[0], "@") {

caddy/caddyconfig/httpcaddyfile/builtins.go

Lines 390 to 395 in 24f3478

case internalIssuer != nil:
configVals = append(configVals, ConfigValue{
Class: "tls.cert_issuer",
Value: internalIssuer,
})

But, the function where those snippets come from returns an array of ConfigValue. Are there any "global" config vals that contain the cert_issuer which can be modified?
@mholt
Copy link
Member

@mholt mholt commented Sep 8, 2020

@divbhasin That's the Caddyfile adapter; the command line doesn't use the Caddyfile. If you were writing a Caddyfile directive that changed the certificate issuer for a site, then yes you would use that. But in this case you just need the JSON.

What I would do is make a config (using the Caddyfile, for example) that does what you want. Then run caddy adapt to see its JSON. Then make sure your flag produces the relevant part of the JSON for what you want. Does that make sense?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature request good first issue
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
@p3lim @mholt @francislavoie @divbhasin
You can’t perform that action at this time.