-
I apologize in advance if this is not the correct place to report this issue. I am using Slackware-current and I about two weeks ago I noticed that my private internet access VPN would not connect using openvpn. After some digging I was able to confirm that the problem is being caused by openssl-3.3.0. Downgrading openssl to 3.2.1 fixes the problem and PIA starts working again. Here is some log output, if anyone has an ideas on how to fix this please let me know. Thanks.
2024-04-29 14:43:07 OpenSSL: error:0A000086:SSL routines::certificate verify failed: |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
The CRL that is being loaded is malformed. It contains malformed revocation dates for 2 certificates. If there is some way how to disable the CRL processing in the VPN client, it might help as a workaround. A proper fix would have to be done by the certificate authority that issued the CRL - i.e., fix it so the revocation dates are proper. |
Beta Was this translation helpful? Give feedback.
-
A workaround from this reddit post worked for me. It involves manually editing the .ovpn file to change the verification of the date. |
Beta Was this translation helpful? Give feedback.
-
As of this posting I am still experiencing the issue with the crl file. Customer service didn't really have an answer for me when I emailed them but they did let me know that the issue is on their radar and they're trying to find a fix. For now, I've been able to switch over to wireguard using the manual_connections scripts provided by PIA on their foss GitHub. Fingers crossed they get this sorted out soon. |
Beta Was this translation helpful? Give feedback.
The CRL that is being loaded is malformed. It contains malformed revocation dates for 2 certificates. If there is some way how to disable the CRL processing in the VPN client, it might help as a workaround. A proper fix would have to be done by the certificate authority that issued the CRL - i.e., fix it so the revocation dates are proper.