openvpn-users — OpenVPN users list

[Openvpn-users] HashCalc App

[Alireza F. <rad...@gm...>]

I recommend HashCalc for calculating Hash for Files or Strings

https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc

[Openvpn-users] HashCalc App

[Alireza F. <rad...@gm...>]

I recommend HashCalc for calculating Hash for Files or Strings

https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/ReactiveCircus/android-emulator-runner/commit/1dcd0090116d15e7c562f8db72807de5e036a4ed

[Openvpn-users] Security

[Alireza F. <rad...@gm...>]

4

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Jochen B. <Joc...@bi...>]

On 30.09.25 04:53, Leroy Tennison via Openvpn-users wrote:
> Third point, are you suggesting that we use something different in
> the new ca.crt to distinguish it from the old one and use
> 
> On Monday, September 29, 2025 at 02:49:32 AM CDT, Jochen Bern <joc...@bi...> wrote:
>> You might be able to change the roll-out process so that the new
>> serverCA file and new client certs with some marker (say,
>> OU=ImAlreadyDone) will be installed at the same time, then you could
>> recognize unprepared clients by the missing marker as they auth ... ?

No, I'm trying to suggest a mechanism that might allow you to see *on 
the server side* which clients still don't have the updated CA file, by 
having a mark in the *client* certs.

In the OpenVPN default config, the "identity" of a cert-authenticated 
client essentially is the cert's subject *CN*, but every (re)auth gets 
logged with the full *DN*:

> Sep  7 04:06:33 [...] VERIFY OK: depth=0, CN=Jochen Bern, OU=[...],
>      O=Binect GmbH, L=Weiterstadt, ST=Hessen, C=Deutschland,
>      emailAddress=Joc...@bi...

Now suppose that whenever a client gets the new CA certs file installed, 
you *also* replace the client cert with one where the DN contains an 
additional "OU=YupIAlreadyGotIt". (And if you have clients that need a 
new cert but can *not* receive the new CA certs file on the same 
occasion, they still get one *without* that extra marker.) Then you can 
tell *from the server log* which (active) clients still lack the config 
update.

(... I haven't been using EasyRSA for long enough that I can't give you 
instructions on *how* exactly to do all that, though. Matter of fact, 
with that regime, the same info *should* IMHO also be available from the 
CAs' index.txt files ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Leroy T. <ler...@ve...>]

Thanks for your reply, you mentioned some alternatives I wasn't aware of.  Our configuration pretty much follows the supplied client.conf and server.conf examples as well as easy-rsa so there's one ca file.  I didn't specify how I'd determine the ca.crt file so, for clarification, my plan was to use

    vpnconf=`ps -ef | grep openvpn | grep -o '\-\-config.*conf ' | cut -d' ' -f 2`

followed by

    cacrt=`grep ^ca $vpnconf | cut -d' ' -f2`


followed by (since our standard is to put the client ca.crt in /etc/openvpn and not use full-path for the file)

    expire=`openssl x509 -in /etc/openvpn/$cacrt -noout -enddate`

and use that.

Second, good point about an expired CRL but we don't use client side CRLs

Third point, are you suggesting that we use something different in the new ca.crt to distinguish it from the old one and use

openssl x509 -in </path/to/ca.crt> -noout -subject

to detect non-upgraded clients?

Finally, by design these clients are always connected so we don't face that issue.


On Monday, September 29, 2025 at 02:49:32 AM CDT, Jochen Bern <joc...@bi...> wrote: 

On 29.09.25 04:18, Leroy Tennison via Openvpn-users wrote:
> Other than connecting to the client, finding what ca.crt they
> use and running openssl x509 -in<client ca.crt> -noout -enddate?

a) Just to make sure: The *clients* need the cert of the CA issuing the 
*server* certs, because *that's* the cert they're checking with it.

b) Your OpenSSL command will output the data for the *first* cert found 
in the file. Files - or, for that matter, CApath directories - accepted 
by OpenVPN can contain *several* CA certs. (In the case of a PKI with 
intermediate CAs, they *should* have the entire chains from root to 
server-cert-issuing intermediate.)

c) I still remember the time when, while we evaluated a new platform, we 
found that OpenVPN would also refuse a CA with an expired *CRL*, so you 
might want to check that as well - *if* you're rolling out CRLs to the 
clients.

d) Having that said, I'm not aware of a method to doublecheck any of 
that on the *server* side ...


