Let’s Encrypt certificate creation fails with TypeError in version 5.0.83 (Docker / Kubernetes setup)

[maltekiessling]

Hi everyone,

when trying to create a Let's Encrypt certificate for my instance via the GlobaLeaks admin interface, I’m getting the following error:

Platform: ***
Host: *** (***.onion)
Version: 5.0.83

TypeError Inappropriate argument type.

Traceback (most recent call last):

  File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 269, in inContext
    result = inContext.theWork()  # type: ignore[attr-defined]

  File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 285, in <lambda>
    inContext.theWork = lambda: context.call(  # type: ignore[attr-defined]
                                ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ctx, func, *args, **kw
        ^^^^^^^^^^^^^^^^^^^^^^
    )
    ^

  File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 117, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^

  File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 82, in callWithContext
    return func(*args, **kw)

  File "/usr/lib/python3/dist-packages/globaleaks/orm.py", line 175, in _wrap
    result = function(session, *args, **kwargs)

  File "/usr/lib/python3/dist-packages/globaleaks/orm.py", line 206, in tw
    return f(session, *args, **kwargs)

  File "/usr/lib/python3/dist-packages/globaleaks/handlers/admin/https.py", line 77, in db_acme_cert_request
    https_cert, https_chain = letsencrypt.request_new_certificate(hostname,
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
                                                                  acme_accnt_key,
                                                                  ^^^^^^^^^^^^^^^
                                                                  https_key,
                                                                  ^^^^^^^^^^
                                                                  State.tenants[tid].acme_tmp_chall_dict,
                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                                  Settings.acme_directory_url)
                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  File "/usr/lib/python3/dist-packages/globaleaks/utils/letsencrypt.py", line 85, in request_new_certificate
    csr = crypto_util.make_csr(key, [hostname], False)

  File "/usr/lib/python3/dist-packages/acme/crypto_util.py", line 293, in make_csr
    private_key = serialization.load_pem_private_key(private_key_pem, password=None)

TypeError: argument 'data': from_buffer() cannot return the address of a unicode object

I’m using the latest Docker image from globaleaks/globaleaks version 5.0.83, running inside a Kubernetes cluster.

What I’ve tried so far

• Restarted the container
• Confirmed that the domain is reachable on ports 80 and 443 (Kubernetes internally maps these to ports 8080 and 8443 on the container)
• Followed the procedure described here to delete and reissue the certificates:
  https://docs.opensource-hinweisgeberportal.de/globaleaks/admin/network/https-certificates/

The issue occurs every time immediately when the certificate issuance process starts. I wasn’t able to reproduce the issue on try.globaleaks.org, since certificate handling works differently there.

Questions

• Can anyone else reproduce this issue?
• Has this bug been fixed in version 5.0.84? I couldn’t find any related note in the changelog.

Any insights or confirmations would be much appreciated.
Thanks a lot for your great work on this project!

[evilaliv3]

Thank you for your question @maltekiessling

This is not a known bug and no changes has been made on this matter in any of the minor releases of release 5.

are you getting this same exception if you reset the https configuration and you restart the automatic procedure?

[maltekiessling]

Yes, I’ve tried resetting the HTTPS configuration several times and also deleting the generated private key before restarting the automatic procedure, but I always get the same error message.

While reviewing the logs and emails again, I also found another error message that appeared at some point during my earlier attempts, although I can’t retrace exactly during which step it occurred:

Platform: ***
Host: *** (***.onion)
Version: 5.0.83

AttributeError Attribute not found.

Traceback (most recent call last):

  File "/usr/lib/python3/dist-packages/twisted/internet/_producer_helpers.py", line 67, in _pull
    self._producer.resumeProducing()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^

  File "/usr/lib/python3/dist-packages/twisted/protocols/basic.py", line 895, in resumeProducing
    self.consumer.unregisterProducer()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^

  File "/usr/lib/python3/dist-packages/twisted/web/http.py", line 1135, in unregisterProducer
    self.channel.unregisterProducer()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

AttributeError: 'NoneType' object has no attribute 'unregisterProducer'

Let me know if I can provide any additional logs or details that might help debugging this.

[evilaliv3]

Thank you. This exception is actually not related.

[karlludwigweise]

I can reproduce this on a non-k8s setup in v5.0.83.

[evilaliv3]

Thank you @karlludwigweise

Which debian/ubuntu version are you user @karlludwigweise @maltekiessling ?

[maltekiessling]

@evilaliv3

I’m using the latest official Docker image globaleaks/globaleaks:v5.0.83, which is based on Debian GNU/Linux 13 (Trixie).

$ cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.1
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[evilaliv3]

Thank you @maltekiessling

Will check if the issue reproduce on our side as well and get back to you. We might have not noticed since in production we had still to update to trixie.

[karlludwigweise]

Same here. Using the official docker image.

[evilaliv3]

Thank you both @maltekiessling and @karlludwigweise.

I've verified and a small defects exist since there has been some changes in the libraries that we use for letsencrypt.
I've opened a dedicated ticket where to deal with the bugfixing: #4657

[maltekiessling]

Thank you, @evilaliv3!
With the release of v5.0.85, everything is now working perfectly.

[evilaliv3]

super, thank you for your confirmation!

[karlludwigweise]

I can also confirm that the auto-renewal worked!