Wie kann ich Pidgin dazu bringen, immer ein abgelaufenes Zertifikat zu akzeptieren?

Meine Arbeit verwendet einen lokalen XMPP-Server (Wildfire, jetzt Openfire genannt ). Bei Verwendung des Pidgin-Clients werde ich immer gefragt, ob das ungültige (abgelaufene) Zertifikat akzeptiert werden soll.

Ich möchte Pidgin dazu bringen, es immer zu akzeptieren, ohne mich zu fragen. Wie kann ich dies tun, ohne ein neues Zertifikat auf dem XMPP-Server zu installieren?

Ich habe versucht, das Zertifikat sowohl in meinen persönlichen als auch in den vertrauenswürdigen Stammspeicher zu importieren, erhalte jedoch immer noch die gleiche Eingabeaufforderung. Das Zertifikat ist auch in gespeichert %APPDATA%\.purple\certificates\x509\tls_peers, aber ich erhalte immer noch die Aufforderung.

Hier ist das Debug-Protokoll beim Verbinden:

Pidgin Debug Log : 10/4/2016 12:05:16 PM
(12:05:05) account: Connecting to account example@192.168.1.21/.
(12:05:05) connection: Connecting. gc = 04528D78
(12:05:05) dnssrv: querying SRV record for 192.168.1.21: _xmpp-client._tcp.192.168.1.21
(12:05:05) dnssrv: Couldn't look up SRV record. The filename, directory name, or volume label syntax is incorrect. (123).
(12:05:05) dnsquery: Performing DNS lookup for 192.168.1.21
(12:05:05) dnsquery: IP resolved for 192.168.1.21
(12:05:05) proxy: Attempting connection to 192.168.1.21
(12:05:05) proxy: Connecting to 192.168.1.21:5222 with no proxy
(12:05:05) proxy: Connection in progress
(12:05:05) proxy: Connecting to 192.168.1.21:5222.
(12:05:05) proxy: Connected to 192.168.1.21:5222.
(12:05:05) jabber: Sending (example@192.168.1.21): <?xml version='1.0' ?>
(12:05:05) jabber: Sending (example@192.168.1.21): <stream:stream to='192.168.1.21' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(12:05:05) jabber: Recv (579): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="192.168.1.21" id="da08260e" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>CRAM-MD5</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>ANONYMOUS</mechanism></mechanisms><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/></stream:features>
(12:05:05) jabber: Sending (example@192.168.1.21): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(12:05:05) jabber: Recv (50): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
(12:05:05) nss: SSL version 3.1 using 128-bit AES with 160-bit SHA1 MAC
Server Auth: 2048-bit RSA, Key Exchange: 1024-bit DHE, Compression: NULL
Cipher Suite Name: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
(12:05:05) nss: subject=CN=Unknown,OU=Unknown,O=REDACTED,L=REDACTED,ST=REDACTED,C=US issuer=CN=Unknown,OU=Unknown,O=REDACTED,L=REDACTED,ST=REDACTED,C=US
(12:05:05) certificate/x509/tls_cached: Starting verify for 192.168.1.21
(12:05:05) certificate/x509/tls_cached: Certificate 192.168.1.21 expired at Mon Aug 29 09:54:35 2016

(12:05:05) certificate/x509/tls_cached: Checking for cached cert...
(12:05:05) certificate/x509/tls_cached: ...Found cached cert
(12:05:05) nss/x509: Loading certificate from C:\Users\example\AppData\Roaming\.purple\certificates\x509\tls_peers\192.168.1.21
(12:05:05) certificate/x509/tls_cached: Peer cert matched cached
(12:05:07) util: Writing file accounts.xml to directory C:\Users\example\AppData\Roaming\.purple
(12:05:07) util: Writing file C:\Users\example\AppData\Roaming\.purple\accounts.xml
(12:05:07) util: Writing file blist.xml to directory C:\Users\example\AppData\Roaming\.purple
(12:05:07) util: Writing file C:\Users\example\AppData\Roaming\.purple\blist.xml
(12:05:07) certificate/x509/tls_cached: User ACCEPTED cert
Caching first in chain for future use as 192.168.1.21...
(12:05:07) nss/x509: Exporting certificate to C:\Users\example\AppData\Roaming\.purple\certificates\x509\tls_peers\192.168.1.21
(12:05:07) util: Writing file C:\Users\example\AppData\Roaming\.purple\certificates\x509\tls_peers\192.168.1.21
(12:05:07) nss: Trusting CN=Unknown,OU=Unknown,O=REDACTED,L=REDACTED,ST=REDACTED,C=US
(12:05:07) certificate: Successfully verified certificate for 192.168.1.21

windows-10 certificate pidgin

