You are not logged in.
Hello everyone,
I am using OpenVPN for mayn years to connect to my office when I am on the road. Since last openssl update (1.0.2.k-1 -> 1.1.0.e-1) my pkcs12 file is not accepeted any more, and therefore the connection to the remote server is not even tried.
The error messages I get are:
Fri Apr 28 10:24:47 2017 OpenSSL: error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
Fri Apr 28 10:24:47 2017 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
Fri Apr 28 10:24:47 2017 Cannot use certificate
Fri Apr 28 10:24:47 2017 Exiting due to fatal error
What can I do in order to be able to connect to my office again?
Unfortunately generating a new pkcs12 file with current encryption methods is not an option, because this is a very complicated process for my company.
Any help is very much appreciated!
Thank you
/Thomas
Last edited by thomas66 (2017-04-28 11:39:40)
Offline
I had the same issue; unfortunately, I did have to ask the Ops team to generate new credentials for me. But is not a complicated process and it was easliy sorted.
Offline
Thank you for the fast reply.
My problem is that there are no Ops available at the moment, because they are on vacation due to 3day weekend (1st of May) here in Germany. And I need access to my office before they come back.
I was not aware, that a regular update of openssl could cause so much trouble.
At the moment I try to downgrade ot openssl 1.0.2.k-1, but at first try that failed, too (sorry for messages being all in German):
[root@allegro pkg]# pacman -U openssl-1.0.2.k-1-x86_64.pkg.tar.xz
Lade Pakete...
Warnung: Downgrade des Paketes openssl (1.1.0.e-1 => 1.0.2.k-1)
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Pakete (1) openssl-1.0.2.k-1
Gesamtgröße der installierten Pakete: 7,00 MiB
Größendifferenz der Aktualisierung: 0,76 MiB
:: Installation fortsetzen? [J/n]
(1/1) Prüfe Schlüssel im Schlüsselring [############################################################################] 100%
(1/1) Überprüfe Paket-Integrität [############################################################################] 100%
(1/1) Lade Paket-Dateien [############################################################################] 100%
(1/1) Prüfe auf Dateikonflikte [############################################################################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
openssl: /usr/lib/libcrypto.so.1.0.0 existiert im Dateisystem
openssl: /usr/lib/libssl.so.1.0.0 existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
[root@allegro pkg]
Both conflicting files are part of the openssl package. So shall I dare it and try to force the installation of "openssl-1.0.2.k-1"?
/Thomas
Last edited by thomas66 (2017-04-28 08:59:43)
Offline
Looks like I bricked my pacman now :-(
I did as described on the Arch-Wiki and renamed the conflicting files. Then pacman command to downgrade openssl worked, at least almost. It gave two errors in post installation process:
(1/1) Downgrading openssl [############################################################################] 100%
ldconfig: /usr/lib/libcrypto.so.1.0.0 ist kein symbolischer Link
ldconfig: /usr/lib/libssl.so.1.0.0 ist kein symbolischer Link
Now openvpn does not start at all. Which is no suprise since it was linked agains the newer openssl version. But when trying to downgrade openvpn as well I got aware that pacman is not working any more, too:
[root@allegro pkg]# pacman -U openvpn-2.4.1-1-x86_64.pkg.tar.xz
pacman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
All my fault.
I should have been aware that pacman relies on openssl, too. And that the troubleshooting WIKI entry is not ment for for downgrading, but for regular upgrades.
I am wondering now how I can get a working system back....
/Thomas
Offline
Have you looked at using the pacman archive?
https://wiki.archlinux.org/index.php/Ar … cific_date
That might be a better solution than trying to hunt down and downgrade Openssl and all of its dependents.
I would probably try to restore pacman function by returning to the current Openssl package and then use the archive. If you can't get pacman to work again, the next option would probably be to create a live media and chroot into your system and archive downgrade from there.
Last edited by Mortimer Houghton (2017-04-28 09:55:09)
Offline
Thank you very much for that hint.
That would have been a very good idea to do, indeed.
Unfortunately I have bricked my pacman, so I cannot commit the "pacman -Syyuu" command after adjusting the config files.
I am still searchig the internet for a solution for that issue.
/Thomas
Last edited by thomas66 (2017-04-28 09:58:21)
Offline
Unfortunately I have bricked my pacman, so I cannot commit the "pacman -Syyuu" command after adjusting the config files.
Offline
Thank you for the hint,
did as described and it worked out well. Now I have a fully running system again.
I will try to set it back to consistentt state of April 20 2017 as descripe some posts above.
Thank you all for your help
/Thomas
Offline
My issue is solved only partially.
Unfortunately getting a consistend older system state, with openssl-1.0.2.k-1 was not possible for me.
The newest package archive that still uses the required openssl library is from 2017-04-23. When issuing "pacman -Syyuu" as described on the ArchWiki-Article I still get a lot of "file already exists" messages:
(350/350) Prüfe auf Dateikonflikte [################################################################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
openssl: /usr/lib/libcrypto.so.1.0.0 existiert im Dateisystem
openssl: /usr/lib/libssl.so.1.0.0 existiert im Dateisystem
guile: /usr/include/guile/2.0/libguile.h existiert im Dateisystem
guile: /usr/include/guile/2.0/libguile/__scm.h existiert im Dateisystem
guile: /usr/include/guile/2.0/libguile/alist.h existiert im Dateisystem
guile: /usr/include/guile/2.0/libguile/arbiters.h existiert im Dateisystem
guile: /usr/include/guile/2.0/libguile/array-handle.h existiert im Dateisystem
[...]
At the moment I do not dare to force any update or somthing like that.
/Thomas
Offline
My interim solution to get at least the most important files from my office: Install an old ArchLinux version into a virtual machine and take care not to update that machine to a state newer than 2017-04-23.
/Thomas
Offline