You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(12) |
Apr
(45) |
May
(34) |
Jun
(50) |
Jul
(39) |
Aug
(39) |
Sep
(29) |
Oct
(28) |
Nov
(30) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(18) |
Feb
(20) |
Mar
(10) |
Apr
(19) |
May
(72) |
Jun
(42) |
Jul
(31) |
Aug
(153) |
Sep
(156) |
Oct
(233) |
Nov
(213) |
Dec
(137) |
| 2004 |
Jan
(255) |
Feb
(292) |
Mar
(449) |
Apr
(241) |
May
(412) |
Jun
(541) |
Jul
(532) |
Aug
(611) |
Sep
(689) |
Oct
(804) |
Nov
(676) |
Dec
(715) |
| 2005 |
Jan
(639) |
Feb
(695) |
Mar
(756) |
Apr
(562) |
May
(497) |
Jun
(424) |
Jul
(394) |
Aug
(427) |
Sep
(390) |
Oct
(418) |
Nov
(387) |
Dec
(494) |
| 2006 |
Jan
(503) |
Feb
(436) |
Mar
(563) |
Apr
(448) |
May
(400) |
Jun
(420) |
Jul
(240) |
Aug
(362) |
Sep
(292) |
Oct
(408) |
Nov
(318) |
Dec
(245) |
| 2007 |
Jan
(330) |
Feb
(241) |
Mar
(259) |
Apr
(216) |
May
(305) |
Jun
(277) |
Jul
(288) |
Aug
(269) |
Sep
(273) |
Oct
(248) |
Nov
(267) |
Dec
(265) |
| 2008 |
Jan
(312) |
Feb
(454) |
Mar
(358) |
Apr
(195) |
May
(352) |
Jun
(305) |
Jul
(233) |
Aug
(385) |
Sep
(441) |
Oct
(325) |
Nov
(301) |
Dec
(329) |
| 2009 |
Jan
(344) |
Feb
(263) |
Mar
(350) |
Apr
(262) |
May
(255) |
Jun
(161) |
Jul
(330) |
Aug
(281) |
Sep
(285) |
Oct
(230) |
Nov
(304) |
Dec
(284) |
| 2010 |
Jan
(353) |
Feb
(260) |
Mar
(357) |
Apr
(403) |
May
(335) |
Jun
(236) |
Jul
(199) |
Aug
(247) |
Sep
(212) |
Oct
(160) |
Nov
(118) |
Dec
(110) |
| 2011 |
Jan
(172) |
Feb
(105) |
Mar
(113) |
Apr
(120) |
May
(124) |
Jun
(88) |
Jul
(94) |
Aug
(63) |
Sep
(78) |
Oct
(42) |
Nov
(137) |
Dec
(90) |
| 2012 |
Jan
(75) |
Feb
(113) |
Mar
(90) |
Apr
(77) |
May
(68) |
Jun
(58) |
Jul
(67) |
Aug
(119) |
Sep
(56) |
Oct
(60) |
Nov
(72) |
Dec
(48) |
| 2013 |
Jan
(78) |
Feb
(93) |
Mar
(114) |
Apr
(79) |
May
(57) |
Jun
(56) |
Jul
(29) |
Aug
(84) |
Sep
(55) |
Oct
(75) |
Nov
(61) |
Dec
(40) |
| 2014 |
Jan
(42) |
Feb
(14) |
Mar
(48) |
Apr
(132) |
May
(96) |
Jun
(58) |
Jul
(90) |
Aug
(116) |
Sep
(88) |
Oct
(69) |
Nov
(97) |
Dec
(93) |
| 2015 |
Jan
(61) |
Feb
(38) |
Mar
(62) |
Apr
(63) |
May
(67) |
Jun
(124) |
Jul
(79) |
Aug
(101) |
Sep
(60) |
Oct
(109) |
Nov
(64) |
Dec
(135) |
| 2016 |
Jan
(107) |
Feb
(83) |
Mar
(90) |
Apr
(78) |
May
(125) |
Jun
(100) |
Jul
(52) |
Aug
(96) |
Sep
(23) |
Oct
(74) |
Nov
(85) |
Dec
(168) |
| 2017 |
Jan
(63) |
Feb
(75) |
Mar
(51) |
Apr
(87) |
May
(48) |
Jun
(135) |
Jul
(90) |
Aug
(72) |
Sep
(38) |
Oct
(54) |
Nov
(102) |
Dec
(42) |
| 2018 |
Jan
(25) |
Feb
(55) |
Mar
(1) |
Apr
(10) |
May
(31) |
Jun
(72) |
Jul
(61) |
Aug
(12) |
Sep
(30) |
Oct
(41) |
Nov
(33) |
Dec
(16) |
| 2019 |
Jan
(19) |
Feb
(26) |
Mar
(72) |
Apr
(32) |
May
(38) |
Jun
(26) |
Jul
(19) |
Aug
(12) |
Sep
(8) |
Oct
(19) |
Nov
(61) |
Dec
(26) |
| 2020 |
Jan
(18) |
Feb
(21) |
Mar
(26) |
Apr
(206) |
May
(59) |
Jun
(18) |
Jul
(64) |
Aug
(28) |
Sep
(22) |
Oct
(15) |
Nov
(22) |
Dec
(21) |
| 2021 |
Jan
(17) |
Feb
(46) |
Mar
(64) |
Apr
(84) |
May
(86) |
Jun
(84) |
Jul
(45) |
Aug
(12) |
Sep
(27) |
Oct
(38) |
Nov
(49) |
Dec
(42) |
| 2022 |
Jan
(37) |
Feb
(55) |
Mar
(35) |
Apr
(31) |
May
(27) |
Jun
(61) |
Jul
(15) |
Aug
(4) |
Sep
(71) |
Oct
(15) |
Nov
(14) |
Dec
(12) |
| 2023 |
Jan
(20) |
Feb
(86) |
Mar
(57) |
Apr
(3) |
May
(7) |
Jun
(28) |
Jul
(105) |
Aug
(189) |
Sep
(33) |
Oct
(63) |
Nov
(40) |
Dec
(71) |
| 2024 |
Jan
(174) |
Feb
(120) |
Mar
(5) |
Apr
(42) |
May
(39) |
Jun
(19) |
Jul
(17) |
Aug
(23) |
Sep
(16) |
Oct
(6) |
Nov
(14) |
Dec
(2) |
| 2025 |
Jan
(1) |
Feb
(11) |
Mar
(19) |
Apr
(6) |
May
(11) |
Jun
(12) |
Jul
(7) |
Aug
(25) |
Sep
(47) |
Oct
(20) |
Nov
|
Dec
|
|
From: Simon M. <sim...@in...> - 2025-10-21 09:43:38
|
Hi David, > On 20/10/2025 14:52, Simon Matter wrote: >> While we are at it: the 'nice' option doesn't work because it's not >> allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes >> it >> work on RHEL. Could this be integrated in the EPEL RPMs? >> > > Simon, could you post this patch as a git patch to the oepnvpn-devel > mailing list? > Sorry, I'm not a git user. Can you or someone else who works with git provide such a patch, please? Thanks, Simon |
|
From: David S. <daz...@eu...> - 2025-10-21 08:16:35
|
On 20/10/2025 14:52, Simon Matter wrote: > While we are at it: the 'nice' option doesn't work because it's not > allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it > work on RHEL. Could this be integrated in the EPEL RPMs? > Simon, could you post this patch as a git patch to the oepnvpn-devel mailing list? What you have proposed looks good to me. Due to how the openvpn binary works, there are few other alternatives when you try restricting privileges than to grant the CAP_SYS_NICE privilege. -- kind regards, David Sommerseth OpenVPN Inc |
|
From: Simon M. <sim...@in...> - 2025-10-20 12:52:36
|
Hi, > On 20/10/2025 14:03, David Sommerseth via Openvpn-users wrote: >> On 17/10/2025 11:26, Gert Doering wrote: >>> Hi, >>> >>> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote: >>>> Looks like "update-crypto-policies --set LEGACY" did the trick to make >>>> it >>>> work. Ar least this makes the errors go away in a test setup. I'll >>>> soon do >>>> it on a production system. >>> >>> Ah, Redhat... "why should we leave decisions to software when we can >>> annoy everbody with a global setting". >>> >>> (I'm not exactly sure how these crypto policies work, but they seem to >>> override the application's request to get "--tls-cert-profile >>> insecure") >>> >>> thanks for reporting back the solution ;-) >> >> For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch >> which is required [2]. >> >> [1] >> <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch> While we are at it: the 'nice' option doesn't work because it's not allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it work on RHEL. Could this be integrated in the EPEL RPMs? Thanks, Simon |
|
From: David S. <daz...@eu...> - 2025-10-20 12:11:11
|
On 20/10/2025 14:03, David Sommerseth via Openvpn-users wrote: > On 17/10/2025 11:26, Gert Doering wrote: >> Hi, >> >> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote: >>> Looks like "update-crypto-policies --set LEGACY" did the trick to make it >>> work. Ar least this makes the errors go away in a test setup. I'll soon do >>> it on a production system. >> >> Ah, Redhat... "why should we leave decisions to software when we can >> annoy everbody with a global setting". >> >> (I'm not exactly sure how these crypto policies work, but they seem to >> override the application's request to get "--tls-cert-profile insecure") >> >> thanks for reporting back the solution ;-) > > For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch > which is required [2]. > > [1] > <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch> > [2] > <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/> > > The goal here is to have a system-wide setting for enforcing a stricter > crypto settings. This has ties to requirements from enterprise > customers of RHEL, where there has been request to centrally manage > this. And that's happening by pushing out settings to files in > /etc/crypto-policies/, via whatever tools the enterprise prefer > (ansible, puppet, chef, etc). Since Fedora is the "development branch" > of RHEL, that's how those are related. > > These crypto policies covers everything across multiple SSL/TLS > libraries (openssl, nss, gnutls) as well as many security relevant > services and software stacks (krb5, java, libreswan, openssh, libssh). > > The OpenSSL settings for the DEFAULT profile is: > > # cat /usr/share/crypto-policies/DEFAULT/openssl.txt > @SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \ > :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL \ > :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 JFTR, the LEGACY profile for OpenSSL is: # cat /usr/share/crypto-policies/LEGACY/openssl.txt @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK \ :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL \ :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 The difference is the addition of `kRSA` in the LEGACY profile. -- kind regards, David Sommerseth OpenVPN Inc |
|
From: David S. <daz...@eu...> - 2025-10-20 12:03:42
|
On 17/10/2025 11:26, Gert Doering wrote: > Hi, > > On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote: >> Looks like "update-crypto-policies --set LEGACY" did the trick to make it >> work. Ar least this makes the errors go away in a test setup. I'll soon do >> it on a production system. > > Ah, Redhat... "why should we leave decisions to software when we can > annoy everbody with a global setting". > > (I'm not exactly sure how these crypto policies work, but they seem to > override the application's request to get "--tls-cert-profile insecure") > > thanks for reporting back the solution ;-) For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch which is required [2]. [1] <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch> [2] <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/> The goal here is to have a system-wide setting for enforcing a stricter crypto settings. This has ties to requirements from enterprise customers of RHEL, where there has been request to centrally manage this. And that's happening by pushing out settings to files in /etc/crypto-policies/, via whatever tools the enterprise prefer (ansible, puppet, chef, etc). Since Fedora is the "development branch" of RHEL, that's how those are related. These crypto policies covers everything across multiple SSL/TLS libraries (openssl, nss, gnutls) as well as many security relevant services and software stacks (krb5, java, libreswan, openssh, libssh). The OpenSSL settings for the DEFAULT profile is: # cat /usr/share/crypto-policies/DEFAULT/openssl.txt @SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \ :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL \ :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 -- kind regards, David Sommerseth OpenVPN Inc |
|
From: Gert D. <ge...@gr...> - 2025-10-17 09:27:07
|
Hi,
On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote:
> Looks like "update-crypto-policies --set LEGACY" did the trick to make it
> work. Ar least this makes the errors go away in a test setup. I'll soon do
> it on a production system.
Ah, Redhat... "why should we leave decisions to software when we can
annoy everbody with a global setting".
(I'm not exactly sure how these crypto policies work, but they seem to
override the application's request to get "--tls-cert-profile insecure")
thanks for reporting back the solution ;-)
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...
|
|
From: Simon M. <sim...@in...> - 2025-10-17 09:20:08
|
> Hi, > > On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote: >> I've tried both options but unfortunately they don't make a difference. >> >> Is there anything else I can try? > > "Look carefully at your certificates" - the error we get back from OpenSSL > is "certificate verification failed", which could be anything really. > > Maybe "openssl verify" can shed some light on it. > > (As far as I can see, it's the client that complains, so you need to > verify the server cert vs. the CA cert that is in the client config) Looks like "update-crypto-policies --set LEGACY" did the trick to make it work. Ar least this makes the errors go away in a test setup. I'll soon do it on a production system. Simon |
|
From: Alireza F. <rad...@gm...> - 2025-10-17 01:52:55
|
curl -X CONNECT 'https://8.8.8.8:853' -H 'Host: 8.8.8.8:853' --http1.1 |
|
From: Gert D. <ge...@gr...> - 2025-10-16 12:15:46
|
Hi,
On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote:
> I've tried both options but unfortunately they don't make a difference.
>
> Is there anything else I can try?
"Look carefully at your certificates" - the error we get back from OpenSSL
is "certificate verification failed", which could be anything really.
Maybe "openssl verify" can shed some light on it.
(As far as I can see, it's the client that complains, so you need to
verify the server cert vs. the CA cert that is in the client config)
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...
|
|
From: Simon M. <sim...@in...> - 2025-10-16 11:56:20
|
Hi Gert, > Hi, > > On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users > wrote: >> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7. >> The old systems do have openssl 1.x while the new systems on AlmaLinux >> 10 >> will have openssl 3.2.2. > > OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates > based on MD5 or SHA1 hash are refused by default. > > Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to > your config and see if that makes it work (this enables SHA1 and MD5 > support). > > The error message you see is not the "typical" one, normally it says > something like "MD too weak" in this case. But it might still help. > I've tried both options but unfortunately they don't make a difference. Is there anything else I can try? Simon |
|
From: Gert D. <ge...@gr...> - 2025-10-16 09:59:55
|
Hi,
On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users wrote:
> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
> The old systems do have openssl 1.x while the new systems on AlmaLinux 10
> will have openssl 3.2.2.
OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates
based on MD5 or SHA1 hash are refused by default.
Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to
your config and see if that makes it work (this enables SHA1 and MD5
support).
The error message you see is not the "typical" one, normally it says
something like "MD too weak" in this case. But it might still help.
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...
|
|
From: Simon M. <sim...@in...> - 2025-10-16 09:54:12
|
Hi, I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7. The old systems do have openssl 1.x while the new systems on AlmaLinux 10 will have openssl 3.2.2. Trying with a first updated client against the old server gives me the following error: Oct 16 09:48:13 gw-06 openvpn[55973]: TCP/UDP: Preserving recently used remote address: [AF_INET]XX.XX.XX.XX:1194 Oct 16 09:48:13 gw-06 openvpn[55973]: Socket Buffers: R=[212992->212992] S=[212992->212992] Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link local: (not bound) Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link remote: [AF_INET]XX.XX.XX.XX:1194 Oct 16 09:48:13 gw-06 openvpn[55973]: TLS: Initial packet from [AF_INET]XX.XX.XX.XX:1194, sid=4c8a20e6 cdc15528 Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY OK: depth=1, C=CH, ST=BL, L=Arisdorf, O=Invoca-Systems, CN=Invoca-Systems CA, ema...@XX... Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY ERROR: depth=0, error=certificate signature failure: C=CH, ST=BL, L=Arisdorf, O=Invoca-Systems, CN=server, ema...@XX..., serial=1 Oct 16 09:48:13 gw-06 openvpn[55973]: Sent fatal SSL alert: decrypt error Oct 16 09:48:13 gw-06 openvpn[55973]: OpenSSL: error:0A000086:SSL routines::certificate verify failed: Oct 16 09:48:13 gw-06 openvpn[55973]: TLS_ERROR: BIO read tls_read_plaintext error Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS object -> incoming plaintext read error Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS handshake failed Oct 16 09:48:13 gw-06 openvpn[55973]: SIGUSR1[soft,tls-error] received, process restarting Oct 16 09:48:13 gw-06 openvpn[55973]: Restart pause, 128 second(s) I also tried with an openvpn 2.4 build and got similar errors. Can it be that the new openssl version breaks compatibility with the old openvpn server? Unfortunately I can not update all systems at the same time so I'm stuck here. Any help is much appreciated! Simon |
|
From: Yuriy D. <yur...@op...> - 2025-10-13 20:09:44
|
The OpenVPN community project team is proud to release OpenVPN 2.7_beta3. This is a third beta which includes improvements and bug fixes. Feature changes since 2.7_beta2: * improvements on PUSH_UPDATE handling on the server side * improve "recursive routing checks", prepare the way for a policy-based setup where "packets to VPN server" could end up in the tunnel without interfering with OpenVPN operations * add support for "eoch" data format to DCO on Windows (needs dco-win driver 2.8.0+) * clean up and remove outdated stuff from COPYING Important bug fixes since 2.7_beta2: * bugfixes reconnect and PUSH_UPDATE handling on the client side (notably handling of ifconfig/ifconfig-ipv6/redirect-gateway ipv6 if the server is not always pushing the same address families) 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 |
|
From: Alireza F. <rad...@gm...> - 2025-10-03 11:50:22
|
I recommend HashCalc for calculating Hash for Files or Strings https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc |
|
From: Alireza F. <rad...@gm...> - 2025-10-03 09:43:06
|
I recommend HashCalc for calculating Hash for Files or Strings https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc |
|
From: Alireza F. <rad...@gm...> - 2025-10-03 08:39:24
|
https://github.com/ReactiveCircus/android-emulator-runner/commit/1dcd0090116d15e7c562f8db72807de5e036a4ed |
|
From: Alireza F. <rad...@gm...> - 2025-10-03 04:29:33
|
4 |
|
From: Alireza F. <rad...@gm...> - 2025-10-03 04:29:04
|
|
From: Alireza F. <rad...@gm...> - 2025-10-02 03:21:27
|
|
From: Alireza F. <rad...@gm...> - 2025-10-01 18:42:35
|
|
From: Jochen B. <Joc...@bi...> - 2025-09-30 11:08:47
|
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, > ema...@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 |
|
From: Leroy T. <ler...@ve...> - 2025-09-30 02:53:32
|
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 |
|
From: Jochen B. <Joc...@bi...> - 2025-09-29 07:48:03
|
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 |
|
From: Leroy T. <ler...@ve...> - 2025-09-29 02:48:54
|
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. |
|
From: Alireza F. <rad...@gm...> - 2025-09-27 18:15:45
|
https://github.com/LSPosed/.github/tree/master/profile |