OpenVPN error under Android - certificate error?

Question

Android

We have a working infrastructure consisting of several OpenVPN servers and a number of clients (Windows, Linux and Android).
Client configuration files for different platforms look almost the same, except for minor architectural features of each of the platforms.
All SSL certificates (server and client) for connection are signed by one own certificate authority.
The described infrastructure worked fine until one moment (approximately the end of November 2016), then absolutely all Android clients suddenly stopped connecting. At the same time, no changes were made to the server/client configuration. OpenVPN clients on other platforms continue to work without problems.
Error on Android device when trying to connect:

OpenVPN server certificate verification failed: PolarSSL: SSL read error: X509 - Certificate verification failed, e.q. CRL, CA or signature check failed.

Full version of the log:
Screenshot
Continuation
of the server log at the time of connection:

Wed Feb  1 22:53:11 2017 us=989593 MULTI: multi_create_instance called
Wed Feb  1 22:53:11 2017 us=989754 Re-using SSL/TLS context
Wed Feb  1 22:53:11 2017 us=989905 LZO compression initialized
Wed Feb  1 22:53:11 2017 us=990087 Control Channel MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ]
Wed Feb  1 22:53:11 2017 us=990149 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Feb  1 22:53:11 2017 us=991052 Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Wed Feb  1 22:53:11 2017 us=991138 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Wed Feb  1 22:53:11 2017 us=991187 Local Options hash (VER=V4): '9915e4a2'
Wed Feb  1 22:53:11 2017 us=991226 Expected Remote Options hash (VER=V4): '2f2c6498'
Wed Feb  1 22:53:11 2017 us=991277 TCP connection established with [AF_INET]192.168.0.104:58009
Wed Feb  1 22:53:11 2017 us=991309 TCPv4_SERVER link local: [undef]
Wed Feb  1 22:53:11 2017 us=991340 TCPv4_SERVER link remote: [AF_INET]192.168.0.104:58009
RWed Feb  1 22:53:11 2017 us=991762 192.168.0.104:58009 TLS: Initial packet from [AF_INET]192.168.0.104:58009, sid=d7485053 5ae035e5
WRWRWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRW
Wed Feb  1 22:53:12 2017 us=157279 192.168.0.104:58009 Connection reset, restarting [0]
Wed Feb  1 22:53:12 2017 us=157426 192.168.0.104:58009 SIGUSR1[soft,connection-reset] received, client-instance restarting
Wed Feb  1 22:53:12 2017 us=157552 TCP/UDP: Closing socket

OpenVPN client version for Android:

OpenVPN Connect 1.1.17 (build 76)
OpenVPN core 3.0.12 android armv7a thumb2 32-bit built on May 24 2016 09:42:05

OpenVPN version on the server:

OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  2 2014
library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03

Note: This error also occurs when trying to connect to a server with a newer version.
If you transfer the configuration for Android with all files, certificates, etc. to any other platform, everything is Ok.
Moreover, this error appeared simultaneously for all Android devices (tablets, phones) connecting from different places (different Internet providers) to different servers (different hosting).
To date, I have not found the cause of this error and the way to solve it :(
Comrades, colleagues - please share any thoughts and arguments on this matter. If necessary, I will post the server / client configuration files, or other information of interest.

Answer 1

Thanks to everyone for the answers and comments, I independently found the cause of this incident: it was necessary to re-release the Certificate Revocation List (CRL) file .
Although the incident is resolved, I still do not understand why the Android client was swearing at the "expired certificate revocation list" and in general, how can this list be expired?
The file with the list used at that time was up-to-date with respect to all issued/revoked certificates and was not updated for a long time, because there was no need for this (about 5 months).

Answer 2

does everyone have the same app on android?
maybe you should try something else? if you haven’t tried it, of course
UPD:
I found a forum thread, they are discussing a similar problem here, read the penultimate message there, it helped like