Willkommen im User-Forum von mailbox.org
 

Muss ich meinen öffentlichen Schlüssel selbst auf den neuen Keyserver hochladen

Ich weiß nichts hat dies geteilt, 3 Jahren her
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 :-)

Kommentare (49)

Foto
1

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

Foto
1

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).

Foto
1

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.

Foto
1

Geht hier immer noch nicht, gleiche Fehlermeldung.


Ich bin - auch wegen anderer Problemchen - mittlerweile schwer genervt...

Foto
1

Ich kann keine Probleme dabei feststellen, wenn ich Ihren Key (lt. Mail Adresse hier im Forum) abrufe:


> gpg2 --keyserver=hkps://pgp.mailbox.org --search <ihre-mail-addr>

gpg: suche nach <> auf hkps-Server pgp.mailbox.org

...

Keys 1-1 of 1 for ... found


Hmmm - verwenden Sie "gpg2"? Die alte Version "gpg" kann in der regel kein HKPS.


Haben Sie die vollständige Adresse des Keyservers eingeben mit der Protokollkennung am Anfang, also: "hkps://pgp.mailbox.org" (so wie es in der Anleitung steht) oder haben Sie nur den Server angegeben mit "pgp.mailbox.org"?

Foto
1

Können Sie auf der Komamndozeile testen? Was ist der Output?


> gpg2 --keyserver=hkps://pgp.mailbox.org --search <ihre-mail-addr>

Foto
1

gpg: suche nach "xxx@mailbox.org" auf hkps-Server pgp.mailbox.org

gpg: Schluessel "xxx@mailbox.org" wurde auf dem Schluesselserver nicht gefunden


Bei mir sind im Log noch Ports hinter hkps://pgp.mailbox.org eingetragen.


Aktuelles Enigmail mit aktuellen GPG4Win.

Foto
1

Ports? Hmmm - Standard-Port für HKPS-Protokoll ist 443 (wie HTTPS).

Das könnte man enforcen mit "hkps://pgp.mailbox.org:443"

Foto
1

Ich kann meinen im Guard verwendeten Schlüssel auch nicht auf hkps://pgp.mailbox.org finden; weder mit Enigmail in Thunderbird noch über die o.a. Kommandozeile.

Meldung: "Schlüssel wurde auf dem Schlüsselserver nicht gefunden."

Foto
1

Das ist verrückt, ich kann die alle hier genannten Schlüssel problemlos importieren, am Keyserver kann ich keine Probleme feststellen. Können Sie Ihre Konfigurationsdateien "gpg.conf" an den Support schicken, zusammen mit den Informationen zum Betriebssystem und GnuPG Version. Dann können wir es uns mal anschauen. Vielleicht macht GPG4WIN irgendwas besonderes?

Foto
1

Habe GPG4Win und Enigmail de- und reinstalliert - hilft nichts.


Wo finde ich die "gpg.conf"?

Foto
1

Bei mir (Windows 7 Prof.) liegt sie hier:

c:\Users\{user}\AppData\Roaming\gnupg\

Foto
1

In dem Verzeichnis liegt bei mir keine *.conf

Foto
1

Wenn das Programm auf C: installiert ist, dann Windows einfach mal nach "gpg.conf" suchen lassen.

Foto
Foto
1

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...

Foto
2

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.

Foto
1

Danke für die Info.

Kann ich irgendwie GnuPG direkt auf Windows installieren? Scheinbar macht GPGWin derzeit ja Probleme. Bei mir finde ich übrigens keine pgp.conf, wenn ich das aktuelle GPGWin (2.3.1) installiere, sondern nur eine gpg-conf.sekl

Foto
Foto
1

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.

Foto
2

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 :)

Foto
1

Test-Adresse: support@mailbox.org


> gpg2 --keyserver=hkps://pgp.mailbox.org --search support@mailbox.org

gpg: searching for "support@mailbox.org" from hkps server pgp.mailbox.org

(1) "mailbox.org Support-Team (mailbox.org Support-Team)

4096 bit RSA key 0x854F20B818A24864, created: 2014-02-15

