Comment puis-je faire en sorte que Pidgin accepte toujours un certificat expiré?

8

Mon travail utilise un serveur XMPP local (Wildfire, maintenant appelé Openfire ). Lors de l'utilisation du client Pidgin, il me demande toujours s'il doit accepter le certificat invalide (expiré).

entrez la description de l'image ici

Je voudrais que Pidgin l'accepte toujours sans me le demander. Comment puis-je faire cela sans installer un nouveau certificat sur le serveur XMPP?

J'ai tenté d'importer le certificat dans mon magasin personnel et dans le magasin racine de confiance, mais je reçois toujours la même invite. Le certificat est également stocké dans %APPDATA%\.purple\certificates\x509\tls_peers, mais je reçois toujours l'invite.

Voici le journal de débogage lors de la connexion:

Pidgin Debug Log : 10/4/2016 12:05:16 PM
(12:05:05) account: Connecting to account [email protected]/.
(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 ([email protected]): <?xml version='1.0' ?>
(12:05:05) jabber: Sending ([email protected]): <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 ([email protected]): <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

la source
Avez-vous essayé d'afficher le certificat et de l'installer dans le magasin de certificats Windows?
Evan Darwin
Oui, mais Pidgin envoie le même message d'erreur.
2
Ouvrez Debug Window(Aide -> Fenêtre de débogage), connectez-vous au serveur et choisissez Acceptdans la boîte de dialogue du certificat. Il pourrait y avoir des messages liés au certificat dans la fenêtre de débogage. Vous pouvez joindre le journal à votre question d'origine. Les certificats acceptés doivent être stockés dans %APPDATA%\.purple\certificates\x509\tls_peers. Essayez de vérifier s'il existe un fichier portant le même nom que votre serveur.
ge0rdi
1
J'ai de mauvaises nouvelles. Je regarde les sources Pidgin (votre journal a beaucoup aidé à s'orienter dans le flux de code), mais il semble que pour les certificats expirés (ou pas encore valides), il y a toujours une invite. Toutes les autres erreurs de certificat ne sont pas signalées si le certificat a déjà été accepté. Je suggère de signaler ce problème aux développeurs Pidgin ici .
ge0rdi
1
En fait, il y a des problèmes avec les certificats expirés signalés dans le système de billetterie Pidgin . Habituellement, la réponse est que le certificat du serveur doit être corrigé.
ge0rdi

Réponses:

7

Malheureusement, il n'est pas possible d'accepter définitivement un certificat expiré (du moins pas dans Pidgin 2.11.0 qui est la dernière version pour le moment).

Il existe de nombreux rapports sur ce problème dans le système officiel de suivi des problèmes de Pigdin . La réponse habituelle est que le certificat du serveur doit être corrigé.

On peut également le confirmer dans les sources Pidgin : la
vérification des certificats commence en x509_tls_cached_start_verify. Pour le certificat expiré, un indicateur est PURPLE_CERTIFICATE_EXPIREDdéfini.
Si le certificat a été trouvé dans le cache x509_tls_cached_cert_in_cacheest appelé. Il vérifie que l'empreinte digitale du certificat correspond à celle du cache et des appels x509_tls_cached_complete.
Cette fonction effectue l'une des actions suivantes:

  • informer l'utilisateur que le certificat n'est pas valide (s'il y a eu un problème de certificat fatal)
  • permet à l'utilisateur de décider d'accepter / rejeter le certificat (en cas de problème non fatal; c'est le cas avec le certificat expiré)
  • continue sans aucune invite s'il n'y a pas eu de problème avec le certificat

Il n'y a aucun moyen d'ignorer l'avertissement concernant un certificat expiré (autre que la correction du certificat lui-même).

ge0rdi
la source
0

Ce que @ ge0rdi a dit est juste, mais vous pouvez essayer de télécharger le certificat SSL à la main. Faire cela ferait démarrer pidgin sans lui demander la permission :)

Utilisez la commande suivante:

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

Si cela échoue, ajoutez la commande avec -starttls xmpp comme suit:

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

Placez le fichier dans le dossier suivant:

~/.purple/certificates/x509/tls_peers

Remarque! Assurez-vous que le nom de fichier est le nom DNS du serveur.

ÉDITER:

Devinez qui vient de remarquer que vous utilisez une machine Windows ... ~ / est la partition domestique d'un utilisateur Linux. Selon cette page, l'équivalent de Windows est% APPDATA%.

Rick van Lieshout
la source
Le certificat est déjà là, mais Pidgin me demande toujours si je veux l'accepter à chaque fois. C'est dans la question et dans les commentaires également.