Skip to content

Conversation

@giga1699
Copy link
Contributor

@giga1699 giga1699 commented Jul 24, 2025

Change summary

Adds feature to enable certificate based authentication for OpenConnect

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes)
  • Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
  • Other (please describe):

Related Task(s)

https://vyos.dev/T7635

Related PR(s)

vyos/vyos-documentation#1662

How to test / Smoketest result

configure
run generate pki ca install catest
commit
run generate pki certificate sign catest install certtest
commit
set vpn openconnect authentication mode certificate user-identifier-field cn
set vpn openconnect network-settings client-ip-settings subnet 192.168.1.0/24
set vpn openconnect ssl ca-certificate catest
set vpn openconnect ssl certificate certtest
commit
exit

Check ocserv.conf for auth = "certificate" and cert-user-oid = 2.5.4.3

sudo cat /var/run/ocserv/ocserv.conf

Checklist:

  • I have read the CONTRIBUTING document
  • I have linked this PR to one or more Phabricator Task(s)
  • I have run the components SMOKETESTS if applicable
  • My commit headlines contain a valid Task id
  • My change requires a change to the documentation
  • I have updated the documentation accordingly

@github-actions
Copy link

github-actions bot commented Jul 24, 2025

👍
No issues in PR Title / Commit Title

@giga1699
Copy link
Contributor Author

I believe this would be backwards compatible to Sagitta if you'd like to backport it.

@sever-sever sever-sever requested a review from Copilot July 27, 2025 15:38
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR implements certificate-based authentication for OpenConnect VPN by adding support for client certificate validation. The implementation allows users to configure certificate authentication using Common Name (CN) or UID fields from client certificates.

  • Adds certificate authentication mode with support for CN and UID certificate fields
  • Updates authentication mode validation to handle the new certificate option
  • Requires CA certificate configuration when using certificate authentication

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
src/conf_mode/vpn_openconnect.py Adds certificate authentication validation logic and mutual exclusion checks
interface-definitions/vpn_openconnect.xml.in Defines the new certificate authentication configuration option
data/templates/ocserv/ocserv_config.j2 Updates the ocserv configuration template to output certificate authentication settings

@giga1699 giga1699 force-pushed the T7635 branch 3 times, most recently from ae471d3 to 96d74db Compare July 27, 2025 16:50
@giga1699
Copy link
Contributor Author

Updates made based off Copilot review feedback.

<valueless/>
</properties>
</leafNode>
<leafNode name="certificate">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@giga1699 I admit I misunderstood what the option actually does when I first reviewed the PR. I now understand that option is used to tell OCServ what certificate field to use as the user identifier. Please disregard my earlier comments.

Based on that, I think we can improve this CLI and make it more obvious what the option means.

For example, authentication mode certificate user-identifier-field <cn|uid|x.x.xx.xxx>.

My reasoning is:

  1. There's also cert-group-oid option to tell OCServ what field to use for the user group. If we put <cn|uid|...>, we cannot easily extend the CLI to support that in the future.
  2. I'm sure I'm not the only one who would have assumed that a bare cn option was supposed to have a particular CN as its argument, while user-identifier-field cn is obvious — that should be more obvious to people without a lot of experience with OCServ.

I'm open to proposals about the option name, not saying user-identifier-field is necessarily the best one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no objection with the name user-identifier-field

@dmbaturin
Copy link
Member

@giga1699 If you don't have the time to work on the PR, we are happy to take over and make the node name change ourselves. Please let us know if you want to do it yourself, it's fine if not.

@giga1699
Copy link
Contributor Author

giga1699 commented Dec 5, 2025

Apologies for the delay. Working on it today.

@github-actions
Copy link

github-actions bot commented Dec 5, 2025

CI integration ❌ failed!

Details

CI logs

  • CLI Smoketests (no interfaces) ❌ failed
  • CLI Smoketests VPP ❌ failed
  • CLI Smoketests (interfaces only) ❌ failed
  • Config tests ❌ failed
  • Config tests VPP ❌ failed
  • RAID1 tests ❌ failed
  • TPM tests ❌ failed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants