You are not logged in.
Can no longer connect to privateinternetaccess VPN since recent update. I see the following in journalctl repeating after attempting to connect.
I have tried recreating the connection in KDE Plama's network manager configuration panel using a fresh profile downloaded from privateinternetaccess jsut in case theat was the problem. No go.
May 06 12:26:47 nm-openvpn[18396]: VERIFY ERROR: CRL not loaded
May 06 12:26:47 nm-openvpn[18396]: OpenSSL: error:0A000086:SSL routines::certificate verify failed:
May 06 12:26:47 nm-openvpn[18396]: TLS_ERROR: BIO read tls_read_plaintext error
May 06 12:26:47 nm-openvpn[18396]: TLS Error: TLS object -> incoming plaintext read error
May 06 12:26:47 nm-openvpn[18396]: TLS Error: TLS handshake failed
May 06 12:26:47 nm-openvpn[18396]: SIGUSR1[soft,tls-error] received, process restarting
Last edited by AYANE-69 (2024-05-07 14:00:02)
Offline
Tried directly loading the config with OpenVPN directly and get the same errors. Unfortunately I don't know enough about this aspect of computing to make any sense from the errors provide other than it clearly relates to openssl in some way.
Offline
This looks like the OpenVPN configuration is referencing a certificate revocation list file and it's missing.
Verify that the OpenVPN configuration contains a line like
crl-verify filename
and make sure that this file is present.
Last edited by -thc (2024-05-06 06:57:42)
Offline
The config contains a clr block
<crl-verify>
-----BEGIN X509 CRL-----
<lots o' stuff here>
-----END X509 CRL-----
</crl-verify>
`
As mentioned earlier this config has been working for years. I then do one pacman- Syu and now no banana.
Offline
O.K. - that's the inline variant. Please post both inline blocks "<ca>" and "<crl-verify>" here - don't worry, they're public.
Offline
<crl-verify>
-----BEGIN X509 CRL-----
MIIDWDCCAUAwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl
cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw
HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0
ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl
aW50ZXJuZXRhY2Nlc3MuY29tFw0xNjA3MDgxOTAwNDZaFw0zNjA3MDMxOTAwNDZa
MCYwEQIBARcMMTYwNzA4MTkwMDQ2MBECAQYXDDE2MDcwODE5MDA0NjANBgkqhkiG
9w0BAQ0FAAOCAgEAppFfEpGsasjB1QgJcosGpzbf2kfRhM84o2TlqY1ua+Gi5TMd
KydA3LJcNTjlI9a0TYAJfeRX5IkpoglSUuHuJgXhP3nEvX10mjXDpcu/YvM8TdE5
JV2+EGqZ80kFtBeOq94WcpiVKFTR4fO+VkOK9zwspFfb1cNs9rHvgJ1QMkRUF8Pp
LN6AkntHY0+6DnigtSaKqldqjKTDTv2OeH3nPoh80SGrt0oCOmYKfWTJGpggMGKv
IdvU3vH9+EuILZKKIskt+1dwdfA5Bkz1GLmiQG7+9ZZBQUjBG9Dos4hfX/rwJ3eU
8oUIm4WoTz9rb71SOEuUUjP5NPy9HNx2vx+cVvLsTF4ZDZaUztW9o9JmIURDtbey
qxuHN3prlPWB6aj73IIm2dsDQvs3XXwRIxs8NwLbJ6CyEuvEOVCskdM8rdADWx1J
0lRNlOJ0Z8ieLLEmYAA834VN1SboB6wJIAPxQU3rcBhXqO9y8aa2oRMg8NxZ5gr+
PnKVMqag1x0IxbIgLxtkXQvxXxQHEMSODzvcOfK/nBRBsqTj30P+R87sU8titOox
NeRnBDRNhdEy/QGAqGh62ShPpQUCJdnKRiRTjnil9hMQHevoSuFKeEMO30FQL7BZ
yo37GFU+q1WPCplVZgCP9hC8Rn5K2+f6KLFo5bhtowSmu+GY1yZtg+RTtsA=
-----END X509 CRL-----
</crl-verify>
<ca>
-----BEGIN CERTIFICATE-----
MIIHqzCCBZOgAwIBAgIJAJ0u+vODZJntMA0GCSqGSIb3DQEBDQUAMIHoMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExEzARBgNVBAcTCkxvc0FuZ2VsZXMxIDAeBgNV
BAoTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAwHgYDVQQLExdQcml2YXRlIElu
dGVybmV0IEFjY2VzczEgMB4GA1UEAxMXUHJpdmF0ZSBJbnRlcm5ldCBBY2Nlc3Mx
IDAeBgNVBCkTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMS8wLQYJKoZIhvcNAQkB
FiBzZWN1cmVAcHJpdmF0ZWludGVybmV0YWNjZXNzLmNvbTAeFw0xNDA0MTcxNzQw
MzNaFw0zNDA0MTIxNzQwMzNaMIHoMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex
EzARBgNVBAcTCkxvc0FuZ2VsZXMxIDAeBgNVBAoTF1ByaXZhdGUgSW50ZXJuZXQg
QWNjZXNzMSAwHgYDVQQLExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UE
AxMXUHJpdmF0ZSBJbnRlcm5ldCBBY2Nlc3MxIDAeBgNVBCkTF1ByaXZhdGUgSW50
ZXJuZXQgQWNjZXNzMS8wLQYJKoZIhvcNAQkBFiBzZWN1cmVAcHJpdmF0ZWludGVy
bmV0YWNjZXNzLmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALVk
hjumaqBbL8aSgj6xbX1QPTfTd1qHsAZd2B97m8Vw31c/2yQgZNf5qZY0+jOIHULN
De4R9TIvyBEbvnAg/OkPw8n/+ScgYOeH876VUXzjLDBnDb8DLr/+w9oVsuDeFJ9K
V2UFM1OYX0SnkHnrYAN2QLF98ESK4NCSU01h5zkcgmQ+qKSfA9Ny0/UpsKPBFqsQ
25NvjDWFhCpeqCHKUJ4Be27CDbSl7lAkBuHMPHJs8f8xPgAbHRXZOxVCpayZ2SND
fCwsnGWpWFoMGvdMbygngCn6jA/W1VSFOlRlfLuuGe7QFfDwA0jaLCxuWt/BgZyl
p7tAzYKR8lnWmtUCPm4+BtjyVDYtDCiGBD9Z4P13RFWvJHw5aapx/5W/CuvVyI7p
Kwvc2IT+KPxCUhH1XI8ca5RN3C9NoPJJf6qpg4g0rJH3aaWkoMRrYvQ+5PXXYUzj
tRHImghRGd/ydERYoAZXuGSbPkm9Y/p2X8unLcW+F0xpJD98+ZI+tzSsI99Zs5wi
jSUGYr9/j18KHFTMQ8n+1jauc5bCCegN27dPeKXNSZ5riXFL2XX6BkY68y58UaNz
meGMiUL9BOV1iV+PMb7B7PYs7oFLjAhh0EdyvfHkrh/ZV9BEhtFa7yXp8XR0J6vz
1YV9R6DYJmLjOEbhU8N0gc3tZm4Qz39lIIG6w3FDAgMBAAGjggFUMIIBUDAdBgNV
HQ4EFgQUrsRtyWJftjpdRM0+925Y6Cl08SUwggEfBgNVHSMEggEWMIIBEoAUrsRt
yWJftjpdRM0+925Y6Cl08SWhge6kgeswgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl
cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw
HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0
ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl
aW50ZXJuZXRhY2Nlc3MuY29tggkAnS7684Nkme0wDAYDVR0TBAUwAwEB/zANBgkq
hkiG9w0BAQ0FAAOCAgEAJsfhsPk3r8kLXLxY+v+vHzbr4ufNtqnL9/1Uuf8NrsCt
pXAoyZ0YqfbkWx3NHTZ7OE9ZRhdMP/RqHQE1p4N4Sa1nZKhTKasV6KhHDqSCt/dv
Em89xWm2MVA7nyzQxVlHa9AkcBaemcXEiyT19XdpiXOP4Vhs+J1R5m8zQOxZlV1G
tF9vsXmJqWZpOVPmZ8f35BCsYPvv4yMewnrtAC8PFEK/bOPeYcKN50bol22QYaZu
LfpkHfNiFTnfMh8sl/ablPyNY7DUNiP5DRcMdIwmfGQxR5WEQoHL3yPJ42LkB5zs
6jIm26DGNXfwura/mi105+ENH1CaROtRYwkiHb08U6qLXXJz80mWJkT90nr8Asj3
5xN2cUppg74nG3YVav/38P48T56hG1NHbYF5uOCske19F6wi9maUoto/3vEr0rnX
JUp2KODmKdvBI7co245lHBABWikk8VfejQSlCtDBXn644ZMtAdoxKNfR2WTFVEwJ
iyd1Fzx0yujuiXDROLhISLQDRjVVAvawrAtLZWYK31bY7KlezPlQnl/D9Asxe85l
8jO5+0LdJ6VyOs/Hd4w52alDW/MFySDZSfQHMTIc30hLBJ8OnCEIvluVQQ2UQvoW
+no177N9L2Y+M9TcTA62ZyMXShHQGeh20rb4kK8f+iFX8NxtdHVSkxMEFSfDDyQ=
-----END CERTIFICATE-----
</ca>
Offline
Also broke my openvpn connection with this update. Didn't have much time to research but a downgrade to previous version 1.10.2-3 allows me to connect again
This is my work machine & i need the VPN to work, but I believe it has to do with Set Data Ciphers changes in gitlab
NetworkManager-openvpn-1.10.2
Overview of changes since NetworkManager-openvpn-1.10.0
=======================================================
* IP condfiguration is no longer required in TAP mode.
* Fix initialization of secret flags.
* Add support for DOMAIN-SEARCH option.
* Set data-ciphers option with chosen cipher.
* Update Brazilian Portuguese, Croatian, Danish, Georgian, Polish, Serbian,
Slovenian, Swedish, Turkish and Ukrainian translations.
Offline
1.10.2-3 is the version I was on when the problem started. I just upgraded to the recently released networkmanager-openvpn 1.10.4-1 and the problem remains the same. Considering I tried running openvpn directly and had the same problem I don't think it has to do with networkmanager's openvpn plugin.
Offline
I wrote the blocks into separate files (ca.crt and crl.pem). The cert is O.K.
The CRL is invalid:
[thc@box]$ openssl crl -in crl.pem -noout -text
Could not find CRL from crl.pem
40A78D00FB7E0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Update:
This is related to OpenSSL itself: The older OpenSSL (3.2.1) is able to decode the CRL (it's valid for 20 years and revokes two serial numbers with unreadable revocation dates)
Last edited by -thc (2024-05-06 19:34:47)
Offline
Update:
This is related to OpenSSL itself: The older OpenSSL (3.2.1) is able to decode the CRL (it's valid for 20 years and revokes two serial numbers with unreadable revocation dates)
OK progress. However, it would seem pretty dangerous to network-naive me to downgrade a package as important to online security as OpenSSL—assuming of course you even can. So what should my current course of action be? Is this an issue I should be raising with the OpenSSL project or is this an issue on the Private Internet Access side where they need to update what they are doing to support changes in OpenSSL? Or is this an issue with the Arch packaging of OpenSSL?
Last edited by AYANE-69 (2024-05-07 02:29:23)
Offline
PIA's CRL was apparently created in 2016 and has the CRL version number 1.
Since I'm my own CA I produce CRL's via Debian since 2016 with an up-to-date OpenSSL at that time. All of those have the version number 2 and Arch's latest OpenSSL (3.3.0) has no problem decoding even the oldest ones.
So I personally think PIA should be made aware that their CRL is incompatible with OpenSSL 3.3.0 and they should create a newer one.
Offline
So I personally think PIA should be made aware that their CRL is incompatible with OpenSSL 3.3.0 and they should create a newer one.
OK I'll give that a shot and see what happens.
I have contacted PIA support and reported the problem. I have also downgraded to OpenSSL 3.2.1 for the time being which makes me very uncomfortable but has at least got me back up and running. I will mark this as solved as this is clearly not an Arch Linux issue.
Last edited by AYANE-69 (2024-05-07 13:59:27)
Offline
Still have the same problem as of now. Did downgrade to to OpenSSL 3.2.1 and it fixed the CRL issue but it breaks the system as flatpack, curl and pacman require current SSL version to work. I will write to PIA as well.
Currently my workaround is to downgrade to openssl-3.2.1-1 and (forced to) downgrade to curl-8.5.0-1.
Last edited by kivot (2024-06-16 22:49:51)
Offline
Anyone heard back from PIA? I just checked their latest openvpn-strong.zip, and their CRL section is still the same.
Offline
Anyone heard back from PIA? I just checked their latest openvpn-strong.zip, and their CRL section is still the same.
Yes. There is no time estimate for the fix: https://github.com/openssl/openssl/disc … nt-9972854
As a workaround you should be able to remove the CRL section (<crl-verify>...</crl-verify>) and it should work, but without using the certificate revocation list.
Another option is using wireguard: https://github.com/pia-foss/manual-connections
Last edited by progandy (2024-07-11 07:11:29)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks progandy for the context and much better workaround. If there are 2 packages I want up to date, they are openssl and curl.
Offline