-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
httpcaddyfile: Add client certificate config to tls
#3335
Conversation
Signed-off-by: NWHirschfeld <Niclas@NWHirschfeld.de>
Could you add some tests (likely an adapt test, see the Could you also post an example Caddyfile and the adapted JSON output (using the Thanks for working on this! |
wow, you're fast! |
Here is the Caddyfile I used for testing and the caddy adapt run:
|
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
…ddyfile Signed-off-by: NWHirschfeld <Niclas@NWHirschfeld.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this is really useful! Just a couple suggestions to improve it.
tls { | ||
clients { | ||
mode request | ||
trusted_ca_certs MIIDSzCCAjOgAwIBAgIUfIRObjWNUA4jxQ/0x8BOCvE2Vw4wDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMTkwODI4MTYyNTU5WhcNMjkwODI1MTYyNTU5WjAWMRQwEgYDVQQDDAtFYXN5LVJTQSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK5m5elxhQfMp/3aVJ4JnpN9PUSz6LlP6LePAPFU7gqohVVFVtDkChJAG3FNkNQNlieVTja/bgH9IcC6oKbROwdY1h0MvNV8AHHigvl03WuJD8g2ReVFXXwsnrPmKXCFzQyMI6TYk3m2gYrXsZOU1GLnfMRC3KAMRgE2F45twOs9hqG169YJ6mM2eQjzjCHWI6S2/iUYvYxRkCOlYUbLsMD/AhgAf1plzg6LPqNxtdlwxZnA0ytgkmhK67HtzJu0+ovUCsMv0RwcMhsEo9T8nyFAGt9XLZ63X5WpBCTUApaAUhnG0XnerjmUWb6eUWw4zev54sEfY5F3x002iQaW6cECAwEAAaOBkDCBjTAdBgNVHQ4EFgQU4CBUbZsS2GaNIkGRz/cBsD5ivjswUQYDVR0jBEowSIAU4CBUbZsS2GaNIkGRz/cBsD5ivjuhGqQYMBYxFDASBgNVBAMMC0Vhc3ktUlNBIENBghR8hE5uNY1QDiPFD/THwE4K8TZXDjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAQEAKB3V4HIzoiO/Ch6WMj9bLJ2FGbpkMrcb/Eq01hT5zcfKD66lVS1MlK+cRL446Z2b2KDP1oFyVs+qmrmtdwrWgD+nfe2sBmmIHo9m9KygMkEOfG3MghGTEcS+0cTKEcoHYWYyOqQh6jnedXY8Cdm4GM1hAc9MiL3/sqV8YCVSLNnkoNysmr06/rZ0MCUZPGUtRmfd0heWhrfzAKw2HLgX+RAmpOE2MZqWcjvqKGyaRiaZks4nJkP6521aC2Lgp0HhCz1j8/uQ5ldoDszCnu/iro0NAsNtudTMD+YoLQxLqdleIh6CW+illc2VdXwj7mn6J04yns9jfE2jRjW/yTLFuQ== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you think people using a Caddyfile would be more likely to have the certs in a PEM file than in base64-encoded DER format?
Maybe we should expect filepaths instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point. The idea was to "just build an adapter" to the JSON config model, without making any security related changes in this point.
Do you think this should be implemented in a way, that the JSON structure also accepts filepaths or should the Caddyfile interpreter read the file?
For both solutions, should both formats, DER format, as well as filepath, be allowed in the same argument list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without making any security related changes in this point.
This isn't a "security-related" change; it's just changing how the input is read. Instead of decoding a huge base64 blob from a handwritten file, it'd be better to read a filename and then just load the PEM data from the file.
should the Caddyfile interpreter read the file?
Probably this one. The Caddyfile adapter can load and parse the file.
For both solutions, should both formats, DER format, as well as filepath, be allowed in the same argument list?
No, let's keep it simple. Just a filename to one or more PEM files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally think that using this piece of full text PEM in config is fine. After all, we already store hashed password, cloudflare API token, etc in encoded text and this "single-file-config" philosphy is pretty good for me. A single file is easy to config and move around.
One thing that might be useful to do is to implement a place holder expression to read from file and expand upon parsing, so the users can express their logic in the way the like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without making any security related changes in this point.
@nwhirschfeld might mean that with the file loading and admin api, an attacker may be able to exploit this functionality to read arbitrary files on the system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think to add the possibility to import a certificate file using the preamble file: and to support base64 encoded certificates in the same list is no problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just follow Caddy convention and have two subdirectives instead:
trusted_ca_cert ... # base64 PEM goes here, can be specified multiple times
trusted_ca_cert_file ... # path to PEM file goes here, can be specified multiple times
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to butt in but I found this while looking to add a feature request for specifying a binary (DER) or base64-DER file (ideally with many certificates) and place it in either a caddyfile or a list in the JSON config for both trusted_ca_cert
and trusted_leaf_cert
. I'm hoping this would be extended to trusted_leaf_cert_file
similar to trusted_ca_cert_file
in this same merge?
Please let me know if you'd like a separate issue opened for any part of the above!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@velosol This is a good point, we should double-check whether this is only for CAs or whether we should just trust any cert in the chain that matches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -59,6 +59,11 @@ func parseBind(h Helper) ([]ConfigValue, error) { | |||
// protocols <min> [<max>] | |||
// ciphers <cipher_suites...> | |||
// curves <curves...> | |||
// clients { | |||
// mode [request|require|verify_if_given|require_and_verify] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix the comment alignment here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no problem, but which style do you prefer? I currently use something like a.
aaa [aaa aaa aaa] {
aaaaaaa <aaa>
aaaaa <aaa...>
aaaa {
aaaaaa <aaaaa>
aaa <aaaa>
}
}
bbb [bbb bbb bbb] {
bbbbbbb <bbb>
bbbbb <bbb...>
bbbb {
bbbbbb <bbbbb>
bbb <bbbb>
}
}
ccc [ccc ccc ccc] {
ccccccc <ccc>
ccccc <ccc...>
cccc {
cccccc <ccccc>
ccc <cccc>
}
}
Signed-off-by: NWHirschfeld <Niclas@NWHirschfeld.de>
tls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally had a chance to look this over again! Thanks, I think we're getting close.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work and discussion about this, everyone! I've made some final adjustments. It's time to merge this in, I really want this to go out with the 2.1 betas.
Fixes #3334