x509-username-field: add "issuer" keyword to get X509_get_issuer_name(3) #848
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 allows for accepting clients based on their certificate authority:
tls-verify
orplugin
can do the equivalent, but require additional codeexecution and always incur overhead or may not be an option when running with
reduced privileges, e.g.
chroot
.Motivation:
ca
contains the root CA and the intermediate CA issuing client certificates.Under the same root CA, another intermediate CA exists, not intended for VPN.
The problem is that OpenVPN successfully validates all certificate chains, i.e.
with both intermediates, whilst one one of them should allow peers to connect.
AFAIU, this is expected OpenSSL behaviour, at least when OpenVPN peers send not
only their own, but also their issuer CA’s certificate via
cert
.Thus reusing the customisable username mechanism allows for limiting to certain
CAs, i.e. rejecting unwanted peers, as early as possible during handshake.
(
remote-cert-ku
might be a viable alternative, but requires the X509v3extension and respective key usage bits set up front; I have not tried that.)
Tested against