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 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.


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

Reply via email to