> My concern is accidentally overlooking a client.


You might be able to change the roll-out process so that the new 
serverCA file and new client certs with some marker (say, 
OU=ImAlreadyDone) will be installed at the same time, then you could 
recognize unprepared clients by the missing marker as they auth ... ?

(Still doesn't catch *dormant* clients, though ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

_______________________________________________
Openvpn-users mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Jochen B. <Joc...@bi...>]

On 29.09.25 04:18, Leroy Tennison via Openvpn-users wrote:
> Other than connecting to the client, finding what ca.crt they
> use and running openssl x509 -in<client ca.crt> -noout -enddate?

a) Just to make sure: The *clients* need the cert of the CA issuing the 
*server* certs, because *that's* the cert they're checking with it.

b) Your OpenSSL command will output the data for the *first* cert found 
in the file. Files - or, for that matter, CApath directories - accepted 
by OpenVPN can contain *several* CA certs. (In the case of a PKI with 
intermediate CAs, they *should* have the entire chains from root to 
server-cert-issuing intermediate.)

c) I still remember the time when, while we evaluated a new platform, we 
found that OpenVPN would also refuse a CA with an expired *CRL*, so you 
might want to check that as well - *if* you're rolling out CRLs to the 
clients.

d) Having that said, I'm not aware of a method to doublecheck any of 
that on the *server* side ...

> My concern is accidentally overlooking a client.

You might be able to change the roll-out process so that the new 
serverCA file and new client certs with some marker (say, 
OU=ImAlreadyDone) will be installed at the same time, then you could 
recognize unprepared clients by the missing marker as they auth ... ?

(Still doesn't catch *dormant* clients, though ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

[Openvpn-users] Any way to check client ca.crt expiration date

[Leroy T. <ler...@ve...>]

Other than connecting to the client, finding what ca.crt they use and running openssl x509 -in<client ca.crt> -noout -enddate?
The reason I'm asking is that we have a ca.crt which will be expiring in about a year.  I know how to update ca.crt without immediately having to update all clients and how to update all clients (including their own certificates which will expire some time after the ca.crt) and we will be doing that over time.  My concern is accidentally overlooking a client. Thanks for any and all help.

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/LSPosed/.github/tree/master/profile

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/AKP199/Spoon-Knife/actions/runs/18035755666/job/51322237718#step:2:19

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/AKP199/Spoon-Knife/actions/runs/18035755666/job/51322237718

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/pvorb/npm-stat.com/blob/develop/package-lock.json#L۲-L۳

Re: [Openvpn-users] OpenVPN 2.7_beta2 released

[Gert D. <ge...@gr...>]

Hi,

On Thu, Sep 25, 2025 at 05:42:01PM +0300, Yuriy Darnobyt wrote:
> Important bug fixes since 2.7_beta1:
> 
> * add proper input sanitation to DNS strings to prevent an attack coming 
> from a trusted-but-malicous OpenVPN server (CVE-2025-10680, affects
> unixoid systems with --dns-updown scripts and windows using the built-in
> powershell call)

Let me emphasize this.  If you followed my advice to "please go and test
2.7_beta1" and installed a --dns-updown script (for example by compiling
and then "make install"), and there is a risk that you connect to an
openvpn server that is not trustworthy -> please upgrade ASAP.

Also, do not use openvpn configs from untrusted sources with 2.7_beta1
under unixoid OSes.

If your OpenVPN server is fully trusted, and you know where the configs
are coming from, then there is no attack angle.

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                             ge...@gr...

[Openvpn-users] OpenVPN 2.7_beta2 released

[Yuriy D. <yur...@op...>]

The OpenVPN community project team is proud to release OpenVPN 2.7_beta2.
This is a second beta which includes important bugfixes.

Feature changes since 2.7_beta1:

* greatly improved event log handling for the Windows interactive service - this brings build system
changes and a new openvpnservmsg.dll

Important bug fixes since 2.7_beta1:

