Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
Am 01.08.19 um 19:36 schrieb Gerald Turner: > On Thu, Aug 01 2019, Philipp Huebner wrote: >> your issue was fixed upstream, could you please try >> https://apt.debalance.de/pool/main/e/erlang-p1-pkix/erlang-p1-pkix_1.0.0-3+deb10u1_amd64.deb >> >> and report back if this solves your problem? > > Awesome! Problem solved. My temporary OpenSSL-signed certificate has > now been thrown out, yay! Thank you for your help, I have now opened https://bugs.debian.org/933769 to get this fixed for Buster. Best wishes -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
On Thu, Aug 01 2019, Philipp Huebner wrote: > your issue was fixed upstream, could you please try > https://apt.debalance.de/pool/main/e/erlang-p1-pkix/erlang-p1-pkix_1.0.0-3+deb10u1_amd64.deb > > and report back if this solves your problem? Awesome! Problem solved. My temporary OpenSSL-signed certificate has now been thrown out, yay! -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
Hi Gerald, your issue was fixed upstream, could you please try https://apt.debalance.de/pool/main/e/erlang-p1-pkix/erlang-p1-pkix_1.0.0-3+deb10u1_amd64.deb and report back if this solves your problem? Thanks! Best wishes -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
> 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? The certificate handling is done by the erlang-p1-pkix package. You can try updating both if you like. signature.asc Description: OpenPGP digital signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
Hi again! Am 26.07.19 um 20:17 schrieb Gerald Turner: > On Fri, Jul 26 2019, Philipp Huebner wrote: > >> 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? Yes they did, probably to be able to debug a running ejabberd. > 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: [...] Thx again, that's very helpful! > Thanks. I do not have a GH account and would appreciate this very much. Done: https://github.com/processone/pkix/issues/2 Best wishes -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
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 Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D -BEGIN CERTIFICATE- MIIJxDCCBaygAwIBAgIBADANBgkqhkiG9w0BAQsFADA6MSYwJAYDVQQDEx1Qcml2 YXRlIENlcnRpZmljYXRlIEF1dGhvcml0eTEQMA4GA1UEChMHRXhhbXBsZTAeFw0x NDA0MDcxNzI3MDBaFw0zODAxMTkwMzE0MDdaMDoxJjAkBgNVBAMTHVByaXZhdGUg Q2VydGlmaWNhdGUgQXV0aG9yaXR5MRAwDgYDVQQKEwdFeGFtcGxlMIIEIjANBgkq hkiG9w0BAQEFAAOCBA8AMIIECgKCBAEA4lsl67c6lIsHKJ+KK+w5FgmGy1Hf5VVp Yx/RWfJPz8pCzdEiiDKB/KWqbQcwHrcSlzhEMQEDcC9fJDwnvWEtiQejg+qq8qIh /XWLNP95Jm9tqudgPphGI0nHwbAokk6famVDLJtntAvFfhBAjgXICjExhPSSwhSS LjLIw5DCl0sm/l6hpn4eB6SUMOZDsRcrOmTWqjjVpMbVGdc1EqudQx/rd4NPmorE a4qW71LEHRwwoKv1mpWd7l4ZThl6plg3QSS+CfwtdHfiJ2fnhQo10m7WH0Ju9QKr wmJtbeBGcoXMK0Fzo8jfcLRpvg6zhu6vh5Y2gi9MtEzHNxxPGddPnWEm4ggE0rWD 6JX2P9b6X3ephb9rAiMOSEyR6jQhIbNVLQojh2EYHVkZM/fI0noU2NtO2MaH2ggB 15wCzn2DBaA2xy7M0phvF5wWiOHyiBnIsA2PFMDD+U73nU7oARqRD1AYMqrWH3cG LGck1RP9I2DUJgToJBzSz7ovHhj11TRPe2bayC6H3wkuEl39Klx3hI81dQdmKBZn
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
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). 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. 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. FWIW, upstream also suspects this to be a bug in Erlang itself rather than ejabberd, hence I'm CCing the Erlang maintainer(s). Best wishes -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd
Package: ejabberd Version: 18.12.1-2 Severity: normal Dear Maintainer, I have been running a Debian ejabberd server since Debian squeeze and every dist-upgrade since. In 2014 I setup a private CA using GnuTLS and had configured ejabberd (version 2.1.5 at the time) to use these certificates. Subsequent upgrades through wheezy, jessie, and stretch, these certificates continued to work, until buster... 2019-07-21 17:02:14.904 [warning] <0.406.0>@ejabberd_pkix:log_warnings:397 Invalid certificate in /etc/ssl/certs/unzane/nyarlathotep-rsa-cert.pem: at line 1: certificate was not signed by its issuer certificate This message isn't true - if I inspect the certificates using GnuTLS certtool or OpenSSL x509 tools, the CA signatures are in place. Furthermore these same certificate files are used by apache2, which had no trouble with the buster upgrade. Additionally, when I use OpenSSL's s_client tool and compare output between port 443 (apache2) and 5223 (ejabberd), they both present the full chain of trust (root CA, intermediate CA, and host certificates), however ejabberd does something wicked with the host certificate fingerprint - it's been recomputed to some random value (doesn't match the PEM file). After a few days of frustration and every imaginable tweak to ejabberd.yml, I decided to experiment with re-issuing a certificate using OpenSSL tools. This worked, however I cannot commit to using this experimental process until I abandon my private CA setup. Attached is a shell script which runs GnuTLS certtool to create a root CA, intermediate CA, and host certificates in a manner closely resembling the certificates I had been using since 2014. The script depends on four template files, and there is also a log attached showing what running it looks like (including certificate info dumps). The resulting certificates can be added to ejabberd.yml and exhibit the broken signature behavior: certfiles: - "/etc/ejabberd/ejabberd-cert.pem" - "/etc/ejabberd/ejabberd-key.pem" - "/etc/ejabberd/private-int-cert.pem" - "/etc/ejabberd/private-ca-cert.pem" Then run a command like OpenSSL's s_client and see the signature error: $ openssl s_client \ -CAfile private-ca-cert.pem \ -connect ejabberd.example.com:5223 \ -showcerts < /dev/null ... Verify return code: 7 (certificate signature failure) ... Furthermore the fingerprint seen on the wire is different than what is in the ejabberd-cert.pem file. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (701, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-cloud-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ejabberd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii erlang-asn11:21.2.6+dfsg-1 ii erlang-base [erlang-abi-17.0] 1:21.2.6+dfsg-1 ii erlang-base64url 1.0-3 ii erlang-crypto 1:21.2.6+dfsg-1 ii erlang-goldrush0.2.0-1 ii erlang-inets 1:21.2.6+dfsg-1 ii erlang-jiffy 0.14.11+dfsg-4 ii erlang-jose1.9.0-1 ii erlang-lager 3.6.8-1 ii erlang-mnesia 1:21.2.6+dfsg-1 ii erlang-odbc1:21.2.6+dfsg-1 ii erlang-os-mon 1:21.2.6+dfsg-1 ii erlang-p1-cache-tab1.0.17-1 ii erlang-p1-eimp 1.0.9-1 ii erlang-p1-iconv1.0.10-1 ii erlang-p1-pkix 1.0.0-3 ii erlang-p1-stringprep 1.0.14-1 ii erlang-p1-tls 1.0.26-1 ii erlang-p1-utils1.0.13-1 ii erlang-p1-xml 1.1.34-1 ii erlang-p1-xmpp 1.2.8-1 ii erlang-p1-yaml 1.0.17-1 ii erlang-p1-zlib 1.0.4-3 ii erlang-public-key 1:21.2.6+dfsg-1 ii erlang-ssl 1:21.2.6+dfsg-1 ii erlang-syntax-tools1:21.2.6+dfsg-1 ii erlang-xmerl 1:21.2.6+dfsg-1 ii lsb-base 10.2019051400 ii openssl1.1.1c-1 ii ucf3.0038+nmu1 ejabberd recommends no packages. Versions of packages ejabberd suggests: ii apparmor 2.13.2-10 ii apparmor-utils 2.13.2-10 ii ejabberd-contrib 0.2018.12.10~dfsg0-3 pn erlang-luerl ii erlang-p1-mysql 1.0.8-1 pn erlang-p1-oauth2 ii erlang-p1-pam1.0.4-3 ii erlang-p1-pgsql 1.1.6-2 ii erlang-p1-sip1.0.27-1 pn erlang-p1-sqlite3 ii erlang-p1-stun 1.0.26-1 pn erlang-redis-client
