https://bugs.documentfoundation.org/show_bug.cgi?id=161872
--- Comment #9 from Moritz Duge <moritz.d...@allotropia.de> --- Created attachment 195198 --> https://bugs.documentfoundation.org/attachment.cgi?id=195198&action=edit SAL_LOG="+INFO+WARN" output (In reply to Miklos Vajna from comment #8) > [...] > 3) Do you understand why the cert verify fails in your case? When you import > the result of create-certs.sh, do you perform the import correctly, as in > you import both the CA chain & the signing cert? When you import the CA > chain, do you mark it as trusted on the Firefox UI? Nice guess! :-) Indeed, when I mark the root and intermediate certificate from create-certs.sh as trusted in Thunderbird (for mail and websites) then ODF signing works. OK I really didn't thought of that. I rarely use X.509 in Thunderbird. And when I do, I use a certificate from https://www.cacert.org/ whose X.509 CA isn't trusted by default in Mozilla software. But Thunderbird never needed me to mark the CACert CA as trusted. Signing and encrypting mails always worked fine without. And so did ODF signing in LibreOffice < 24.2. Thunderbird doesn't make it very convenient to mark the X.509 CA of the users own certificate as trusted. At least I see no direct way from my own certificate in Thunderbird to the trust dialog for the CA. Instead I've had to lookup the CA name in my own certificate and then search trough the long list of CAs. Thunderbird also doesn't notify the user to trust the CA when importing an own certificate. And as said, Thunderbird itself doesn't require CA trust, so that's consistent inside Thunderbird. Conclusion: In LibreOffice 24.2 I can still sign PDF files with X.509 certificates without having the CA trusted. So that's an inconsistency. And if ODF signing shall stay the way it's now, it should get a proper error dialog informing the user about the missing CA trust. And additionally it might be worth a thought, to look for a way to make it easier to mark the own certificates CA as trusted in Thunderbird/Firefox/Seamonkey. Unfortunately I'm currently too busy to care further about this bug. Same goes for an upstream bug at xmlsec. This bug was more of a side discovery and I don't really use that feature. Sorry! But I've still attached the requested SAL_INFOs, in case they are of any use. -- You are receiving this mail because: You are the assignee for the bug.
