Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 24/04/17 08:58, Samuli Seppänen wrote: > On 23/04/2017 11:02, Steffan Karger wrote: >> >> On 22-04-17 20:24, debbie10t wrote: >>> >>> On 02/01/17 15:39, Steffan Karger wrote: On 02-01-17 16:24, SviMik wrote: > >> On 02-01-17 15:26, Gert Doering wrote: >>> On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez >>> Iniesta wrote: I just got this [1] bug report on OpenVPN 2.4 threating all certs as expired when upgrading from 2.3. I find this quite weird, but until I have some time to test it I thought asking here would be faster. >>> >>> From the bug report: >>> >>> Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: >>> depth=0, >> error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, >> emailAddress=my@email >>> >>> "what the log says" :-) >>> >>> 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had >>> some built-in checking which only looked at revocations, while >>> 2.4 leaves this to the crypto library, and they check all fields >>> more rigidly). >>> >>> Specifically, CRLs with an expired "next update" field are >>> flagged as "expired" by OpenSSL, while the built-in check in 2.3 >>> did not. >> >> This. I replied something similar on the debian bug tracker, but I >> have no clue what will happen with that mail. >> >>> Since this bit a few people already, I wonder how we could >>> communicate this better. >> >> I wonder about that too. Maybe some more verbose text on a wiki >> page? We could even detect this specific error and add a link to >> that page in the warning. >> > > Is there an option to disable this check? It would be extremely > useful to maintain (at least optional) backward compatibility with > already existing setups, which originally relied on 2.3 behaviour. > No, there is not. And I don't think there is an easy way to implement that either. But, the fix is just as easy as the workaround: just regenerate the CRL, with a more correct nextUpdate value. If you don't want your CRLs expire, just put that value far enough into the future. >>> >>> Following this up, something like: >>> https://community.openvpn.net/openvpn/wiki/SandBox >> >> Excellent text! Thanks. Let's give this a good spot on the wiki. >> >> -Steffan >> > > Perhaps a condensed version of that text should go to the --crl-verify > section on the man-page? > Please feel free to edit, improve, correct and use it as preferred. -- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 23/04/2017 11:02, Steffan Karger wrote: > > On 22-04-17 20:24, debbie10t wrote: >> >> On 02/01/17 15:39, Steffan Karger wrote: >>> On 02-01-17 16:24, SviMik wrote: > On 02-01-17 15:26, Gert Doering wrote: >> On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez >> Iniesta wrote: >>> I just got this [1] bug report on OpenVPN 2.4 threating all >>> certs as expired when upgrading from 2.3. I find this quite >>> weird, but until I have some time to test it I thought asking >>> here would be faster. >> >> From the bug report: >> >> Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: >> depth=0, > error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, > emailAddress=my@email >> >> "what the log says" :-) >> >> 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had >> some built-in checking which only looked at revocations, while >> 2.4 leaves this to the crypto library, and they check all fields >> more rigidly). >> >> Specifically, CRLs with an expired "next update" field are >> flagged as "expired" by OpenSSL, while the built-in check in 2.3 >> did not. > > This. I replied something similar on the debian bug tracker, but I > have no clue what will happen with that mail. > >> Since this bit a few people already, I wonder how we could >> communicate this better. > > I wonder about that too. Maybe some more verbose text on a wiki > page? We could even detect this specific error and add a link to > that page in the warning. > Is there an option to disable this check? It would be extremely useful to maintain (at least optional) backward compatibility with already existing setups, which originally relied on 2.3 behaviour. >>> >>> No, there is not. And I don't think there is an easy way to implement >>> that either. >>> >>> But, the fix is just as easy as the workaround: just regenerate the >>> CRL, with a more correct nextUpdate value. If you don't want your CRLs >>> expire, just put that value far enough into the future. >> >> Following this up, something like: >> https://community.openvpn.net/openvpn/wiki/SandBox > > Excellent text! Thanks. Let's give this a good spot on the wiki. > > -Steffan > Perhaps a condensed version of that text should go to the --crl-verify section on the man-page? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 22-04-17 20:24, debbie10t wrote: > > On 02/01/17 15:39, Steffan Karger wrote: >> On 02-01-17 16:24, SviMik wrote: >>> On 02-01-17 15:26, Gert Doering wrote: > On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez > Iniesta wrote: >> I just got this [1] bug report on OpenVPN 2.4 threating all >> certs as expired when upgrading from 2.3. I find this quite >> weird, but until I have some time to test it I thought asking >> here would be faster. > > From the bug report: > > Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: > depth=0, error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, emailAddress=my@email > > "what the log says" :-) > > 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had > some built-in checking which only looked at revocations, while > 2.4 leaves this to the crypto library, and they check all fields > more rigidly). > > Specifically, CRLs with an expired "next update" field are > flagged as "expired" by OpenSSL, while the built-in check in 2.3 > did not. This. I replied something similar on the debian bug tracker, but I have no clue what will happen with that mail. > Since this bit a few people already, I wonder how we could > communicate this better. I wonder about that too. Maybe some more verbose text on a wiki page? We could even detect this specific error and add a link to that page in the warning. >>> >>> Is there an option to disable this check? It would be extremely >>> useful to maintain (at least optional) backward compatibility with >>> already existing setups, which originally relied on 2.3 behaviour. >>> >> >> No, there is not. And I don't think there is an easy way to implement >> that either. >> >> But, the fix is just as easy as the workaround: just regenerate the >> CRL, with a more correct nextUpdate value. If you don't want your CRLs >> expire, just put that value far enough into the future. > > Following this up, something like: > https://community.openvpn.net/openvpn/wiki/SandBox Excellent text! Thanks. Let's give this a good spot on the wiki. -Steffan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 02/01/17 15:39, Steffan Karger wrote: > On 02-01-17 16:24, SviMik wrote: >> >>> On 02-01-17 15:26, Gert Doering wrote: On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: > I just got this [1] bug report on OpenVPN 2.4 threating all > certs as expired when upgrading from 2.3. I find this quite > weird, but until I have some time to test it I thought asking > here would be faster. From the bug report: Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, >>> error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, >>> emailAddress=my@email "what the log says" :-) 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some built-in checking which only looked at revocations, while 2.4 leaves this to the crypto library, and they check all fields more rigidly). Specifically, CRLs with an expired "next update" field are flagged as "expired" by OpenSSL, while the built-in check in 2.3 did not. >>> >>> This. I replied something similar on the debian bug tracker, but I >>> have no clue what will happen with that mail. >>> Since this bit a few people already, I wonder how we could communicate this better. >>> >>> I wonder about that too. Maybe some more verbose text on a wiki >>> page? We could even detect this specific error and add a link to >>> that page in the warning. >>> >> >> Is there an option to disable this check? It would be extremely >> useful to maintain (at least optional) backward compatibility with >> already existing setups, which originally relied on 2.3 behaviour. >> > > No, there is not. And I don't think there is an easy way to implement > that either. > > But, the fix is just as easy as the workaround: just regenerate the > CRL, with a more correct nextUpdate value. If you don't want your CRLs > expire, just put that value far enough into the future. Following this up, something like: https://community.openvpn.net/openvpn/wiki/SandBox -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 02-01-17 16:24, SviMik wrote: > >> On 02-01-17 15:26, Gert Doering wrote: >>> On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez >>> Iniesta wrote: I just got this [1] bug report on OpenVPN 2.4 threating all certs as expired when upgrading from 2.3. I find this quite weird, but until I have some time to test it I thought asking here would be faster. >>> >>> From the bug report: >>> >>> Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: >>> depth=0, >> error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, >> emailAddress=my@email >>> >>> "what the log says" :-) >>> >>> 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had >>> some built-in checking which only looked at revocations, while >>> 2.4 leaves this to the crypto library, and they check all fields >>> more rigidly). >>> >>> Specifically, CRLs with an expired "next update" field are >>> flagged as "expired" by OpenSSL, while the built-in check in 2.3 >>> did not. >> >> This. I replied something similar on the debian bug tracker, but I >> have no clue what will happen with that mail. >> >>> Since this bit a few people already, I wonder how we could >>> communicate this better. >> >> I wonder about that too. Maybe some more verbose text on a wiki >> page? We could even detect this specific error and add a link to >> that page in the warning. >> > > Is there an option to disable this check? It would be extremely > useful to maintain (at least optional) backward compatibility with > already existing setups, which originally relied on 2.3 behaviour. > No, there is not. And I don't think there is an easy way to implement that either. But, the fix is just as easy as the workaround: just regenerate the CRL, with a more correct nextUpdate value. If you don't want your CRLs expire, just put that value far enough into the future. -Steffan -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
> On 02-01-17 15:26, Gert Doering wrote: > > On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: > >> I just got this [1] bug report on OpenVPN 2.4 threating all certs as > >> expired when upgrading from 2.3. I find this quite weird, but until I have > >> some time to test it I thought asking here would be faster. > > > > From the bug report: > > > > Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, > error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, > emailAddress=my@email > > > > "what the log says" :-) > > > > 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some > > built-in checking which only looked at revocations, while 2.4 leaves this > > to the crypto library, and they check all fields more rigidly). > > > > Specifically, CRLs with an expired "next update" field are flagged as > > "expired" by OpenSSL, while the built-in check in 2.3 did not. > > This. I replied something similar on the debian bug tracker, but I have > no clue what will happen with that mail. > > > Since this bit a few people already, I wonder how we could communicate > > this better. > > I wonder about that too. Maybe some more verbose text on a wiki page? > We could even detect this specific error and add a link to that page in > the warning. > Is there an option to disable this check? It would be extremely useful to maintain (at least optional) backward compatibility with already existing setups, which originally relied on 2.3 behaviour. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On 02-01-17 15:26, Gert Doering wrote: > On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: >> I just got this [1] bug report on OpenVPN 2.4 threating all certs as >> expired when upgrading from 2.3. I find this quite weird, but until I have >> some time to test it I thought asking here would be faster. > > From the bug report: > > Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, > error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, > emailAddress=my@email > > "what the log says" :-) > > 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some > built-in checking which only looked at revocations, while 2.4 leaves this > to the crypto library, and they check all fields more rigidly). > > Specifically, CRLs with an expired "next update" field are flagged as > "expired" by OpenSSL, while the built-in check in 2.3 did not. This. I replied something similar on the debian bug tracker, but I have no clue what will happen with that mail. > Since this bit a few people already, I wonder how we could communicate > this better. I wonder about that too. Maybe some more verbose text on a wiki page? We could even detect this specific error and add a link to that page in the warning. -Steffan signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On Mon, Jan 02, 2017 at 03:26:46PM +0100, Gert Doering wrote: > Hi, > > On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: > > I just got this [1] bug report on OpenVPN 2.4 threating all certs as > > expired when upgrading from 2.3. I find this quite weird, but until I have > > some time to test it I thought asking here would be faster. > > From the bug report: > > Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, > error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, > emailAddress=my@email > > "what the log says" :-) > > 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some > built-in checking which only looked at revocations, while 2.4 leaves this > to the crypto library, and they check all fields more rigidly). > > Specifically, CRLs with an expired "next update" field are flagged as > "expired" by OpenSSL, while the built-in check in 2.3 did not. > > > Since this bit a few people already, I wonder how we could communicate > this better. > > gert > > Oh! I see. Thanks Gert!! I can/will add a note on the Debian package, but that has a limited audience. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
Hi, On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: > I just got this [1] bug report on OpenVPN 2.4 threating all certs as > expired when upgrading from 2.3. I find this quite weird, but until I have > some time to test it I thought asking here would be faster. From the bug report: Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, emailAddress=my@email "what the log says" :-) 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some built-in checking which only looked at revocations, while 2.4 leaves this to the crypto library, and they check all fields more rigidly). Specifically, CRLs with an expired "next update" field are flagged as "expired" by OpenSSL, while the built-in check in 2.3 did not. Since this bit a few people already, I wonder how we could communicate this better. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
