Remember what the whole Y2K issue was like, over a quarter-century ago? And all the work that had to be done to fix it? You’d think that lessons were learned, software developers would be wiser, and henceforth they would always use four digits for year numbers, so that a situation like that would not occur again. Guess again. Recently I hit a situation where a piece of software was *still* using just two digits for year numbers. Basically it was maintaining Certificate Revocation Lists (CRLs) for OpenVPN connections; these have an expiry date, in the form of the “nextupdate” field, to ensure that outdated lists are regularly replaced with fresh ones, to reduce the chance that anybody is inadvertently continuing to use compromised keys. The software in question is pfSense, from Netgate <https://forum.netgate.com/topic/172870/crl-has-expired>. The standard format for these CRLs can handle a full range of dates, but the internal system on pfSense for generating them can only handle years from 1950 to 2049. The generated CRLs were being given validity durations of 9999 days, which was fine up until about August this year, when the expiry date went past 2049, and wrapped around to 1950. On an incoming connection attempt, OpenSSL would check the CRL, find it invalid, and cause OpenVPN to drop the connection. The forum discussion above links to a patch to fix the issue. Only the patch doesn’t really make for a permanent fix: all it does is reduce the assigned validity duration from 9999 days to 730 days; the actual underlying software is still only working with 2-digit year numbers. This gives Netgate a few decades’ breathing room to come up with a proper fix.