Keys 1-1 of 1 for "support@mailbox.org". Enter number(s), N)ext, or Q)uit >

Foto
Foto
2

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.

Foto
1

Ich glaube ich habe auch ein Problem gefunden.

Ich nutze meine Hauptadresse nur zum Login und gebe sie nie heraus.

Der Schlüssel den ich für de Guard angegeben habe ist eigentlich einer anderen Adresse (die ich normal nutze) zugeordnet.

Suche ich nach meiner (geheimen) Loginadresse finde ich den Schlüssel auch.

Eigentlich finde ich das garnicht soooo gut da durch das Hochladen auf den Keyserver meine "geheime" Adresse quasi öffentlich wird, da dort beide Adressen verknüpft werden.


Suche ich auf dem Keyserver nach meiner nicht geheimen Adresse dann finde ich den Schlüssel nicht.

Foto
2

Der Guard wurde von den Entwicklern für die Arbeit mit der Haupt-Adresse konzipiert. Aus dieser Basis des Konzeptes ergeben sich einige Konsequenzen, die manchmal nicht trivial zu erkennen sind.


Der FAQ Artikel Guard mit Aliases nutzen erklärt übrigens, wie Sie das Problem vermeiden können, dass ihre (geheime) Login Adresse durch den PGP-Schlüssel bekannt wird.

Foto
1

Super, danke für die schnelle Antwort. Ich habe es gerade genau nach der Anleitung eingerichtet.

Und es hat geklappt. Meine Loginadresse taucht nicht mehr als Identität des Schlüssels auf.


Nur noch eine kurze Frage:

Wird der Schlüssel auf dem Keyserver (mit der Verknüpfung der Loginadresse) durch den aktuellen Schlüssel ersetzt, so das meine geheime Adresse wieder vom Keyserver entfernt wird?


Es ist der gleiche Schlüssel (die selbe Schlüssel ID). Ich habe ihn nur erneut hochgeladen nachdem ich temporär die Hauptadresse geändert habe.

Foto
1

Super, bin schon auf die Info morgen bzgl. SSL-Lib gespannt!!!


Ich hab auch auf meinem Mac mit GPGTools nochmals etwas rumprobiert. Die bestehende gpg.conf hab ich gelöscht und durch das Tool selbst via Neustart einfach eine neue gpg.conf erstellen lassen. Dann hab ich die Settings in der GUI neu gesetzt und eine Suche im GPG Keychain nach meinem Schlüssel durchgeführt.


Ergebnis ... ich bekomme wenigstens keine Fehlermeldung mehr, finde jedoch meinen eigenen Schlüssel immer noch nicht. Suche ich jedoch nach dem Schlüssel für support@mailbox.org, finde ich diesen und kann ihn importieren. Seehr komisch. Es scheint nun zu klappen, jedoch nicht mit meinem eigenen Key...


Vielen Dank für die neuen Funktionen und eure Mühe - Daumen hoch!!!

Foto
1

Gibt es die aktualisierte FAQ schon, um die SSL-Zertifikate richtig importieren zu können?

Foto
1

Hallo,

hier gibt es die aktualisierte FAQ:

https://support.mailbox.org/knowledge-base/article/der-mailbox-org-hkps-keyserver

Nach Einbinden des SwissSign-Zertifikates funktioniert die Suche in Enigmail.

Foto
1

Danke!


Super!


Es funktioniert!!!

Foto
1

