OpenVPN OpenSSL entry 22: invalid expiry date

I attempted to generate some OpenVPN keys for a new employee the other day. Same procedure as normal. Nothing has changed in this area for months.

During the certificate generation I get the following error:

Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
entry 22: invalid expiry date

After some searching, there doesn't appear to be a clear answer. Some sites said something about a database file index.txt becoming damaged. Others said that its something to do with the default_days setting in openssl.cnf. Other sites suggested its an OpenSSL bug.

Anyone have any clues?

UPDATE

After more research I have discovered that there is a bug with OpenSSL where the expiration date for the last generated certificate goes beyond the year 2050, and thus the date in the index.txt has two extra digits added to it for some reason, thus making the index.txt appear corrupted. I'm not sure how to fix this.

This is a 'Year 2038 Problem' bug! It seems that OpenVPN certificates cannot be generated which expire after Jan. 19, 2038. I'm using Ubuntu 10.04 and OpenVPN 2.1.0.

I know this is a really old question, but just ran into this issue myself and took a long time to solve - hoping this might help somebody in the future. Also, seeing how this is still one of the first results google provides for a search on this error, it seems relevant to post here.

'entry 22' refers to line 22 of the database file for the CA - in your case it sounds like this file is 'index.txt'. My error was 'entry 477' which refered to line 477 of my CA's database file.

To fix this just go manually modify your database file and make the expiration date look as it should.

For my OpenSSL database file the second column corresponds to the expiry and my invalid entry that caused this error was '20160505000000Z'. This particular entry had 2 extra digits compared to all other entries. The 2 extra digits were the '20' of the '2016'. I manually changed this to '160505000000Z' and then this error went away.

Not sure how it allowed that to be written in the first place, but that is what fixed mine. Hope this helps somebody.

I ran into the same issue and can confirm the year 2038 bug with openssl 0.9.8 Manually changing the time in index.txt "fixed" the "invalid expiry date" error message, but the generated certificate then has a validity until 1902.

So you either have to use openssl 1.0+ or reduce the "days" parameters, e.g. in your openssl.cnf.