FUCKUP #005: The Expired Certificate Was Only the First Failure

A Nextcloud-to-Paperless upload stopped working in a home test environment.

The first error was clear:

cURL error 60: SSL certificate problem: certificate has expired

The Paperless certificate had indeed expired.

The first fix

The Nextcloud Paperless integration sends uploads from:

custom_apps/integration_paperless/lib/Service/ApiService.php

or, depending on the installation:

apps/integration_paperless/lib/Service/ApiService.php

In the POST request to:

/api/documents/post_document/

this option was added:

'verify' => false,

Example:

$this->client->post(
    $this->config->url . '/api/documents/post_document/',
    [
        'verify' => false,
        'headers' => $this->getAuthorizationHeaders(),
        'multipart' => [

After restarting the Nextcloud/PHP runtime, uploads worked again.

This was a deliberate test-environment workaround, not a proper TLS fix. verify => false disables certificate verification for that request and should not be used as a normal production solution.

This failure was at a different certificate layer from a Windows service failure where private-key access mattered to recovery. Here, the client rejected the remote server certificate before the upload request could proceed.

Then the next failure appeared

An ODT file now reached Paperless successfully, but document conversion failed with:

503 Service Unavailable

from:

http://gotenberg:3000/forms/libreoffice/convert

The Gotenberg log showed:

LibreOffice listener socket not available:
context deadline exceeded

with a request duration of almost exactly:

10.003s

LibreOffice itself was present:

/usr/bin/libreoffice
LibreOffice 7.0.4.2

So the problem was not a missing LibreOffice installation. Gotenberg simply did not get its LibreOffice listener ready within the available ten-second window.

The next step was therefore to increase the startup timeout, for example:

command:
  - "gotenberg"
  - "--uno-listener-start-timeout=60s"
  - "--api-timeout=120s"

and recreate the container:

docker compose up -d --force-recreate gotenberg

The surviving notes do not record whether that final change was verified successfully.

The lesson

A different error can be progress.

The first failure stopped the request at TLS validation.

After that was bypassed, the document progressed through Nextcloud and Paperless until it hit a completely different failure in Gotenberg.

So do not ask only:

Did the original error disappear?

Ask:

How far did the request get this time?

That is often the more useful answer.