Support for client certificate fingerprint whitelist #62
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 usingRequireAnyClientCert
, so it invites a mistake of settingRequireAnyClientCert
and forgetting aboutclient_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 withclient_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 likeRequireAnyClientCert
, but would treat a nil set like an empty one (i.e. reject any certificate). This diverges a bit fromtls.ClientAuthType
enumeration list, but it's less error-prone this way.Currently based on top of #61, hence draft.