Question Windows peut-il journaliser les délais impartis par CryptoAPI CRL?


Je soupçonne que le processus de construction du cache CRL peut provoquer une latence dans certaines applications.

Nous avons plusieurs applications .NET qui parfois "agissent lentement" sans accès CPU ou disque. Je soupçonne qu'ils sont bloqués sur l'authentification lorsqu'ils tentent de valider le certificat, car le délai d'attente est presque 20 secondes.

Comme par cet article MSFT

La plupart des applications ne spécifient pas à CryptoAPI d’utiliser une   temps libre. Si l'option de délai d'expiration cumulé n'est pas activée, CryptoAPI   utilise le paramètre par défaut CryptoAPI qui est un délai d'attente de 15 secondes   par URL. Si l'option de délai d'expiration cumulée spécifiée par le   CryptoAPI utilisera un paramètre par défaut de 20 secondes.   en tant que délai d'attente cumulé. La première URL reçoit un délai d'expiration maximal de   10 secondes. Chaque délai d’URL subséquent correspond à la moitié de la durée restante.   solde dans la valeur de temporisation cumulée.

Puisqu'il s'agit d'un service, comment puis-je détecter et consigner les blocages CryptoAPI pour les applications pour lesquelles j'ai un code source, ainsi que pour des tiers?


6
2018-06-02 03:53


origine




Réponses:


Un moyen d'obtenir plus d'informations à ce sujet consiste à activer le journal des événements CAPI2.

  • Ouvrez Eventvwr -> Journaux d'applications et de services ->
  • Microsoft -> Windows -> CAPI2 -> Opérationnel ->
  • Clic droit Activer le journal

Les informations qui apparaissent dans le journal des événements aideront à déterminer si le processus de validation du certificat prend beaucoup de temps.

Pour activer la journalisation

  wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true

Pour enregistrer le journal dans un fichier

 wevtutil.exe epl Microsoft-Windows-CAPI2/Operational filename.elf

Pour désactiver la journalisation

 wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false

Pour effacer les journaux

 wevtutil.exe cl Microsoft-Windows-CAPI2/Operational

4
2018-06-02 18:17





J'ai plusieurs options pour vous, car dépanner une PKI potentielle peut être un problème complexe.

Les CRL sont des bêtes lentes et encombrantes ...

Tout d'abord, je vais vous dire que les délais d'attente des listes de révocation de certificats ont conduit la plus grande infrastructure à clé publique au monde à ne pas utiliser les listes de révocation de certificats pour la grande majorité des besoins en validation de la PKI. Le téléchargement d'un fichier de 50 Mo lorsqu'un utilisateur a simplement besoin d'un simple oui ou non avant d'envoyer un courrier électronique crypté est un non-débutant!

Comment faire la validation

1 - Vous pouvez tester un client de validation natif de Microsoft de remplacement avec un client de validation tiers, tel que Tumbleweed ou autre, puis surveiller le client de validation tiers (en tant que contrôle). Tumbleweed / Axways vend et fournit des tests à un client de validation tiers populaire, aux répéteurs OCSP et aux répondeurs. Vous pouvez également utiliser OpenSSL, ejbca ou OpenCA en tant que répondeurs de validation. En outre, il existe une infrastructure PKIF OSS, comprenant des fonctions de journalisation CAPI spécifiques, et des clients OCSP situés à l'adresse suivante: http://pkif.sourceforge.net/

2 - Vous pouvez contrôler les sources de données de validation (CRL, OCSP, SCVP).

3 - Une autre source de problèmes peut être une résolution DNS lente, un manque de cache DNS, une PKI mal configurée, des approbations manquantes ou le temps requis pour actualiser les listes de révocation de certificats (provoquant un blocage temporaire si une PKI plus grande).

Pouvez-vous partager plus de détails sur la configuration des applications, la PKI elle-même, les champs des certificats x509, la bande passante, etc. Je suis particulièrement intéressé par les champs relatifs à la validation, tels que le champ AIA (Authority Information Access) pour exemple, et toute référence codée en dur à la liste de révocation de certificats ou à OCSP.

N'oubliez pas qu'il existe également une ambiguïté bien connue dans les types de réponse. Les RFC spécifiquement pour OCSP ont des problèmes en ce sens qu'une bonne réponse et une réponse inconnue sont également valables pour un certificat dont la validation n'a pas connaissance.

Une discussion sur les alternatives:

Il existe deux méthodes principales pour valider un certificat: la liste blanche et la liste noire.

Les protocoles de liste noire incluent les listes de révocation de certificats, OCSP et SCVP, puis des variantes d'OCSP.

La liste blanche sur Windows peut être réalisée à l'aide d'une interface OCSP avec une base de données CA, CTL * et SCVP.

Dans la plupart des cas, les méthodes de liste blanche sont considérées comme supérieures, plus sûres, plus rapides, plus en temps réel et de meilleures alternatives aux méthodes de liste noire.


4
2018-06-02 20:33



Pouvez-vous m'en dire plus sur les logiciels tiers que je devrais utiliser? Bon point sur la résolution DNS. Je n'ai pas les certificats à inspecter, mais quels champs x 509 affectent le temps de résolution? Je suis également intrigué mais le commentaire d'ambiguïté. S'il vous plaît faites plus de détails à ce sujet! - random65537
réponse mise à jour pour répondre à vos questions - Brennan
Impressionnant! Je veux plus +++++ cela. Je pense qu'une partie du problème réside dans le fait que le certificat contient une URL LDAP à laquelle je n'ai pas accès, une URL de fichier sur un autre réseau. Je ne sais pas ce que seront les AIA ou les LCR… des CRL…. Je soupçonne que cela peut être la cause. - random65537
Dans la lignée des "mal configurés", nous avons une autorité de certification de développement / test, une autorité de certification de production et une autorité de certification de récupération hors site. Nous avons en fait eu des problèmes où la validation n’était pas effectuée par rapport à l’AC prévue. Cela peut aussi être un problème de DNS, mais le résultat est que si vous avez un environnement complexe, cela peut aider à confirmer que les serveurs utilisés pour valider les certificats sont bien les serveurs qui devraient être utilisés. - Greg Askew


Pour ce que cela vaut, il existe un correctif qui ne résout pas le problème spécifique, mais contient un cryptnet.dll mis à jour pour résoudre les problèmes OCSP. Ce fichier particulier n'a pas non plus été mis à jour dans SP1.

Vous ne pouvez pas utiliser une méthode d'ouverture de session basée sur un certificat pour authentifier les demandes sur un ordinateur qui exécute Windows Server 2008 R2

http://support.microsoft.com/kb/2666300 


1
2018-06-02 19:35



+1 bon conseil: le bogue vient du fait que la liste de révocation de certificats (CRL) mise en cache localement est expirée et que le répondeur OSCP est hors ligne. - random65537