[Pkg-erlang-devel] Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd

[Gerald Turner]

On Fri, Jul 26 2019, Philipp Huebner wrote:
> Hi,
>
> thank you very much for this detailed bugreport!
>
> I have contacted upstream, and they requested sample certificates
> (PEMs) for ejabberd (cert+key) and CA (without key).

Great!  Did they really want the host key PEM file?  Otherwise I'd send
the real-world certificates I'm using.  Instead I've attached all of the
fictitious certificates and keys generated with the script from the
previous mail (four files: root CA cert, intermediate CA cert, and host
cert and key).

On a random machine running Debian buster that hadn't been running
ejabberd before, I've been able to reproduce this bug with the following
steps:

  1. apt install ejabberd (debconf questions won't matter).

  2. Copy the four attached certs/keys to /etc/ejabberd.

  3. Edit ejabberd.yml with:

       hosts:
         - "jabber.example.com"

       certfiles:
          - "/etc/ejabberd/ejabberd-cert.pem"
          - "/etc/ejabberd/ejabberd-key.pem"
          - "/etc/ejabberd/private-int-cert.pem"
          - "/etc/ejabberd/private-ca-cert.pem"

   4. systemctl restart ejabberd

   5. Examine output of the following commands:

        gnutls-cli -V \
          --x509cafile=/etc/ejabberd/private-ca-cert.pem \
          --verify-hostname=jabber.example.com \
          -p 5223 \
          localhost:5223 < /dev/null

       certtool --certificate-info \
         --load-certificate /etc/ejabberd/ejabberd-cert.pem

The gnutls-cli command reports:

  Status: The certificate is NOT trusted. The signature in the
  certificate is invalid.

Earlier in the gnutls-cli output is the signature received on the wire:

  sha1:647fe53a3b279f605d2ec7a572c54724f0765285

The certtool command shows a different signature:

  sha1:9789b39f3b5bde6a8c5b7dd2c11c25c901199edf

So somehow ejabberd is recomputing the signature when it should match
what's in the PEM file verbatim.

> I tried running your script on Buster, but it fails:
> $ ./gen
> Password: test
> Generating private-int-key.pem...
> Assuming PKCS #8 format...
> ** Note: You may use '--sec-param High' instead of '--bits 4096'
> Generating a 4096 bit RSA private key...
> Generating private-int-req.pem...
> Generating a PKCS #10 certificate request...
> Generating private-int-cert.pem
> Generating a signed certificate...
> error importing CA certificate: public/private-ca-cert.pem: Base64
> unexpected header error.

Oops!  I see, I tried this again on buster too.  The newer version of
certtool seems to require that serial numbers are not zero (change
"serial = 1" in private-ca.template, and change "crl_number = 1" in
private-ca-crl.template).  Another problem with the script is that if a
certtool command fails, it still touches a file with zero bytes, so the
next run doesn't retry generation (i.e. just "rm -rf private public", or
rm the specific zero byte PEM file, and try again).

> With sample PEMs I'll forward this to an issue at
> https://github.com/processone/pkix, you're welcome to do it yourself
> if you like.

Thanks.  I do not have a GH account and would appreciate this very much.

> FWIW, upstream also suspects this to be a bug in Erlang itself rather
> than ejabberd, hence I'm CCing the Erlang maintainer(s).

Interesting.

The following is a bit of an anecdote (TL;DR I'm willing to rebuild
newer versions and test if that'll help): while chasing down another
problem (Debian BTS #933042, after having resorted to using a temporary
OpenSSL signed cert, bypassing this bug, and then could not get ejabberd
to accept TLSv1.0 client connections), I happened to notice that the
erlang-p1-tls repository on salsa had already been prepared for the
latest release (which has some commits mentioning more OpenSSL wrapper
code has moved into the C binding).  I built erlang-p1-tls 1.1.1 but
didn't have any luck with the issue at hand, so I reverted to the buster
released versions.  Perhaps it's worth another try with the newer
erlang-p1-tls package and looking at this certificate issue?

-- 
Gerald Turner <gturner at unzane.com>        Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: private-ca-cert.pem
URL: <http://alioth-lists.debian.net/pipermail/pkg-erlang-devel/attachments/20190726/6624aaa6/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: private-int-cert.pem
URL: <http://alioth-lists.debian.net/pipermail/pkg-erlang-devel/attachments/20190726/6624aaa6/attachment-0005.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ejabberd-cert.pem
URL: <http://alioth-lists.debian.net/pipermail/pkg-erlang-devel/attachments/20190726/6624aaa6/attachment-0006.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ejabberd-key.pem
URL: <http://alioth-lists.debian.net/pipermail/pkg-erlang-devel/attachments/20190726/6624aaa6/attachment-0007.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-erlang-devel/attachments/20190726/6624aaa6/attachment-0001.sig>