It has always been a mystery to me, why the AqBanking/Gwenhywfar library used for online banking in KMyMoney complains about the validity of certificates because it cannot check the signer when all other software on my system has no problem with that, even with the same servers.
Up until now, I simply checked the signer manually using some openssl tools and accepted the certificate within AqBanking. Now that it happened to me that I moved to a new system, the complaints popped up again and I sat down to figure out what the problem really is and how to solve it.
Apparently, each Linux distro has their own way of storing the certificates. Some are based on a single file containing all of the certificates simply concatenated, some others rely on single files in a directory. Also, the location of these files and dirs is different among the distros.
Not knowing where AqBanking is searching for certificates, I ran
strace -e trace=%file -o cert.log kmymoney
and I found the following section in the cert.log file after I saw the dialog with the complaint:
openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr", {st_mode=S_IFDIR|0755, st_size=104, …}) = 0
stat("/usr/share", {st_mode=S_IFDIR|0755, st_size=5498, …}) = 0
stat("/usr/share/ca-certificates", 0x7fff91f0cb30) = -1 ENOENT (No such file or directory)
It seems, that it only looks in two locations and my distro does not keep the certificates in them. So far, so good. Since I build Gwenhywfar with the –enable-system-certs setting, I built it again without that setting just to find out that it does not make a difference with respect to my problem.
Next I studied where the openSUSE distro expects the certificates and found some useful information in /usr/share/doc/packages/ca-certificates/README:
The canonical source of CA certificates is what p11-kit knows about. By default p11-kit looks into /usr/share/pki/trust/ resp /etc/pki/trust/ but there could be other plugins that serve as source for certificates as well.
The next paragraph in that file talks about legacy systems:
update-ca-certificate supports a number of legacy certificate stores for applications that don’t talk to p11-kit directly yet. It does so by generating the certificate stores in /var/lib/ca-certificates and having symlinks from the locations where applications expect those files.
Cool, that is it, but why is it not working for me? Well, the locations that are supported out of the box are not the ones AqBanking is using.
- /etc/ssl/certs: Hashed directory readable by openSSL. Only for legacy applications. Only contains CA certificates for server-auth purpose. Avoid using this in applications.
- /etc/ssl/ca-bundle.pem: Concatenated bundle of CA certificates with server-auth purpose. Avoid using this in applications.
- java-cacerts: Key store fore Java. Only filled with CA certificates with purpose server-auth.
- openssl: hashed directory with CA certificates of all purposes. Your system openSSL knows how to read that, don’t hardcode the path! Call SSL_CTX_set_default_verify_paths() instead.
Hmm, the contents of /etc/ssl/ca-bundle.pem looks very similar to what is kept in /etc/ssl/certs/ca-certificates.crt in other distros. I am a bit adventurous today, so I thought a simple
sudo ln -s /etc/ssl/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt
can help. And in fact, it solved the problem of the unknown signer.
Now I have to find out, why AqBanking/Gwenhywfar always wants me to manually accept an institution’s certificate before I can use it. Or is this by design?