* add proper input sanitation to DNS strings to prevent an attack coming from a trusted-but-malicous
OpenVPN server (CVE-2025-10680, affects unixoid systems with --dns-updown scripts and windows
using the built-in powershell call)
* bugfixes when using multi-socket on windows (properly recognize that TCP server mode does not work
with DCO, properly handle TCP multi-socket server setups without DCO)
* bring back configuring of IPv4 broadcast addresses on Linux
* repair "--dhcp-option DNS" setting in combination with DHCP (TAP) or "--up" scripts
(Github: OpenVPN/openvpn#839, OpenVPN/openvpn#840)

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/master/Changes.rst>

Source code and Windows installers can be downloaded from our download page:

<https://openvpn.net/community-downloads/>

Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:

<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>

Kind regards,
Yuriy Darnobyt

[Openvpn-users] OpenVPN 2.6.15 released

[Frank L. <fr...@li...>]

The OpenVPN community project team is proud to release OpenVPN 2.6.15.

This is a bugfix release.

Bug fixes:

* On Windows, do not use "wmic.exe" any longer to set DNS search domain
  (discontinued by Microsoft), use "powershell" fragment instead.
* On Windows, logging to the windows event log has been improved
  (and logging of GetLastError() strings repaired).
  To make this work, a new "openvpnmsgserv.dll" library is now installed and
  registered.
* DNS domain names are now strictly validated with a positive-list of
  allowed characters (including UTF-8 high-bit-set bytes) before being handed
  to powershell.
* Apply more checks to incoming TLS handshake packets before creating new state
  - namely, verify message ID / acked ID for "valid range for an initial packet".
  This fixes a problem with clients that float very early but send control
  channel packet from the pre-float IP (Github: OpenVPN/openvpn#704, backported
  from 2.7_beta1).
* Backport handling of client float notifications on FreeBSD 14/STABLE DCO.
  (FreeBSD: #289303)
* Update GPL license text to latest version from FSF.
* On Linux, on interfaces where applicable, OpenVPN explicitly configures the
  broadcast address again. This was dropped for 2.6.0 "because computers are
  smart and can do it themselves", but the kernel netlink interface isn't, and
  will install "0.0.0.0". This does not normally matter, but for broadcast-based
  applications that get the address to use from "ifconfig", this change repairs
  functionality.

Windows MSI changes since 2.6.14-I004:

* Built against OpenSSL 3.5.3
* Included openvpn-gui updated to 11.56.0.0
  * Fix "Cannot open the System Tray Menu with Keyboard"
    (Github: OpenVPN/openvpn-gui#763)

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst>

(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:

<https://openvpn.net/community/>

Debian and Ubuntu packages are available in the official apt repositories:

<https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories>

On Red Hat derivatives we recommend using the Fedora Copr repository.

<https://copr.fedorainfracloud.org/coprs/g/OpenVPN/openvpn-release-2.6/>

Regards,
-- 
  Frank Lichtenheld

[Openvpn-users] OpenVPN 3 Linux v26 released

[David S. <daz...@eu...>]

OpenVPN 3 Linux v26 (Stable release)

The v26 release is a small bugfix and enhancement release.

Please notice the deprecation of openvpn3-autoload.

* Enhancement: Improve user feedback when a VPN profile is not valid
  Since the OpenVPN 3 Linux v22_dev release, the
  openvpn3-service-configmgr service has provided an API to validate
  VPN profiles it manages.  This has been used in the rest of the
  available tools to check if everything is in order before
  attempting to start a VPN session.

  When a configuration profile was lacking certain required options,
  it would fail this validation.  But the feedback to the user was
  not much helpful and the user would need to check the
  configuration profile manually.

  With the v26 release, the end user will be provided a list of
  required configuration options missing.


* Enhancement: Set route metric value when provided via VPN session
  Since the very beginning of OpenVPN 3 Linux, the route metric
  value has been ignored.  This has been improved in the v26 release
  and the metric values provided in the configuration profile or
  pushed from the VPN server will now be respected.
  

* FEATURE DEPRECATION: openvpn3-autoload

  The openvpn3-autoload feature was deprecated already in the
  v20 release.  This feature will be removed in a coming stable
  release.

  The replacement is the openvpn3-session@.service systemd unit.
  Please see the openvpn3-systemd man page [1] for more details.

  If you depend on openvpn3-autoload today, please migrate ASAP
  to the systemd approach.

  [1] <https://codeberg.org/OpenVPN/openvpn3-linux/src/branch/master/docs/man/openvpn3-systemd.8.rst>


* Bugfix: Proper parsing of <connection/> tags in OpenVPN configs
  The internal VPN profile configuration parser did not properly
  parse configuration files containing <connection>...</connection>
  tags to configure a remote server.  This has been fixed and both
  the openvpn3-service-configmgr and the openvpn3 Python module has
  been updated to support this feature.


* Bugfix: Proper parsing of semicolon (;) as comment line
  The openvpn3 Python module did not properly parse configuration
  files which used semicolon (;) as a comment separator.  This
  has been improved and both hash (#) and semicolon can now be
  used for comments in configuration profiles.


* Bugfix: openvpn3-service-netcfg may stop on route setup errors
  In some corner cases, when the openvpn3-service-client (VPN
  client) process called the Network Configuration service
  (openvpn3-service-netcfg) to establish the VPN network
  interface, the Network Configuration service could crash
  and not recover, resulting in the VPN session not being able
  to be established.  This has been improved and this error
  situation is now handled and logged properly.


* Bugfix: Background D-Bus calls to systemd-resolved fails
  On some systems the D-Bus communication between the
  openvpn3-service-netcfg (NetCfg) process and systemd-resolved
  could be too slow, resulting in the NetCfg process retrying
  the D-Bus call.  Due to an incorrect retry logic, the parameters
  systemd-resolved would need had been released from memory and
  was no longer accessible.  This has been resolved and the
  retry logic now behaves as expected.


* Bugfix: VPN session restart triggers assertion warning in logs
  When an on-going VPN session is attempted restarted, for example
  via the openvpn3 session-manage command, the NetCfg service
  would log an assertion warning in the system logs.  This has
  been resolved and VPN session restarts will now work as expected.


* Bugfix: OpenVPN 3 AWS-VPC fails changing IPv6 routes
  Due to a typo in the parameter name used for changing IPv6
  routes in the AWS VPC service, setting IPv6 routes would result
  in an error.  This has been resolved in the OpenVPN 3 Core
  version 3.11.5 release, which OpenVPN 3 Linux v26 has
  upgraded to.


* OpenVPN 3 Core Library update
  The OpenVPN 3 Core Library has been updated to version 3.11.5,
  which is contains the fix for the AWS VPC route fix.  It also
  enables building against Linux 6.16 kernel headers.


Known issues:

  - The openvpn3-service-netcfg service does not differentiate between
    --dns server X resolve-domains and --dns search-domains when using
    the --resolv-conf mode, which is not as this feature is
    intended to work.  This was discovered in the v24 release and is
    on the schedule to be fixed in the next releases.  When this gets
    fixed, only --dns search-domains will be considered as search
    domains and --dns server X resolve-domains will enable split-DNS
    when using --systemd-resolved and otherwise ignored when using
    --resolv-conf with openvpn3-service-netcfg.


Supported Linux distributions
-----------------------------

  - Debian: 12, 13[*]
  - Fedora: 41, 42
  - Red Hat Enterprise Linux 8, 9, 10[*]
  - Ubuntu: 22.04, 24.04, 25.05

Installation and getting started instructions can be found here:

  <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux>

There are in addition other Linux distributions now providing
OpenVPN 3 Linux packages.  These distributions are primarily
supported by their respective distribution communities.  We will
naturally review and apply fixes deemed needed for any
distributions as they occur.

NOTE: Red Hat Enterprise Linux 10
  The Fedora Copr repository definition for RHEL+EPEL-10 *may*
  use a wrong URL.  After doing the 'dnf copr enable' step
  on RHEL-10, please ensure the URL contains 'rhel+epel' and
  not just 'epel'.  This is expected to automatically improve
  with time.

  The stable repositories provided by OpenVPN Inc should not
  have this issue.

NOTE: Debian 13 (Trixie)
  Debian 13 is added to the list of supported distribution versions.
  With Debian 13 there is now also an upstream distribution package
  as well, openvpn3-client, as well as the GDBus++ library.  The
  version in the distribution repository is at OpenVPN 3 Linux v24.1.
  This cannot be upgraded to a newer base line, due to Debian
  packaging rules.  The package maintainer will apply bug and security
  fixes as needed.

  If you want to use a newer OpenVPN 3 Linux on Debian 13, you will
  need to install the third-party repository provided by OpenVPN Inc.
  This is the same procedure as in Debian 12 and earlier.  With the
  v26 release, the package has been renamed to 'openvpn3-client' and
  an upgrade path from the openvpn3 package has been added.  After
  upgrading to v26, the openvpn3 transitional package can be removed
  via 'apt autoremove'.


--
kind regards,

David Sommerseth
OpenVPN Inc


---- Source tarballs ---------------------------------------------------
* OpenVPN 3 Linux v26

  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-26.tar.xz>
  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-26.tar.xz.asc>

* GDBus++ v3

  <https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz>
  <https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz.asc>

---- SHA256 Checksums --------------------------------------------------

80e35615ae913fbdbdda53495b27934a3bbb21d8b15c49a624d4992c15e196e1  openvpn3-linux-26.tar.xz
474ba43ae9a6f4e8e5488750ed779bf57e7e2efe9bc05d196f65adb83f830eb4  openvpn3-linux-26.tar.xz.asc
c7a053a13c4eb5811a542b747d5fcdb3a8e58a4a42c7237cc5e2e2ca72e0c94e  gdbuspp-3.tar.xz
b9cf732d7a347f324d6a5532dc48f80c2815dbf6704c169b4ee97a411506a99b  gdbuspp-3.tar.xz.asc

---- git references ----------------------------------------------------

git repositories:

 - OpenVPN 3 Linux
   <https://codeberg.org/OpenVPN/openvpn3-linux> (PRIMARY)
   <https://gitlab.com/openvpn/openvpn3-linux>   (code-only mirror)
   <https://github.com/OpenVPN/openvpn3-linux>   (code-only mirror)

   git tag: v26
   git commit: 42ecc42a782025f8774e907a8c1966524424bcee

 - GDBus++
   <https://codeberg.org/OpenVPN/gdbuspp/>       (PRIMARY)
   <https://gitlab.com/openvpn/gdbuspp/>         (code-only mirror)
   <https://github.com/openvpn/gdbuspp/>         (code-only mirror)

   git tag: v3
   git commit: 96f7fb688ed2dea3f192c63c5fe283dbe4900f16

---- Changes from v25 to v26 ---------------------------------------

David Sommerseth (30):
      build: Add fmt subproject
      configmgr: Add details when profile validation fails
      ovpn3cli/config-import: Show warning if imported profile is invalid
      netcfg/resolved: Ensure glib2 params are available on retries
      common: Refactor and clean-up core-extensions.hpp
      common/core-extensions: Move helper functions into OptionListJSON class
      tests: Parse Access Server meta options in config-export-json-test
      common: Properly parse <connection/> blocks
      netcfg: Catch Core library exceptions in method_establish()
      configmgr: Let <connection/> tags be equivalent to --remote when validating the profile
      python: Deprecate openvpn3.ConfigParser.SanityCheck()
      python/openvpn2: Make Configuration.Validate() errors more user friendly
      python/openvpn2: Add IMPORT_ONLY debug more
      python: Implement <connection/> tag support in ConfigParser
      netcfg: Clarify IP address 'prefix' usage
      netcfg: Split up the NetCfgProxy::Network object construction
      netcfg: Small clean-up/codestyle fixup for IPAddr, Network and VPNAddress classes
      netcfg: Add support for route metric when assing VPN routes
      netcfg/proxy: Add service version check for D-Bus API compatibility
      python: Semicolon is not accepted by openvpn3.ConfigParser
      common: Minor cleanups in cmdargparser code
      netcfg/resolved: Fix g_variant_ref assertion warning on session restarts
      core: Update to OpenVPN 3 Core Library v3.11.4
      docs: Minor updates to the coding style guide
      Code style cleanup
      git: Update .git-blame-ignore-revs ignoring last code-style changes
      Quick spellcheck fixes all over project
      configmgr: Fix auth-user-pass handling regression
      netcfg: Make logged metric details more user friendly
      core: Update to OpenVPN 3 Core Library v3.11.5

--------------------------------------------------------------------

[Openvpn-users] Fwd:

[Alireza F. <rad...@gm...>]

---------- Forwarded message ---------
فرستنده: Alireza Farid <rad...@gm...>
‪Date: سه‌شنبه ۲۳ سپتامبر ۲۰۲۵، ۰۰:۰۰‬
Subject:
To: Alireza Farid <rad...@gm...>


http://46.229.253.146/

Re: [Openvpn-users] OpenVPN and non-rsa encryption

[tincantech <tin...@pr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

to use easyrsa with edwards curve, the simplest way is to copy pki/vars.example to pki/vars and edit that vars file.
Enable `set_var EASYRSA_ALGO ed`. The default curve is then set to ed25519. You can also choose curve ed448.

You can make this change to a new or existing PKI.

You can also make the switch to edwards temporary by using options --use-algo=ed and --curve=ed25519 or ed448.

Regards
Richard (Easy-RSA development)


Sent with Proton Mail secure email.

On Tuesday, 16 September 2025 at 06:23, Leroy Tennison via Openvpn-users <ope...@li...> wrote:

> I have a customer asking about switching from rsa to ed25519 for openVPN.  I know about easy-rsa, is there an easy-ed25519 or, if we can take that approach, are we back to determining how to do it with openssl?
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJoyU2MCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnhxRoyaQtioPss6C5qVBzXxPyr14KYAD20++Y
9w0iRPkWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA9B0H/iZ5yFx/6Yl4vuLn
vxbQInU6Jdl9zl0NyfPbqTFoiOj7orB/aUTSU1ggytcHCAnIsdXBTgaov8Ys
tXaO0ZeRcmgcbNge1T2QTTBDGknl6djlc+PVaFpGK0u3tGPConD9V9X5lBoi
sZS0IYZi3gXTNJXEQMIog/4VzsKm4CCd4ayExvpBA60l3qvGRSjxzZSpfnG8
EZXUObJAVa/3HV2j5QQqfbOdUBRQqybBkFUH7mjPk+uWUO2JISS4gEUpA8yO
FfNMatrzneLxj3byUKRnNWaRPsdfLFxhjRTTFDxf/N1Ya3hw7M8zm3T2HMbc
rhldeXeS3kifkyaFt5d6FistmbI=
=FuQs
-----END PGP SIGNATURE-----

Re: [Openvpn-users] OpenVPN and non-rsa encryption

[Antonio Q. <a...@un...>]

On 16/09/2025 06:40, Leroy Tennison via Openvpn-users wrote:
> I have a customer asking about switching from rsa to ed25519 for openVPN.  I know about easy-rsa, is there an easy-ed25519 or, if we can take that approach, are we back to determining how to do it with openssl?

It's called easyrsa, but it can do ed* as well.

It's all about tuning the right params so that openssl is invoked 
accordingly when creating keys/certs.

To the easyrsa user this is mostly transparent as the PKI creation works 
the same way.

Regards,


-- 
Antonio Quartulli

[Openvpn-users] OpenVPN and non-rsa encryption

[Leroy T. <ler...@ve...>]

I have a customer asking about switching from rsa to ed25519 for openVPN.  I know about easy-rsa, is there an easy-ed25519 or, if we can take that approach, are we back to determining how to do it with openssl?

Re: [Openvpn-users] Request for feedback: Unbundling easy-rsa on Windows

[tincantech <tin...@pr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

There is one specific benefit to bundling Easy-RSA with the OpenVPN installer:

The OpenVPN installer is not blocked by modern browsers, which means that it
is still relatively easy for users to download and install Easy-RSA.

The Easy-RSA zip files from Github are regularly blocked.


Regards
Richard Bonhomme (Easy-RSA development)

Sent with Proton Mail secure email.



-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJoxXj7CZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jnocr8hQVqrFMeYb1dBdSn2ZnXWrjYJbisN60e
MHFk1OMWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAAqIYIAK73CrYhZQZDDTEu
rUZ0CCoflIzBPOwXSaDRQc9RaovKl5V58QNAB1yPVJSYNyfksaP6kyvOT1Je
ZPhF9sNqVCdDAsErMHza32J8JUIDQGqrYjcpxYb56seccBnzlWNR1EtWZW8f
mIa5UqWi09Qb9yI4hxZxeQBtcJOT4nd7WSTqEjGyvISQyJggdZhYvVPYwf5u
UhdZJlG6j4yT7qslhwYBxS4Liw4JqDbR4nB4ZxOjmf3dBenVWt964WYy8BA3
JPIEBeJukBPrRDzJaPlpQgP1N3eJ5vCwOlElF1OO+nsB0Fq4XUt4QMdYTc9p
Rr+QPGWvO4Zks+L5eZ/QPDzFlGE=
=CWLS
-----END PGP SIGNATURE-----

Re: [Openvpn-users] OpenVPN service account & Windows compute Certificate Store

[Gert D. <ge...@gr...>]

Hi,

On Thu, Sep 11, 2025 at 08:59:22PM -0400, Selva Nair wrote:
> NT SERVICE\OpenVPNService

Thanks.

I'll put a big fat note into Changes.rst for 2.7_beta2 (and thus 2.7.0).

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                             ge...@gr...