Electronic signing in Collabora Online

Posted on: Mon 03 March 2025

Estimated read time: 13 minutes

LibreOffice Technology had the concept of digital signing, but this was not available in Collabora Online, so it was not possible to combine this with collaborative editing. Also, once Collabora Online started to expose digital signing with software certificates for ODF files, that also allowed taking a further step and start supporting electronic signing for PDF files. Partnering with eID Easy, you can create strongest of the electronic signatures – the mighty QES. This means signing with Collabora Online allows you to:

create proper electronic signatures
not share your document with a 3rd-party, only the hash of your PDF will be sent to the external service
integrate with e.g. Nextcloud, use the feature without installing anything other than the Nextcloud AIO image
potentially combine signing with other security features like Secure View and
work with visual signing in a WYSIWYG way, which allows placing a visible signature widget at the specified page, then dragging it to the preferred position.

The sample integration presented here is for Nextcloud, but the feature can be made available in other integrations as well.

See Collabora's blog post if you prefer less technical information about this feature.

Motivation¶

Digital and electronic signing of documents is meant to be based on cryptographic security, and traditionally this has been exposed to users in a very complex way. You need to know that first you have to sign your macros and only then your document, you need to somehow get PEM files to have a signing certificate, you need to somehow get your certificate trusted by some certificate authority that is commonly trusted by other people who will verify your signature, and so on.

This lead to the need to first support digital signatures in COOL using a single signatures dialog for ODF files and then later to provide electronic visual signing for PDF files, while continuing to respect your privacy by not sharing your document with a 3rd-party service.

Results so far¶

A read-write signatures dialog¶

First the signature viewer dialog was turned into a read-write digital signatures dialog in COOL that is still async (compatible with collaborative editing), first for ODF files & using PEM files.

Related to this, we automatically sign macros (if the document has macros) when signing the document, so you can’t forget about this or get the order wrong (sign macros first, then the document).

At this stage implementing signature removal was possible, which again needs an async conversion so the user can confirm they really want to remove a signature. This also means the signature status of the document can change, the COOL UI now supports this.

You can now associate a signing certificate / key / CA chain with a COOL editor, so you can sign the document, but not an other editor working on the same document.

Finally adding a digital signature is now possible, where the certificate chooser just shows your signing certificates and hides it from other editors.

Here is a screenshot of the early digital signatures dialog at this stage:

Initial async digital signatures dialog in COOL with sign and remove buttons

Automatically signed documents¶

The second half of digital signing support in COOL started with WOPI extensions, so an integrator of COOL can specify the signature settings on their user settings page and pass that to COOL when a document is edited. We then send this to the document editor process only when needed, i.e. not on file open, but when the actual signing process would start.

UI is also added on the notebookbar in the form of a new button that allows adding signatures to a previously unsigned document – before you could only trigger the signatures dialog if the status bar said something about existing signatures, and only then you could add a signature. This button is hidden if you don’t have signature settings configured. It looks like this:

When was still missing here is automated Cypress tests to make sure signing e.g. an ODT file keeps working and the SDK documentation now also describes what does it take to support digital signatures in your COOL integration. For example you can create a Nextcloud integration like this:

Nextcloud integration for digital signing

Finally, COOL’s convert-to endpoint is hooked up with signature support, so you can export to a signed PDF. Example curl invocation:

curl -k -F "data=@in.odt" -F "format=pdf" -F 'options={"SignPDF":{"type":"boolean","value":"true"},"SignCertificateCaPem":{"type":"string","value":"..."},"SignCertificateCertPem":{"type":"string","value":"..."},"SignCertificateKeyPem":{"type":"string","value":"..."}}' https://localhost:9980/cool/convert-to > out.pdf

Plumbing for electronic signing¶

Once digital signing of ODF files is handled, let’s switch to PDF signing, which is much more interesting: you typically want to sign something final, and we see PDF as a final output of your documents. So first support for digital signing of PDFs was added.

The next part is to integrate with eID Easy, which can do privacy-friendly electronic signing for us. This is a 5 step process:

Extract the hash of the to-be-signed document. This is similar to signing, you start the process but once you have the hash that you would sign locally, you just take that hash and abort the actual signing.
Send this hash to the electronic signing service.
Open a popup and let the user authenticate with their credentials (passport, personal ID, etc) using one of the providers (different providers support different countries) and sign the hash.
Download the signed hash from the service.
Serialize this signed hash into the local document. This requires producing the local PDF signature once more, but this time using the previous timestamp (instead of the system clock, so the hash is table) and using the downloaded PKCS#7 signature instead of locally signing something.

At the end we got something that looks like a signature produced externally, but there was no UI for this. An initial popup for step 3 looked like this in the test environment (that doesn’t work with real passport numbers or anything sensitive):

UI for electronic signing¶

The next step was to create a user interface for electronic signing. The Insert menu had a new menu item to insert electronic signatures and to specify your country, finally choose one of the providers available in your country.

Also support for two types of providers is added: the first is the “in context” one, the other is a “redirect based” one. We now support both: all the redirect (should be familiar to you if you ever did e.g. online payments) happens in the popup, so the original COOL editor is never closed.

eID also has the concept of multiple tokens for signing: initiating the signing costs money, so is done using a “secret”, which is never sent to the COOL JS code. Then the “client ID” identifies the client, but can’t be used to start signing. Finally any single signing transaction has a specific “document ID”. We took care to follow the guidelines here, so the sensitive “secret” for signing is always kept on the server.

Similar to the initial document signing, electronic signing settings are also possible to specify from an integration, we documented this in the SDK and also created a sample Nextcloud integration for this.

The Nextcloud integration looks like this:

Nextcloud integration for electronic signing

Note that later the API URL was changed to be a hidden setting, as real signing never needs a custom value there, this is just for testing.

Visual signing¶

The last part of this electronic signing effort was to expose visual singing in COOL, something that was added to LibreOffice Draw back in 2020, see this earlier blog post.

First this was exposed in COOL with digital signing, in a way that the current page gets a signature widget inserted at the page center and then the user can move that signature widget to the desired location.

Combining this with electronic signing is a bit more tricky, since we don’t want to select a certificate when the signature widget is inserted, we’ll deal with that in the external service, as usual.

Also, there was no real reason to not use visual signing unconditionally, so now the way to initiate a signing process is to open your PDF in COOL, use the Insert → Signature line menu item to insert a signature widget, move it to the wanted position, click “finish” on the snackbar and that completes the process with the usual electronic signing popup.

The final problem was that our multi-page PDF viewer was not really prepared to deal with changed PDF content (assuming your PDF rendering will not change is reasonable), so some last minute work had to be done to make sure the signature widget’s graphical selection indicator, its dragging and its rendering works fine even on non-first pages of a PDF document.

At the end, a test signature using the d-trust signature provider’s test environment looks like this:

Electronic signature with a signature widget / visual signature on page 2 of a PDF file, using the test environment of the d-trust provider.

Or if you prefer watching a demo, a typical electronic signing process session looks like this:

Demo of electronic signing with Collabora Online, part of a tea-time training

There were a few more talks with similar content:

At the end you get an electronic signature that is trusted by the EU trust list and thus e.g. Acrobat Reader:

How is this implemented?¶

If you would like to know a bit more about how this works, continue reading... :-) As usual, the high-level problem was addressed by a series of small changes.

LibreOffice core commits:

Collabora Online commits:

Nextcloud richdocuments commits:

Want to start using this?¶

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition.

Category: collabora-online – Tags: en