Skip to content
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

Support for client certificate fingerprint whitelist #62

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

WGH-
Copy link
Contributor

@WGH- WGH- commented Aug 20, 2021

This is useful for simple setups that don't require full-blown CAs for mutual authentication.

An example of a program that support this type of client auth is Postfix (see permit_tls_clientcerts).

This introduces a footgun in a way: using client_fingerprints practially requires using RequireAnyClientCert, so it invites a mistake of setting RequireAnyClientCert and forgetting about client_fingerprints. Luckily, it's possible to discern empty list from a nil one (not set), but it still requires the user to carefully replace multiline YAML list with client_fingerprints: [] if he wants to delete all certificates for some reason. Maybe that's not really a problem, but I still want to mention it.

Alternatively, we might introduce a new custom client_auth_type (say, FingerprintWhitelist) that would behave like RequireAnyClientCert, but would treat a nil set like an empty one (i.e. reject any certificate). This diverges a bit from tls.ClientAuthType enumeration list, but it's less error-prone this way.

Currently based on top of #61, hence draft.

client_ca_file is used to validate client certificate. However,
in tests, client never present any.

Signed-off-by: WGH <wgh@torlan.ru>
Add tests cases when the client actually sends a certificate, and check
how the server responds to it.

The client certificates were generated with this command:

    openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout client2_selfsigned.key -out client2_selfsigned.pem -nodes -subj '/CN=test2' -days 36500 -addext "extendedKeyUsage = clientAuth"

Signed-off-by: WGH <wgh@torlan.ru>
This is useful for simple setups that don't require full-blown
CAs for mutual authentication.

Signed-off-by: WGH <wgh@torlan.ru>
@roidelapluie
Copy link
Member

Wouldn't putting client cert as CA work instead? This looks uncommon.

@WGH-
Copy link
Contributor Author

WGH- commented Dec 26, 2021

Wouldn't putting client cert as CA work instead? This looks uncommon.

I think not, because it might lack the flag allowing it to be a CA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants