Digital Signature in Windows client is shown as valid although it shouldn't

Hello community

I’m currently setting up a public key infrastruture in my organization for internal use. We want to sign documents with macros for security reasons.

We currently have a three level hierarchy for our CA:
– root ca
---- production ca
-------- LibreOffice certificate (end-entity for signing documents including macros)

The problem is that when I create a document, sign it with our LibreOffice certificate (see above) and then I untrust our production ca (resulting in a destroyed chain of trust for this certificate) LibreOffice will always display a message to me stating that the signature would be valid although it shouldn’t since I removed an intermediate CA out of the Windows trust store.
When I remove the root CA as well I get the behaviour I would also expect LibreOffice to do when there is an untrusted intermediate CA, so stating at start up that the signature is invalid. MS Excel does this properly and correct (to my personal astonishment). On a second computer where I’m running Linux Mint (here LibreOffices uses the Firefox trust store) I also got the expected and correct behaviour (one intermediate certificate is missing => signature isn’t valid). On a third device running Windows 11 I tried two different LibreOffice versions (24.2.3.2 and 24.8.1.1) which lead to the same unwanted behaviour

During my first tests with out internal CA I got this working as it should, if I remember correctly. But I can’t remember what I did different back then. I’m trying to debug this problem now for several days. Since our CAs and their issued certificates all work perfectly I can’t think of the problem to be on our side. However I also can not suppose that the problem lays on the side of LibreOffice because our situation doesn’t seem to be that specific so that nobody else wouldnt have experienced this yet. And yet during my researchs I haven’t seen threads or posts with roughly the same problem as we now experience.

I hope somebody knows a solution or at least can confirm to me that this is indeed a bug.

Version Info Windows

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded

Version Info Linux

Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: de-DE (en_US.UTF-8); UI: de-DE
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.6
Calc: threadedi

Do you think there may be a reason it could be not a bug?

Yes. I think there could be reasons. But I at least don’t know them. I debugged different OpenSSL settings, tried different versions of LibreOffice on different OSes. But since LibreOffice Linux (and Excel on Windows) work with our certificates like we would expect them to do its difficult to narrow down on which end the problem lies - our’s or perhabs LibreOffice’s?

This is a bug.

I opened a bug report regarding this unexpected behaviour:
https://bugs.documentfoundation.org/show_bug.cgi?id=162693

1 Like