Created attachment 119447 [details]
Step-1.jpg, dialog for [Step #1], see description

Created attachment 119448 [details]
Step-2.jpg, dialog for [Step #2], see description

Created attachment 119449 [details]
Step-3.jpg, dialog for [Step #3], see description

It is enough to mention the bitness in the description or summary like you now have.

Reproduce in LibreOffice 5.1.4.2.

Version: 5.1.4.2 (x64)
Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
Locale: zh-CN (zh_CN)

And when using 64bit LibreOffice open a file has Signatured it shows:

The digitally signed document content and/or macros do not match the current document signature.

This could be the result of document manipulation or of structural document damage due to data transmission.

We recommend that you do not trust the content of the current document.
Execution of macros is disabled for this document.

Version: 5.2.2.1
Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; 
Locale: zh-CN (zh_CN); Calc: single

Now, LibreOffice 5.2.0 and 5.2.2 32bit cannot sign documnet either.

*** Bug 102276 has been marked as a duplicate of this bug. ***

(In reply to Samuel Mehrbrodt (CIB) from comment #8)
> LibreOffice 5.2 is EOL now.
> 
> Does the bug still exist in 5.3 or 5.4?

I can use digital signatures on Windows 10 64 bits with LibreOffice 5.4.0.3
So resolve as WorksForMe.
Oliver, if you still have problems in the new versions, feel free to reopen with  details as much as possible :)

Digital signing doesn't work in 64 bit LibreOffice 6.0.6.2. Behaviour is as described by Oliver.

Digital signing doesn't work in 64 bit LibreOffice 6.0.7.3 in Windows 10. Behaviour is as described by Oliver.

Digital signature is not working in 64 bit LibreOffice 6.2.x and 6.3 for Windows 10 x64.

Behaviour is similary as described by Oliver, but i was using a hardware digital signature (eToken):

1)The "Digital Signatures" dialog comes up.
2)The "choose certificate" windows opens up with all availible certificates.
3)I choose a certificate and press "Sign" button.
4)At this point, with a "hardware signature" (eToken), a dialog window should pop up asking for the digital signature password... that is just not happening.
5)The "Digital Signatures" window comes up again without the signature.

Note: Digital signature is working fine at LibreOffice 6.1.6 x64 version, wich actually i have installed and working good.

Martin: it would be great, if you could bibisect the bug: https://wiki.documentfoundation.org/QA/Bibisect/Windows
General instructions: https://wiki.documentfoundation.org/QA/Bibisect

After installing cygwin, the command to clone the repo you need:
git clone https://git.libreoffice.org/bibisect-win32-6.2

Issue exists as described by Martin

Windows 8.1 pro x64

Libreoffice 6.3


In the older version Loffice 6.1.6.3
the digital signature is working.

However for that version another bug exists
https://bugs.documentfoundation.org/showdependencytree.cgi?id=75285&hide_resolved=1

In the older version Loffice 5.4.3
the bug does not appear.

If anyone knows a version 6.xx that is ok let us know in the comments.

We managed to reproduce this issue with 5.4 and newer versions.
5.3 and older (tested: 5.0-5.3, 4.2, 3.5) did work using an X509 certificate to sign odt files on Win 8.1 and 32 bit release versions via SI-GUI. 

bibisect-win32-5.4 shows it begun at:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=273da4e3d1d2a9fb10807d9300d5bac47e1e2584

author	Miklos Vajna <vmiklos@collabora.co.uk>	2017-05-17 09:13:09 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2017-05-17 10:20:50 +0200

xmlsecurity: use xmlsec API instead of patching out cert verification
This flag does exactly what we need since xmlsec-1.2.24.

Adding CC to: Miklos Vajna

Also a debug build gives this console output when trying to sign a document:

warn:xmlsecurity.xmlsec:17676:14848:xmlsecurity/source/xmlsec/errorcallback.cxx:52: ..\src\xmldsig.c:793: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL' A művelet sikeresen befejeződött.
warn:xmlsecurity.xmlsec:17676:14848:xmlsecurity/source/xmlsec/errorcallback.cxx:52: ..\src\xmldsig.c:508: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' ' A művelet sikeresen befejeződött.
warn:xmlsecurity.xmlsec:17676:14848:xmlsecurity/source/xmlsec/errorcallback.cxx:52: ..\src\xmldsig.c:291: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' ' A művelet sikeresen befejeződött.

('A művelet sikeresen befejeződött.' = Operation completed successfully)

Could you please attach some test certificate that triggers this problem? I used the xmlsecurity/qa/create-certs/ script last time to create a self-signed cert for testing purposes, and it was OK, even after the above change.

There is some nastiness going on here and I really hate it.


"JL: OpenOffice.org implements its own certificate verification routine. 
-+           The goal is to separate validation of the signature
-+           and the certificate. For example, OOo could show that the document signature is valid,
-+           but the certificate could not be verified. If we do not prevent the verification of
-+           the certificate by libxmlsec and the verification fails, then the XML signature will not be 
-+           verified. This would happen, for example, if the root certificate is not installed.                "


