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

OpenVPN rejects certificates whose CN starts with specified CN prefix #1923

Open
Facsimiler opened this issue Nov 30, 2019 · 0 comments
Labels

Comments

@Facsimiler
Copy link

@Facsimiler Facsimiler commented Nov 30, 2019

Describe the bug
Under VPN/Servers/Configuration, there's a property Client authorization by common name, which states:

If disabled, any client with a certificate generated by Zentyal will be able to connect. If enabled, only certificates whose common name begins with the selected value will be able to connect.

If this field is set to disabled, then OpenVPN clients using a Zentyal-issued certificate are able to connect just fine.

However, if a certificate containing a common name (CN) prefix is specified, then OpenVPN clients using certificates with that prefix are rejected.

To Reproduce
Steps to reproduce the behavior:

  1. Ensure that the Logs, and VPN modules are installed, configured and enabled.
  2. Ensure logging for VPN is enabled.
  3. Go to Certification Authority/General and issue a new certificate with the common name SomeExamplePrefix.
  4. On the same screen, issue another certificate with the common name SomeExamplePrefixForSomeClient.
  5. Go to VPN\Servers and configure a single server, advertising the whole Zentyal sub-network. Under the server's Configuration, select the SomeExamplePrefix certificate under Client authorization by common name. (All other values should be set as required.)
  6. Download the client bundle, using SomeExamplePrefixForSomeClient as the client's certificate. (All other values should be set as required.)
  7. Install OpenVPN on a client, and use the downloaded client bundle to connect to the server, from a network other than the one Zentyal administers.
  8. Observe that a connection cannot be made and that Zentyal reports (in the VPN logs): Certificate common name not authorized. (Note: It might be that Zentyal is looking at the wrong attribute, since it identifies the remote certificate by its Country code, C=US, in my case.)
  9. Return to VPN/Servers/Configuration and change the Client authorization by common name certificate to disabled.
  10. Attempt a VPN connection on the client once more, noting that it succeeds and that Zentyal reports a successful connection with a remote certificate value of SomeExamplePrefixForSomeClient.

I've recently upgraded to 6.1 (from 4.0) and it used to work just fine.

Expected behavior
VPN connections using client certificates whose CN field begins with the CN field of the specified Client authorization by common name certificate (such certificates also being issued, and not revoked, by the Zentyal administered Certification Authority, CA) should be accepted; all other client certificates should be rejected.

Screenshots
n/a

Zentyal OS (please complete the following information):

  • Version: 6.1
  • Version of the module which has the bug: zentyal-openvpn 6.1
  • Modules installed: Network, Firewall, Antivirus, DNS, DHCP, Logs, NTP, VPN, Domain Controller and File Sharing, RADIUS.

Other OS (please complete the following information):

  • OS: Ubuntu server
  • Version: 18.04.3 LTS, 64-bit

Additional context
Can't think of anything relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.