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