I don't really get it so I installed Apache openoffice 4.1.7 as well.

I sign a document with Libreoffice 5.4.3.2 that still works for me.

First test, I sign with Loffice and then I open the file from apacheOO.
Apache says the certificate is ok, but the signature is invalid.
Libreoffice says it is ok and the type of signature is XAdES

Second test I sign with Apache and then I open with LIbre
Libreoffice says everything ok and the type of sign is XML-DSig
Certificate is valid and signature is valid

AOO has some ancient libxmlsec, so you need to use crypto algos which are considered unsafe today to please it. If you create a new signature in LO, you'll get SHA-256 for hashing, but AOO only supports MD5 and SHA1. I would say this is their problem, not ours.

@Miklos Vajna

I use safenet etoken 5100 and SafeNet Authentication Client

Who decides for the crypto algorithm, is it Libreoffice of the Safenet Client?

LO asks for the algo of the signing certificate, we handle RSA and ECDSA there. Then we create a signature using the same algo, we don't really have an other choice I think.

Miklos 
I checked my signed libreoffice *.odt and it says

PKCS #1 SHA-1 With RSA Encryption

So it is not SHA-256. 

How come there is the issue with apacheOO ?


"AOO has some ancient libxmlsec, so you need to use crypto algos which are considered unsafe today to please it. If you create a new signature in LO, you'll get SHA-256 for hashing, but AOO only supports MD5 and SHA1. I would say this is their problem, not ours."

Perhaps I misremember, best to look at the code. :-)

What I remembered is that we always create SHA-256 hashes, we just roundtrip SHA-1 for existing signatures.

Anyhow, please don't misuse this bug. This bug tracks the problem of not being able to create signatures at all for specific certificates, on Windows.

Your problem is about an AOO vs LO compatibility; please file a separate issue and then it can be triaged to see if that's a regression, etc. Thanks.

Yes this bug is about that. It would be useful if we had a test build of Libreoffice 6.XX version with the problematic patch reverted so that we could test it the bug is not present.

"Anyhow, please don't misuse this bug. This bug tracks the problem of not being able to create signatures at all for specific certificates, on Windows."

(In reply to Miklos Vajna from comment #19)
> Could you please attach some test certificate that triggers this problem? I
> used the xmlsecurity/qa/create-certs/ script last time to create a
> self-signed cert for testing purposes, and it was OK, even after the above
> change.

Oh, I forgot about setting this back to Unconfirmed. But I sent you privately the requested GovCA certificate that fails for me here.

Creating a test xmlsecurity certificate does not trigger the error, only our GovCA certs. Maybe the accented characters make a difference...

Created attachment 159181 [details]
xmlsecurity certs work, GovCA ones don't

This seems to affect at least 7.2.4.1 x64/win 10 version also - after selecting an X.509 certificate for signing, no signatures are added to the document (either pdf of odt)

In contrast what the heading is saying, I find no bug when I add a digital signature to an existing pdf file. I sign the pdf with my identity card (eID) with a smartcardreader (type Vasco Digipass 870 with integrated keypad) and this digital signature is added to the pdf as soon as I input my pin-code on the little keypath of the smartcardreader.
Verified with AcrobatReader and later, pdf-opening with LO and the message of a signature. For me: there is no bug.
My system: 
- Windows 10 Home (x64) version 21H2
- Libreoffice 7.2.7.2(x64)

What about a similar issue I see on macOS Arm Silicon ?
Should I open a separate report ?

I have an EIDAS hardware certificate (USB key) issued by CertEurope that uses Trusted Key Manager for making the key available to the OS.

I have set up a security device per the supplier's recommendations in Firefox so that the key is readable in a Firefox profile session after entry of a PIN associated with the certificate on the physical USB key.

I can use this certificate to sign PDF files in Adobe Reader.
I can also use the certificate within Firefox to login to a court CMS for which the certificate and key are provided for the filing of signed and authenticated transactions with the court CMS.


However, in LibreOffice, after the usual idiocy of not being able to find a Certificate Manager, I can finally get LO to display an entry dialog for the PIN, when I click on the Sign button (which otherwise shows no available certificates).

I can then sign an ODT, but LibreOffice reports that it could not verify the signature.

One has to ask how it can activate the digital signature and not be able to validate it ?
What use is a X509 signature that isn't validated by the software application that adds it to the document ?

CertEurope uses SHA-256 with RSA Encryption.

If I export the signed ODT to PDF(A/3b), opening the PDF in Adobe Reader doesn't show the document as being signed.

If I create an ODT without a signature, export to PDF with signature, the signature is considered valid in the PDF when opened in Adobe Reader.

Am I missing something, or does signing X590 within the ODT not do anything actually useful ?

Perhaps a separate bug is better, since this bug is specific to Windows.

Testing your use-case in a debug build (where warnings are printed on the console) may be useful. Last time I tested, both a HW token (ECDSA in my case) and software certificates were working. We also have tests for software certificates. So most likely it's not broken in general, just some specific case.

*** Bug 139449 has been marked as a duplicate of this bug. ***

*** Bug 128092 has been marked as a duplicate of this bug. ***