Es scheint da noch ein anders Problem zu geben (Ausgabe gekürzt!):


  1. $ gpg2 --debug 1024 --keyserver=hkps://pgp.mailbox.org --search support@mailbox.org
  2. gpg: DBG: chan_4 <- OK Dirmngr 2.1.13 at your service
  3. gpg: DBG: chan_4 -> KEYSERVER --clear hkps://pgp.mailbox.org
  4. gpg: DBG: chan_4 <- OK
  5. gpg: DBG: chan_4 -> KS_SEARCH -- support@mailbox.org
  6. gpg: DBG: chan_4 <- ERR 1 General error <Unspecified source>
  7. gpg: error searching keyserver: General error
  8. gpg: keyserver search failed: General error
  9. $ dirmngr
  10. OK Dirmngr 2.1.13 at your service
  11. KEYSERVER --clear hkps://pgp.mailbox.org
  12. OK
  13. KS_SEARCH -- support@mailbox.org
  14. dirmngr[875.0]: DNS query returned an error or no records: No such domain (nxdomain)
  15. dirmngr[875.0]: resolve_dns_addr for 'pgp.mailbox.org': 'pgp.mailbox.org' [already known]
  16. S SOURCE https://pgp.mailbox.org:443
  17. D info:1:1%0D%0Apub:854f20b818a24864:1:4096:1392491184:1518721584:%0D%0Auid:"mailbox.org Support-Team (mailbox.org Support-Team) <support@mailbox.org>":1392491184:1518721584:%0D%0A
  18. OK
  19. $ gpg2 --version
  20. gpg (GnuPG) 2.1.13
  21. libgcrypt 1.7.1
  22. $ dirmngr --version
  23. dirmngr (GnuPG) 2.1.13


Wenn gpg2 den dirmngr aufruft, wird der Schlüssel nicht abgerufen - über den dirmngr direkt gibt es aber ein Ergebnis. Grundsätzlich, d.h. mit einem anderen Keyserver funktioniert es aber über gpg2, denn


  1. $ gpg2 --debug 1024 --keyserver hkps://hkps.pool.sks-keyservers.net --search support@mailbox.org


fördert insgesamt 9 Keys zutage. Eine Idee, woran es hier scheitert?

Foto
Foto
1

Ich habe die Schritte im FAQ abgearbeitet, aber es bleibt beim "Allgemeinen Fehler"...

Foto
1

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.


  1. gpg2 --keyserver=hkps://pgp.mailbox.org --search support@mailbox.org

    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


  1. gpg2 --version

    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

Foto
1

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.

Foto
1

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

Foto
1

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?

Foto
1

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.

Foto
1

oh stimmt. Die Curl Version ist gegen GnuTLS 3.4.10 verlinkt.


  1. /usr/lib/gnupg/gpgkeys_hkp --version

    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?

Foto
1

ldd `which dirmngr` |grep gnutls und dann mit dem Paketmanager nachschauen.

Foto
1

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!

Foto
1

Welchen Fehler bekommst Du denn, wenn du den gpg2 Befehl mit '--debug-all' aufrufst?

Foto
1

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

[...]

Foto
1

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.

Foto
1

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!

Foto
1

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. :-)

Foto
1

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 :) )


  1. gpg2 --debug-all --keyserver=hkps://pgp.mailbox.org --search support@mailbox.org

    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:


  1. lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch

    Distributor ID: Ubuntu

    Description: Ubuntu 16.04.3 LTS

    Release: 16.04

    Codename: xenial

und ~/.gnupg/dirmngr.conf

  1. #hkp-cacert /etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem

    hkp-cacert /home/jschmidt/.gnupg/SwissSign_Silver_CA_-_G2.pem

Foto
1

Hmm, der dirmngr daemon wurde gekillt/neugestartet?


Wird vielleicht eine brauchbare Fehlermeldung angezeigt, wenn du den dirmngr manuell mit den Optionen "--debug-all" und/oder "--debug-level guru" startest?


% killall dirmngr

% dirmngr --debug-all --debug-level guru --daemon --homedir /home/your_username/.gnupg

% gpg --keyserver ...

Foto
1

ja super! Mir war nicht klar, dass "dirmngr" als Service im Hintergrund ständig läuft. Unter xubuntu 16.04 geht es auch. Jetzt fehlt nur noch gpg4win :D

Foto
Foto
1

jetzt wird es noch verrückter... mit gpg2 funktioniert es nicht (siehe Post vorher). Mit dirmngr direkt geht es...

  1. dirmngr --debug-all

    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

Foto
1

Als Information an alle. Es gibt ein BugReport. Mehr dazu unter:

https://dev.gnupg.org/T3411

Foto
1

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 ;)