https://bugs.freedesktop.org/show_bug.cgi?id=87030
Bug ID: 87030
Summary: PDF signatures fail on Windows
Product: LibreOffice
Version: 4.5.0.0.alpha0+ Master
Hardware: Other
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
This bug is a follow-up to #66701. It focusses on the original problem reported
there.
When trying to create a digitally signed PDF on Windows, the signature
operation fails. This is taken from the original report:
-----
Steps to reproduce:
1. Install Digital Certificate under Windows /IE by double click onto your .p12
file and follow the Certificate Import Wizard guidance.
2. Enable 'experimental features' under Tools / Options / LibreOffice /
Advanced menu.
3. Export one of your document to PDF with Digital signature via File / Export
to PDF /Digital signature tab. Choose one of your installed certificate and
provide a password for that.
4. Open the created PDF file in Acrobat Reader.
Current behavior:
Malfunctioned signature reported by Adobe Reader:
Signature validity unknown.
Error during signature verification.
Error encountered while BER decoding.
-----
The resulting PDF indeed hat all zeroes where the signature should be.
In the meantime Tor has worked on the problem and found out a lot of related
background:
> On Windows I double-clicked the .p12 file I used in the Linux case, and
> Windows apparently added it fine to its certificate database. It shows up in
> LibreOffice and I am able to try to use it to sign a PDF, but the NSS API
> returns failure from the NSS_CMSEncoder_Finish() call, though.
And more:
> Seems that the situation on Windows is that the code is quite incomplete and
> confused at the moment. On the “PDF Options” page that opens up for
> File>Export as PDF, the “Select” button on the “Digital Signatures” tab opens
> up a dialog that offers certificates that are stored in Windows’s own place
> for such, they are accessed using Windows APIs.
> But then the code that does the actual PDF signing is hardcoded to use only
> NSS APIs. And NSS apparently has no access to the Windows certificate store,
> so it can’t find the one it is told to use.
And:
> I think I now understand what is going on with the PDF signing on Windows.
>
> On Linux (and OS X), we use NSS for all this, and its certificate store. The
> Tools>Options>LibreOffice>Security page has a "Certificate Path" setting,
> which is a directory where the NSS cert8.db, key3.db and secmod.db files
> should exist.
>
> The code that handles the selection of certificate (the "Select" button on
> the "Digital Signatures" tab of the File>Export as PDF dialog) has two
> "backends": a NSS one that is used on Linux and OS X, and a Windows one.
>
> The NSS backend calls NSS_Init() with the certificate path directory as
> parameter. The dialog shows the certificates storted in this NSS database. I
> don't know what the "user-friendly" way to manage this database is, but one
> can use the horrible certutil or pk12util command-line tools to add
> certificates there...
>
> This code is located in the xmlsecurity module, because it was originally
> written for ODF-signing functionality. (And perhaps signing of older, now
> already obsolete, XML-based document formats?) (No idea if this stuff is also
> used when signing OOXML.)
>
> On Windows, the dialog shows the certificates stored the user's Windows-
> managed certificate store. (One adds certificates there by simply double-
> clicking on .p12 or .cer files.) No NSS_Init() is called, of course.
>
> So far, so good.
>
> But, the PDF signing code uses NSS directly. (It couldn't use xmlsecurity
> anyway, as PDF has nothing to do with XML.) It calls NSS_NoDB_Init(), which
> is the function to initialise NSS to work *without* any database (the
> cert8.db etc files), but that is actually irrelevant on Linux, as it is the
> first of any NSS_Init() and NSS_NoDB_Init() calls that counts, subsequent
> calls are no-ops. So, on Linux, the NSS_Init() call done when fetching the
> list of certificates, which passed in the directory from the "Certificate
> Path" setting, stays in force.
>
> On Windows, however, this NSS_Nodb_Init() call is what initialises NSS. This
> then means that eventually the NSS_CMSEncoder_Finish() call fails. I donut
> know the exact mechanism here. Why it is that particular the NSS call that
> fails, the next-to-last NSS API called, I have no idea.
>
> Just as a test, I changed the NSS_NoDB_Init() call to instead call
> NSS_Init(), passing in the pathname to the directory on my Linux machine with
> a NSS database where I had stored the same certificate that I had added to my
> Windows certificate store. Then the signing works! But this is only of
> academic interest of course.
>
> As I see it, there are two possible ways forward to get this stuff to work on
> Windows:
>
> 1) Set up a NSS database also on Windows. One would think there is a way to
> get the stuff to be added to that out of the Windows certificate store, using
> Windows APIs, and then store it in the database, using NSS APIs. Make sure to
> call NSS_Init() with the path to this database. Then the PDF signing code
> needs no change.
>
> 2) Add a Windows-specific implementation of the PDF signing. It is a single
> function, as far as I can see, PDFWriterImpl::finalizeSignature(), that needs
> ifdefs. This probably makes more sense. Presumably one just needs to figure
> out the right WinCrypt APIs to use instead of the NSS APIs. The concepts
> should be fairly similar, one hopes. It shouldn't be more than a handful
> function calls, knock on wood.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