Haben Sie versucht, das Zertifikat anzuzeigen und im Windows-Zertifikatspeicher zu installieren?

— Evan Darwin

Ja, aber Pidgin gibt dieselbe Fehlermeldung aus.

Öffnen Sie Debug Window(Hilfe -> Debug-Fenster), stellen Sie eine Verbindung zum Server her und wählen Sie Acceptim Zertifikatdialog. Das Debug-Fenster enthält möglicherweise einige zertifikatsbezogene Meldungen. Sie können das Protokoll an Ihre ursprüngliche Frage anhängen. Akzeptierte Zertifikate sollten in gespeichert werden %APPDATA%\.purple\certificates\x509\tls_peers. Versuchen Sie dort zu suchen, ob es eine Datei mit demselben Namen wie Ihr Server gibt.

— Ge0rdi

Ich habe schlechte Neuigkeiten. Ich schaue mir Pidgin- Quellen an (Ihr Protokoll hat mir sehr geholfen, mich im Code-Fluss zu orientieren), aber es scheint, dass für abgelaufene (oder noch nicht gültige) Zertifikate immer eine Eingabeaufforderung vorliegt. Alle anderen Zertifikatfehler werden nicht gemeldet, wenn das Zertifikat bereits akzeptiert wurde. Ich würde vorschlagen , um dieses Problem zu Pidgin - Entwickler berichten hier .

— Ge0rdi

Tatsächlich gibt es Probleme mit abgelaufenen Zertifikaten, die im Pidgin- Ticketingsystem gemeldet werden . Normalerweise lautet die Antwort, dass das Serverzertifikat repariert werden muss.

— Ge0rdi

Leider ist es nicht möglich , abgelaufene Zertifikate dauerhaft zu akzeptieren (zumindest nicht in Pidgin 2.11.0, der derzeit neuesten Version).

Es gibt viele Berichte zu diesem Problem im offiziellen Pigdin Issue Tracking System . Die übliche Antwort ist, dass das Serverzertifikat repariert werden muss.

Man kann es auch in Pidgin- Quellen bestätigen : Die
Zertifikatsüberprüfung beginnt in x509_tls_cached_start_verify. Für abgelaufene Zertifikate ist ein Flag PURPLE_CERTIFICATE_EXPIREDgesetzt.
Wenn ein Zertifikat im Cache gefunden wurde, x509_tls_cached_cert_in_cachewird aufgerufen. Es wird überprüft, ob der tatsächliche Zertifikatfingerabdruck mit einem im Cache und bei Aufrufen übereinstimmt x509_tls_cached_complete.
Diese Funktion führt eine der folgenden Aktionen aus:

Benachrichtigen Sie den Benutzer, dass das Zertifikat ungültig ist (wenn ein schwerwiegendes Zertifikatproblem aufgetreten ist).
Ermöglicht dem Benutzer die Entscheidung, ob ein Zertifikat akzeptiert / abgelehnt werden soll (wenn ein nicht schwerwiegendes Problem aufgetreten ist; dies ist bei abgelaufenen Zertifikaten der Fall).
wird ohne Aufforderung fortgesetzt, wenn kein Problem mit dem Zertifikat aufgetreten ist

Es gibt keine Möglichkeit, Warnungen über abgelaufene Zertifikate zu überspringen (außer das Zertifikat selbst zu reparieren).

— ge0rdi
quelle

Was @ ge0rdi gesagt hat, ist richtig, aber Sie können versuchen, das SSL-Zertifikat von Hand herunterzuladen. Dies würde dazu führen, dass Pidgin startet, ohne um Erlaubnis zu bitten :)

Verwenden Sie den folgenden Befehl:

~/.purple/certificates/x509/tls_peers$ openssl s_client -connect YOUR_SERVER:PORTNUMBER

Wenn dies fehlschlägt, hängen Sie den Befehl wie folgt mit -starttls xmpp an:

~/.purple/certificates/x509/tls_peers$ openssl s_client -connect YOUR_SERVER:PORTNUMBER -starttls xmpp

Legen Sie die Datei in den folgenden Ordner:

~/.purple/certificates/x509/tls_peers

Hinweis! Stellen Sie sicher, dass der Dateiname der DNS-Name des Servers ist.

BEARBEITEN:

Ratet mal, wer gerade bemerkt hat, dass ihr einen Windows-Computer verwendet ... ~ / ist die Home-Partition eines Linux-Benutzers. Laut dieser Seite ist das Windows-Äquivalent% APPDATA%.

— Rick van Lieshout
quelle

Das Zertifikat ist bereits vorhanden, aber Pidgin fragt immer noch, ob ich es jedes Mal akzeptieren möchte. Das steht in der Frage und auch in den Kommentaren.