Wow, thank you!
Another really well-written, detailed and knowledged guide by @olf.
I am not that deep into that cert stuff, normally do not need it and always forced to dig into it when something happens.
So I did not dare to look for the cert to put it into the blacklist (as it was not in pem format in the bundle).
One noob question I do have: why is my approach only almost? 
I used the source bundle and ran update-ca-trust.
What is “wrong” with that?
I am not that deep into that cert stuff, normally do not need it and always forced to dig into it when something happens.
Neither was I WRT how certificates, their updates and manual intervention are practically handled on modern Linux distributions.
But a co-worker firmly stated, “do read the update-ca-trust man-page thoroughly and do not alter the source bundle”, so I went down that road.
So I did not dare to look for the cert to put it into the blacklist (as it was not in pem format in the bundle).
Well, openssl makes these conversions easy (see in the guide).
One noob question I do have: why is my approach only almost?
I used the source bundle and ran update-ca-trust.
What is “wrong” with that?
One shall not alter the source bundle!
It belongs to an RPM and any update of that RPM (ca-certificates) will overwrite your changes in the source bundle, plus its %post script will trigger update-ca-trust, which overwrites the changes in the target bundle: then your device is back at the start (WRT the certificate issues).
For example, all this will happen during the next SailfishOS upgrade; I would not be surprised, if it fails to finish, due to failing https connections.
Do read the update-ca-trust(8) man page, which additionally explains why manual adaptions by a sysadmin usually should be performed in the /etc/pki hierarchy (priority over /usr/share/pki etc.).
Thanks again for explanation.
Then, from my perspective, I did it well enough
knowing my changes will be overwritten…
it was meant for a Jolla1, not getting any more updates
and for newer devices the removal of X3 was said (and with shipping of ssl1.1 the right cert is chosen anyway)
But again, your guide is appreciated to do it right the next time!
Then, from my perspective, I did it well enough
You sure did, without this hint I would not have known what to ask and look for.
knowing my changes will be overwritten…
it was meant for a Jolla1, not getting any more updates
I needed it for an XperiaX@SFOS3.2.1, which I may update, when ultimately a newer SailfishOS release is published which does not contain flaws seriously impeding my usage.
and for newer devices the removal of X3 was said (and with shipping of ssl1.1 the right cert is chosen anyway)
???
As documented above, only SailfishOS 4.1 to 4.3 provide an updated ca-certificates RPM.
And all this is regardless of the device used.
I have Verla 4.2 since today and the email cannot work, complaining about certificates… Which one is the correct way to fix the isue on Saifish 4.2 ?
Cannot tell, because “the email cannot work, complaining about certificates…” does not include any relevant information.
But walking through section A is fully and easily reversible (if you understand it), so you might as well just try.
Email means standard native email. Version is 4.2.0.21. IIRC it stopped working with the previous version 4.1.x.x (I don’t remember which) some days ago. Mail app shows “check certificates” upon sync.
Which is the best approach (A or B) for 4.2.x.x OS ?
I tried approach A but it doesn’t fix the issues with my email provider; the account is an Exchange one. What makes the email accessible is to reset the password and allow untrusted certificates (I really don’t like that).
IMHO none.
B. Download a recent CA-certificate bundle RPM for SailfishOS,
The most recent ca-certificate RPM Jolla currently provides is the one deployed on SailfishOS 4.1.0, 4.2.0 and 4.3.0.
And A fixes something which is already fixed in the recent ca-certificate RPM.
Thus no fix available for now. Nice.
That sounds as if “your email provider” has certificate issues, do not blame SailfishOS / Jolla, rsp. Fedora / RedHat rsp. Mozilla for this: Their certificate bundle is fine.
What about installing openssl
and try to dig what goes wrong in cert chain with
openssl s_client -connect servername:portnumber
Very possible.
Thanks a lot
Please mind, that you nowadays also need OpenSSL 1.1 for “the WWW to work”, hence on SailfishOS < 4.0.1 one must:
Install a newer OpenSSL package from here: OpenSSL 1.1.1 + 1.0.2 | OpenRepos.net — Community Repository System
If you are doing this manually (without Storeman), you also have to download the OpenSSL -libs RPM (omit the -devel RPM): openssl-libs 1.1.1 + 1.0.2 | OpenRepos.net — Community Repository System
When using the command line, you have to install these in one go (using the ARMv7 RPMs for e.g., a Jolla1 in this example):
pkcon install-local openssl-1.1.1kgit1-1.7.4.jolla_.armv7hl.rpm openssl-libs-1.1.1kgit1-1.7.4.jolla_.armv7hl.rpm
Minor updates to the original guide are at olf (Olf0) (Olf0) / Guide - Fix certificate issues on SailfishOS · GitLab
Because the idiotic default configuration of Discoure (which Jolla will not alter) makes all messages uneditable after a while, except for “wiki”-pages.
Hey there, sailfish 3.2.1.9 running on an aquafish.
I tried the blacklist method and i even installed newer openssl (I couldn’t use zypper as zypper can’t download packages because of the certificate validity).
[root@Sailfish anchors]# rpm -qa | grep openssl
openssl-libs-1.1.1k+git1-1.7.4.jolla.armv7hl
openssl-1.1.1k+git1-1.7.4.jolla.armv7hl
I have verified and I don’t even have the DST Root within /etc/pki/tls/certs/ca-bundle.crt
Nothing works unfortunately! Any suggestions?
* TCP_NODELAY set
* Expire in 149994 ms for 3 (transfer 0xae9d30)
* Expire in 200 ms for 4 (transfer 0xae9d30)
* Connected to www.google.com (142.251.209.4) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, bad certificate (554):
* SSL certificate problem: certificate is not yet valid
* Closing connection 0
curl: (60) SSL certificate problem: certificate is not yet valid
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Try installing a newer certificate bundle as described under B; choosing the third method may be easiest.
Can’t install anything newer than what I have because of the pk11 packages version constraint, do you know if I can pick them from 3.4.0 and install them on 3.2.19? As if they are supposed to work
Sorry, I do not understand: Please provide the commands you used and their output for clarity.
Hello i just found back my old jolla phone and try to give it a new life 
It was factory reset to 1.0.0.5…i tried to install recent certificate 2021 but then stuck with p11-kit dependencies any suggestion ? thanks in advance
Does this work for Email “certificate error” too? (See Email Update Error: Check Certificate ). I am on Sailfish OS 3.4.0.24 (Jolla 1), and updated the certificates with the zypper method successfully. But I still am able to send / receive email only by enabling the “Accept Untrusted Certificates” option.
My email provider says everything is fine at their end. Any suggestions on how to troubleshoot this issue?