openvpn
openvpn copied to clipboard
OpenVPN
Support subject alternative names for --verify-x509-name CN checks
When using "--verify-x509-name [hostname] name" hostname will now be accepted also when matched against one of the X509v3 Subject Alternative Name IP or DNS entries (instead of just Subject's CN).
This would introduce different behaviour than OpenVPN 2.x and to previous version. I am not sure that is a good thing.
Hi,
On Sun, Jan 19, 2020 at 03:00:22PM -0800, Arne Schwabe wrote:
This would introduce different behaviour than OpenVPN 2.x and to previous version. I am not sure that is a good thing.
We could have a different "type" for "CN and SAN match"
--verify-x509-name myserver.com subject-alt-name
which would just add functionality, not change existing checks.
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
@schwabe : how different behavior here is a bad thing though? Please note that this is not a breaking change, all currently accepted certificates will continue to be accepted, it simply enables new class of certificates of being accepted as well. This change brings identity verification closer to how browsers are currently doing it and more in line with rfc2818.
From https://tools.ietf.org/html/rfc2818#section-3.1:
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
Browsers actually have moved away from using CN at all for identity verification (see https://www.chromestatus.com/feature/4981025180483584) but this would indeed be a potentially breaking change when introduced here.
It is not a breaking change but in the past we were very careful not the change the behaviour of options so that one config either works in all version of openvpn that support those options or none.
@mateusz-markowicz we are not verifying domain names, we are verifying CNs. Also a lot of certificates have domain names, I have seen a lot of certificates that have different.
If we really implement RFC2818 that would also mean that we IGNORE the CN if subjAltNames are present.
@schwabe : Sure, I'll prepare the change as a separate option.
I wasn't fully following RFC2818 to avoid this potentially breaking change when CN is ignored. And yes, the fact that CN we verify can actually be anything makes it a bit difficult to make this into a really clean solution (this seems why CN was actually deprecated for browsers). I guess in practice this new option will (and should) be used with domain names, but in fact nothing prevents it being used with other types of identifiers (basically it's a string that'd be checked against CN and SAN DNS/IPs).
I'd go with rfc2818-like solution allowing CN to be checked only if SAN extension is not present in the cert (as browsers did previously). I wouldn't go the current browser's way of completely ignoring CN, as it might make sense for some clients to support 2 types of certificates (those having SAN and those with only CN) in single configuration. What do you think?
Change is now prepared as a separate option, can you guys take a look?
Hi,
On Mon, Feb 10, 2020 at 08:48:18AM -0800, Samuele Kaplun wrote:
Hi! What is the next step to have this merged officially?
Send to list. PRs are only for initial discussion, but patches will only ever merged if sent to the openvpn-devel list for public review and ACK.
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
The resulting (rebased) patch was sent to the mailing list for proper review. Closing this PR. Thanks!
