Willkommen im User-Forum von mailbox.org
Muss ich meinen öffentlichen Schlüssel selbst auf den neuen Keyserver hochladen
beantwortet
Enigmail findet meinen Schlüssel auf
hkps://pgp.mailbox.org
nicht.
Ich nutze den Guard, somit ist der Schlüssel bei Mailbox.org hinterlegt.
Muss ich den Schlüssel selbst hochladen oder braucht es einfach noch ein Wenig Zeit bis alle Schlüssel verfügbar sind?
Danke für die vielen neuen Funktionen :-)
Ich habe die gleiche Frage 
Wenn Sie den Guard nutzen, dann ist der dort hinterlegte Schlüssel auch auf dem Schlüsselserver zu finden.
Öffnen Sie in Thunderbird das Menü
Enigmail==>Schlüssel verwalten
und dort wiederum das Menü
Schlüsselserver==>Schlüssel suchen.
Geben Sie Ihre E-Mail Adresse ein und wählen Sie als Server:
hkps://pgp.mailbox.org
Wenn Sie den Guard nutzen, dann ist der dort hinterlegte Schlüssel auch auf dem Schlüsselserver zu finden.
Öffnen Sie in Thunderbird das Menü
Enigmail==>Schlüssel verwalten
und dort wiederum das Menü
Schlüsselserver==>Schlüssel suchen.
Geben Sie Ihre E-Mail Adresse ein und wählen Sie als Server:
hkps://pgp.mailbox.org
Habe ein ähnliches Problem. Auch die beschriebene Lösung scheitert.
EDIT: die Fehlermeldung von Enigmail ist folgende:
Leider konnte kein passender Schlüssel zu den angegebenen Suchkriterien gefunden werden. Beachten Sie, dass Schlüssel-IDs mit „0x“ beginnen müssen (z.B. 0xABCDEF12).
Habe ein ähnliches Problem. Auch die beschriebene Lösung scheitert.
EDIT: die Fehlermeldung von Enigmail ist folgende:
Leider konnte kein passender Schlüssel zu den angegebenen Suchkriterien gefunden werden. Beachten Sie, dass Schlüssel-IDs mit „0x“ beginnen müssen (z.B. 0xABCDEF12).
Wir konnten das Problem lösen.
Enigmail unterdrückt leider die vollständige Fehlermeldung: "Timeout.... usw." Dadurch entstand bei Ihnen der falsche Eindruck, dass die Keys nicht gefunden wurden. Die Keys stehen aber (wie oben vermutet) mit der Einrichtung des Guard auch auf unserem Keyserver bereit.
Jetzt sollte es problemlos ohne Timeouts funktionieren.
Wir konnten das Problem lösen.
Enigmail unterdrückt leider die vollständige Fehlermeldung: "Timeout.... usw." Dadurch entstand bei Ihnen der falsche Eindruck, dass die Keys nicht gefunden wurden. Die Keys stehen aber (wie oben vermutet) mit der Einrichtung des Guard auch auf unserem Keyserver bereit.
Jetzt sollte es problemlos ohne Timeouts funktionieren.
Geht hier immer noch nicht, gleiche Fehlermeldung.
Ich bin - auch wegen anderer Problemchen - mittlerweile schwer genervt...
Geht hier immer noch nicht, gleiche Fehlermeldung.
Ich bin - auch wegen anderer Problemchen - mittlerweile schwer genervt...
Ich habe übrigens dasselbe Problem. Zugriff auf Keyserver via PGPTools (Mac) und Thunderbird via Enigmail (Ubuntu 16.04) nicht möglich. Ich verwende in beiden Fällen als gpg.conf-File die Implementierung von riseup.net ( https://help.riseup.net/de/security/message-security/openpgp/gpg-best-practices ).
Bei dem Werkzeug GPGTools (Mac) könnte es sein, dass ein Zugriff via hkps gar nicht möglich ist, dies versuche ich mit dem dortigen Support zu klären...
Ich habe übrigens dasselbe Problem. Zugriff auf Keyserver via PGPTools (Mac) und Thunderbird via Enigmail (Ubuntu 16.04) nicht möglich. Ich verwende in beiden Fällen als gpg.conf-File die Implementierung von riseup.net ( https://help.riseup.net/de/security/message-security/openpgp/gpg-best-practices ).
Bei dem Werkzeug GPGTools (Mac) könnte es sein, dass ein Zugriff via hkps gar nicht möglich ist, dies versuche ich mit dem dortigen Support zu klären...
Wir konnten das Problem etwas eingrenzen, es ist ein Bug in dem neuen Entwicklerzweig GnuPG Version 2.1.x und betrifft alle HKPS Keyserver
Die aktuelle GnuPG "stable" Version 2.0.30 funktioniert stabil mit unserem HKPS-Server und ist von diesem Bug nicht betroffen. Bisher kann ich nur empfehlen, sie "stable" Version von GnuPG zu installieren: https://www.gnupg.org/
GPG4WIN soll laut Doku die Version 2.0.30 von GnuPG enthalten. Muss also noch ein Problem sein. Schwierig.
Wir konnten das Problem etwas eingrenzen, es ist ein Bug in dem neuen Entwicklerzweig GnuPG Version 2.1.x und betrifft alle HKPS Keyserver
Die aktuelle GnuPG "stable" Version 2.0.30 funktioniert stabil mit unserem HKPS-Server und ist von diesem Bug nicht betroffen. Bisher kann ich nur empfehlen, sie "stable" Version von GnuPG zu installieren: https://www.gnupg.org/
GPG4WIN soll laut Doku die Version 2.0.30 von GnuPG enthalten. Muss also noch ein Problem sein. Schwierig.
Es muss noch einen weiteren Fehler geben, denn auch mit der oben genannten Befehlszeile ist der Key nicht zu finden. Ich frage mich, ob meiner überhaupt auf dem Server liegt.
Es muss noch einen weiteren Fehler geben, denn auch mit der oben genannten Befehlszeile ist der Key nicht zu finden. Ich frage mich, ob meiner überhaupt auf dem Server liegt.
könntet ihr nicht eine Test Mailadresse mit PGP Key bereitstellen/bekanntgeben, über die der Abruf vom Keyserver getestet werden kann?
So könnte man zumindest schon mal alle Clientseitigen Probleme ausschließen :)
könntet ihr nicht eine Test Mailadresse mit PGP Key bereitstellen/bekanntgeben, über die der Abruf vom Keyserver getestet werden kann?
So könnte man zumindest schon mal alle Clientseitigen Probleme ausschließen :)
Ich glaube, ich habe das Problem gefunden.
In Abhängigkeit von der verwendeten SSL-Lib nutzen einige Versionen von GnuPG die CA-Root Zertifikate des Betriebssystems nicht und können deshalb das SSL-Zertifikat unseres HKPS-Servers nicht verifizieren. Neben GPG4WIN betrifft es GnuPG unter Unbuntu 16.04. MAn erhält aber nur eine nichtssagende Fehlermeldung.
Ich schreibe morgen früh eine Erweiterung zur FAQ, was man tun muss, um das Problem zu lösen, heute Abend ist es schon spät.
Ich glaube, ich habe das Problem gefunden.
In Abhängigkeit von der verwendeten SSL-Lib nutzen einige Versionen von GnuPG die CA-Root Zertifikate des Betriebssystems nicht und können deshalb das SSL-Zertifikat unseres HKPS-Servers nicht verifizieren. Neben GPG4WIN betrifft es GnuPG unter Unbuntu 16.04. MAn erhält aber nur eine nichtssagende Fehlermeldung.
Ich schreibe morgen früh eine Erweiterung zur FAQ, was man tun muss, um das Problem zu lösen, heute Abend ist es schon spät.
Ich habe die Schritte im FAQ abgearbeitet, aber es bleibt beim "Allgemeinen Fehler"...
Ich habe die Schritte im FAQ abgearbeitet, aber es bleibt beim "Allgemeinen Fehler"...
Ich würde diesen Thread gerne einmal aufwärmen. Läuft der Keyserver bei jemandem zuverlässig mit gpg4win oder xubuntu 16.04?
Bei mir werden die Schlüssel einfach nicht gefunden.
gpg: suche nach "support@mailbox.org" auf hkps-Server pgp.mailbox.org
gpg: Schlüssel "support@mailbox.org" wurde auf dem Schlüsselserver nicht gefunden
Dabei ist es egal, ob ich das Zertifikat, wie in den FAQs beschrieben, in der gpg.conf angebe oder nicht. Es macht kein Unterschied. Auch gpg4win 3.0 beta funktioniert nicht. Gibt es noch einen anderen Trick?
Viele Grüße und vielen Dank im voraus
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.4)
libgcrypt 1.7.8
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: C:/Users/Jan/AppData/Roaming/gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, RSA, RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
Ich würde diesen Thread gerne einmal aufwärmen. Läuft der Keyserver bei jemandem zuverlässig mit gpg4win oder xubuntu 16.04?
Bei mir werden die Schlüssel einfach nicht gefunden.
gpg: suche nach "support@mailbox.org" auf hkps-Server pgp.mailbox.org
gpg: Schlüssel "support@mailbox.org" wurde auf dem Schlüsselserver nicht gefunden
Dabei ist es egal, ob ich das Zertifikat, wie in den FAQs beschrieben, in der gpg.conf angebe oder nicht. Es macht kein Unterschied. Auch gpg4win 3.0 beta funktioniert nicht. Gibt es noch einen anderen Trick?
Viele Grüße und vielen Dank im voraus
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.4)
libgcrypt 1.7.8
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: C:/Users/Jan/AppData/Roaming/gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, RSA, RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
Unter Windoof mit gpg4win geht es bei mir auch nicht. Fehler: TLSv1.2 Handshake Failure. Unter FreeBSD, NetBSD und Linux (Fedora 26 und Debian 8/9) gibt es keine Probleme.
Unter Windoof mit gpg4win geht es bei mir auch nicht. Fehler: TLSv1.2 Handshake Failure. Unter FreeBSD, NetBSD und Linux (Fedora 26 und Debian 8/9) gibt es keine Probleme.
Vielleicht ist die GnuTLS Version zu alt?
gpgkeys_hkp (GnuPG) 2.0.30
Uses: libcurl/7.54.1 GnuTLS/2.12.23 zlib/1.2.11
Vielleicht ist die GnuTLS Version zu alt?
gpgkeys_hkp (GnuPG) 2.0.30
Uses: libcurl/7.54.1 GnuTLS/2.12.23 zlib/1.2.11
Vielleicht... Aber auch mit gpg4win 3.00 funktioniert es nicht und dort wird eine deutlich neuere GnuPG (2.20) und libgcrypt-Version (1.8.1) benutzt (dirmngr 2.2.0).
Ich hab es nun aber unter xubuntu 16.04 zum laufen bekommen. Aber lediglich mit der gnupg-Version 1.4.20...
Mit welcher Version geht es denn unter *BSD? Kommt der mailbox.org Keyserver vielleicht einfach nicht mit den neuen Versionen klar?
Vielleicht... Aber auch mit gpg4win 3.00 funktioniert es nicht und dort wird eine deutlich neuere GnuPG (2.20) und libgcrypt-Version (1.8.1) benutzt (dirmngr 2.2.0).
Ich hab es nun aber unter xubuntu 16.04 zum laufen bekommen. Aber lediglich mit der gnupg-Version 1.4.20...
Mit welcher Version geht es denn unter *BSD? Kommt der mailbox.org Keyserver vielleicht einfach nicht mit den neuen Versionen klar?
FreeBSD:
gpg (GnuPG) 2.1.23/libgcrypt 1.8.1 und
gpg (GnuPG) 2.2.0/libgcrypt 1.8.1
Linux(Fedora 26):
gpg (GnuPG) 2.2.0/libgcrypt 1.7.8
Was ist der Output von '/usr/libexec/gnupg/gpgkeys_hkp --version' unter (x)Ubuntu? Die Curl Version ist sicher nicht gegen eine uralt GNUTLS Version gelinkt. Unter Centos 6.9 kommt zwar auch noch GnuTLS 2.12.23 zum Einsatz, aber diese Version dürfte die Patches von GnuTLS 2.12.24 enthalten, in der der TLS 1.2 Support verbessert wurde. Der Keyserver von Mailbox unterstützt nur TLSv1.2.
FreeBSD:
gpg (GnuPG) 2.1.23/libgcrypt 1.8.1 und
gpg (GnuPG) 2.2.0/libgcrypt 1.8.1
Linux(Fedora 26):
gpg (GnuPG) 2.2.0/libgcrypt 1.7.8
Was ist der Output von '/usr/libexec/gnupg/gpgkeys_hkp --version' unter (x)Ubuntu? Die Curl Version ist sicher nicht gegen eine uralt GNUTLS Version gelinkt. Unter Centos 6.9 kommt zwar auch noch GnuTLS 2.12.23 zum Einsatz, aber diese Version dürfte die Patches von GnuTLS 2.12.24 enthalten, in der der TLS 1.2 Support verbessert wurde. Der Keyserver von Mailbox unterstützt nur TLSv1.2.
oh stimmt. Die Curl Version ist gegen GnuTLS 3.4.10 verlinkt.
gpgkeys_hkp (GnuPG) 1.4.20
Uses: libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Wie finde ich bei GnuPG2 raus, welche GnuTLS-Version genutzt wird?
oh stimmt. Die Curl Version ist gegen GnuTLS 3.4.10 verlinkt.
gpgkeys_hkp (GnuPG) 1.4.20
Uses: libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Wie finde ich bei GnuPG2 raus, welche GnuTLS-Version genutzt wird?
ldd `which dirmngr` |grep gnutls und dann mit dem Paketmanager nachschauen.
ldd `which dirmngr` |grep gnutls und dann mit dem Paketmanager nachschauen.
GnuPG2 ist auch gegen GnuTLS 3.4.10 gelinked (Version: 3.4.10-4ubuntu1). Von daher kann die GnuTLS-Version leider nicht alleinig ausschlaggebend sein. Schade... Vielleicht wäre das aber auch einfach ein Fall für den GnuPG/gpg4win-Bugtracker.
Vielen Dank für deine bisherige Mühe!
GnuPG2 ist auch gegen GnuTLS 3.4.10 gelinked (Version: 3.4.10-4ubuntu1). Von daher kann die GnuTLS-Version leider nicht alleinig ausschlaggebend sein. Schade... Vielleicht wäre das aber auch einfach ein Fall für den GnuPG/gpg4win-Bugtracker.
Vielen Dank für deine bisherige Mühe!
Welchen Fehler bekommst Du denn, wenn du den gpg2 Befehl mit '--debug-all' aufrufst?
Welchen Fehler bekommst Du denn, wenn du den gpg2 Befehl mit '--debug-all' aufrufst?
Offenbar ist gnutls 3.4.10 auch nicht kompatibel! 'gnutls-cli-debug' kommt zum Ergebnis, dass der Server kein SSL 3.0, TLS 1.0, TLS 1.1 und TLS 1.2 unterstützt, was natürlich Quatsch ist, da ja zumindest TLS 1.2 angeboten wird.
GnuTLS debug client 3.4.10
Checking pgp.mailbox.org:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes
whether we need to disable TLS 1.0... yes
whether %NO_EXTENSIONS is required... yes
whether %COMPAT is required... yes
for TLS 1.0 (RFC2246) support...
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2
Mit gnutls 3.5.13 (unter FreeBSD) sieht das so aus:
% gnutls-cli-debug pgp.mailbox.org
GnuTLS debug client 3.5.13
Checking pgp.mailbox.org:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... no
whether we need to disable TLS 1.1... no
whether we need to disable TLS 1.0... no
whether %NO_EXTENSIONS is required... no
whether %COMPAT is required... yes
for TLS 1.0 (RFC2246) support... no
for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
for TLS 1.1 (RFC4346) support... no
fallback from TLS 1.1 to... failed
for TLS 1.2 (RFC5246) support... yes
[...]
Offenbar ist gnutls 3.4.10 auch nicht kompatibel! 'gnutls-cli-debug' kommt zum Ergebnis, dass der Server kein SSL 3.0, TLS 1.0, TLS 1.1 und TLS 1.2 unterstützt, was natürlich Quatsch ist, da ja zumindest TLS 1.2 angeboten wird.
GnuTLS debug client 3.4.10
Checking pgp.mailbox.org:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes
whether we need to disable TLS 1.0... yes
whether %NO_EXTENSIONS is required... yes
whether %COMPAT is required... yes
for TLS 1.0 (RFC2246) support...
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2
Mit gnutls 3.5.13 (unter FreeBSD) sieht das so aus:
% gnutls-cli-debug pgp.mailbox.org
GnuTLS debug client 3.5.13
Checking pgp.mailbox.org:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... no
whether we need to disable TLS 1.1... no
whether we need to disable TLS 1.0... no
whether %NO_EXTENSIONS is required... no
whether %COMPAT is required... yes
for TLS 1.0 (RFC2246) support... no
for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
for TLS 1.1 (RFC4346) support... no
fallback from TLS 1.1 to... failed
for TLS 1.2 (RFC5246) support... yes
[...]
Hmm, bei Debian 8.9 ist noch 3.3.8 und gnupg 2.0.26 enthalten... gnutls-cli schlägt fehl, die Suche nach dem Schlüssel funktioniert mit GPG2 aber.
Hmm, bei Debian 8.9 ist noch 3.3.8 und gnupg 2.0.26 enthalten... gnutls-cli schlägt fehl, die Suche nach dem Schlüssel funktioniert mit GPG2 aber.
sehr komisch. Auf xubuntu 16.04 funktioniert es ja auch mit gpg1 obwohl es gegen die selbe gnutls-Version gelinked ist und auch dort gnutls-cli fehlschlägt. Ich denke ich wende mich mal direkt an GnuPG oder gpg4win.
Aber danke auf jeden Fall!
sehr komisch. Auf xubuntu 16.04 funktioniert es ja auch mit gpg1 obwohl es gegen die selbe gnutls-Version gelinked ist und auch dort gnutls-cli fehlschlägt. Ich denke ich wende mich mal direkt an GnuPG oder gpg4win.
Aber danke auf jeden Fall!
OMG. Die Lösung in <https://support.mailbox.org/knowledge-base/article/der-mailbox-org-hkps-keyserver>; funktioniert doch bei mir (Testsystem xubuntu 16.04): Swiss Sign Zertifikat runterladen und hkp-cacert Eintrag in ~/.gnupg/dirmngr.conf einfügen. :-)
OMG. Die Lösung in <https://support.mailbox.org/knowledge-base/article/der-mailbox-org-hkps-keyserver>; funktioniert doch bei mir (Testsystem xubuntu 16.04): Swiss Sign Zertifikat runterladen und hkp-cacert Eintrag in ~/.gnupg/dirmngr.conf einfügen. :-)
Ich habe es gerade noch einmal ausprobiert. Es funktioniert definitiv nicht. Weder mit dem SwissSign-Zertifikat unter /etc/ssl noch mit dem in der Wissendatenbank von mailbox.org (sollten ja hoffentlich gleich sein :) )
gpg: reading options from '/home/jschmidt/.gnupg/gpg.conf'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/jschmidt/.gnupg
gpg: DBG: chan_3 <- # Config: /home/jschmidt/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: chan_4 <- # Home: /home/jschmidt/.gnupg
gpg: DBG: chan_4 <- # Config: /home/jschmidt/.gnupg/dirmngr.conf
gpg: DBG: chan_4 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_4 -> GETINFO version
gpg: DBG: chan_4 <- D 2.1.11
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER --clear hkps://pgp.mailbox.org
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KS_SEARCH -- support@mailbox.org
gpg: DBG: chan_4 <- ERR 1 General error <Unspecified source>
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error
gpg: DBG: chan_4 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/65536 bytes in 0 blocks
Ubuntu-Version:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
und ~/.gnupg/dirmngr.conf
hkp-cacert /home/jschmidt/.gnupg/SwissSign_Silver_CA_-_G2.pem
Ich habe es gerade noch einmal ausprobiert. Es funktioniert definitiv nicht. Weder mit dem SwissSign-Zertifikat unter /etc/ssl noch mit dem in der Wissendatenbank von mailbox.org (sollten ja hoffentlich gleich sein :) )
gpg: reading options from '/home/jschmidt/.gnupg/gpg.conf'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/jschmidt/.gnupg
gpg: DBG: chan_3 <- # Config: /home/jschmidt/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: chan_4 <- # Home: /home/jschmidt/.gnupg
gpg: DBG: chan_4 <- # Config: /home/jschmidt/.gnupg/dirmngr.conf
gpg: DBG: chan_4 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_4 -> GETINFO version
gpg: DBG: chan_4 <- D 2.1.11
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER --clear hkps://pgp.mailbox.org
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KS_SEARCH -- support@mailbox.org
gpg: DBG: chan_4 <- ERR 1 General error <Unspecified source>
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error
gpg: DBG: chan_4 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/65536 bytes in 0 blocks
Ubuntu-Version:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
und ~/.gnupg/dirmngr.conf
hkp-cacert /home/jschmidt/.gnupg/SwissSign_Silver_CA_-_G2.pem
jetzt wird es noch verrückter... mit gpg2 funktioniert es nicht (siehe Post vorher). Mit dirmngr direkt geht es...
dirmngr[16086.0]: reading options from '/home/jschmidt/.gnupg/dirmngr.conf'
dirmngr[16086.0]: enabled debug flags: x509 crypto memory cache memstat hashing ipc lookup
dirmngr[16086.0]: error opening '/home/jschmidt/.gnupg/dirmngr_ldapservers.conf': No such file or directory
dirmngr[16086.0]: permanently loaded certificates: 0
dirmngr[16086.0]: runtime cached certificates: 0
dirmngr[16086.0]: DBG: chan_4 -> # Home: ~/.gnupg
# Home: ~/.gnupg
dirmngr[16086.0]: DBG: chan_4 -> # Config: /home/jschmidt/.gnupg/dirmngr.conf
# Config: /home/jschmidt/.gnupg/dirmngr.conf
dirmngr[16086.0]: DBG: chan_4 -> OK Dirmngr 2.1.11 at your service
OK Dirmngr 2.1.11 at your service
KEYSERVER --clear hkps://pgp.mailbox.org
dirmngr[16086.0]: DBG: chan_4 <- KEYSERVER --clear hkps://pgp.mailbox.org
dirmngr[16086.0]: DBG: chan_4 -> OK
OK
KS_SEARCH -- support@mailbox.org
dirmngr[16086.0]: DBG: chan_4 <- KS_SEARCH -- support@mailbox.org
dirmngr[16086.0]: resolve_dns_addr for 'pgp.mailbox.org': 'pgp.mailbox.org' [already known]
dirmngr[16086.0]: DBG: chan_4 -> S SOURCE https://pgp.mailbox.org:443
S SOURCE https://pgp.mailbox.org:443
dirmngr[16086.0]: DBG: chan_4 -> D info:1:1%0D%0A
D info:1:1%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> D pub:854f20b818a24864:1:4096:1392491184:1518721584:%0D%0A
D pub:854f20b818a24864:1:4096:1392491184:1518721584:%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> D uid:"mailbox.org Support-Team (mailbox.org Support-Team) <support@mailbox.org>":1392491184:1518721584:%0D%0A
D uid:"mailbox.org Support-Team (mailbox.org Support-Team) <support@mailbox.org>":1392491184:1518721584:%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> OK
OK
jetzt wird es noch verrückter... mit gpg2 funktioniert es nicht (siehe Post vorher). Mit dirmngr direkt geht es...
dirmngr[16086.0]: reading options from '/home/jschmidt/.gnupg/dirmngr.conf'
dirmngr[16086.0]: enabled debug flags: x509 crypto memory cache memstat hashing ipc lookup
dirmngr[16086.0]: error opening '/home/jschmidt/.gnupg/dirmngr_ldapservers.conf': No such file or directory
dirmngr[16086.0]: permanently loaded certificates: 0
dirmngr[16086.0]: runtime cached certificates: 0
dirmngr[16086.0]: DBG: chan_4 -> # Home: ~/.gnupg
# Home: ~/.gnupg
dirmngr[16086.0]: DBG: chan_4 -> # Config: /home/jschmidt/.gnupg/dirmngr.conf
# Config: /home/jschmidt/.gnupg/dirmngr.conf
dirmngr[16086.0]: DBG: chan_4 -> OK Dirmngr 2.1.11 at your service
OK Dirmngr 2.1.11 at your service
KEYSERVER --clear hkps://pgp.mailbox.org
dirmngr[16086.0]: DBG: chan_4 <- KEYSERVER --clear hkps://pgp.mailbox.org
dirmngr[16086.0]: DBG: chan_4 -> OK
OK
KS_SEARCH -- support@mailbox.org
dirmngr[16086.0]: DBG: chan_4 <- KS_SEARCH -- support@mailbox.org
dirmngr[16086.0]: resolve_dns_addr for 'pgp.mailbox.org': 'pgp.mailbox.org' [already known]
dirmngr[16086.0]: DBG: chan_4 -> S SOURCE https://pgp.mailbox.org:443
S SOURCE https://pgp.mailbox.org:443
dirmngr[16086.0]: DBG: chan_4 -> D info:1:1%0D%0A
D info:1:1%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> D pub:854f20b818a24864:1:4096:1392491184:1518721584:%0D%0A
D pub:854f20b818a24864:1:4096:1392491184:1518721584:%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> D uid:"mailbox.org Support-Team (mailbox.org Support-Team) <support@mailbox.org>":1392491184:1518721584:%0D%0A
D uid:"mailbox.org Support-Team (mailbox.org Support-Team) <support@mailbox.org>":1392491184:1518721584:%0D%0A
dirmngr[16086.0]: DBG: chan_4 -> OK
OK
Als Information an alle. Es gibt ein BugReport. Mehr dazu unter:
https://dev.gnupg.org/T3411
Als Information an alle. Es gibt ein BugReport. Mehr dazu unter:
https://dev.gnupg.org/T3411
So, das Problem wurde gelöst. gpg4win hat die elliptische Kurve nicht unterstützt und daher klappte der Handshake mit dem Mailbox.org Server nicht.
Mit Version 3.0.0 funktioniert es bei mir nun tadellos, sogar ohne Angabe des CA-Zertifikats!
Ich hoffe das hilft anderen hier im Forum ;)
So, das Problem wurde gelöst. gpg4win hat die elliptische Kurve nicht unterstützt und daher klappte der Handshake mit dem Mailbox.org Server nicht.
Mit Version 3.0.0 funktioniert es bei mir nun tadellos, sogar ohne Angabe des CA-Zertifikats!
Ich hoffe das hilft anderen hier im Forum ;)
Kommentare wurden auf dieser Seite deaktiviert! Bitte benutzen Sie für einzelne Themen auch separate Einträge, da wir diese dann einzeln mit einem Status versehen können. Ein Sammelthema ist unnötig unübersichtlich.