Guide

Comment analyser Schannel 36874 et 36888

Ce guide montre comment analyser Schannel 36874 et 36888 à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200.

⌚ Environ 3 min de lecture
Voir mes favoris
Windows & TLS Intermédiaire 15-30 min

Ce guide montre comment analyser Schannel 36874 et 36888 à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Identifier les critères déterminants

    Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200.

  2. 2

    Recouper le contexte technique

    Le certificat doit couvrir le nom utilisé via SAN, être dans sa période de validité et présenter une chaîne de confiance complète.

  3. 3

    OpenSSL + HTTP

    Tester le handshake avec le bon servername puis lire le statut HTTP séparément.

  4. 4

    Écarter les erreurs de diagnostic

    Ne pas confondre certificat expiré et chaîne intermédiaire manquante : les messages clients diffèrent.

  5. 5

    Valider le résultat

    Le nom, la chaîne, les dates et le protocole sont valides depuis un client représentatif. La requête HTTP atteint le backend attendu et retourne le statut prévu.

Commandes utiles

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -I https://example.com/

À retenir

  • Avec SNI, tester l’IP seule peut présenter un certificat différent de celui du nom DNS.
  • Schannel 36874/36888 doit être corrélé au protocole/cipher et au client qui déclenche l’alerte.
  • La requête HTTP atteint le backend attendu et retourne le statut prévu.
Complément technique

HTTPS/TLS : séparer disponibilité HTTP, handshake TLS et identité du certificat

Repères techniques

  • Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200.
  • Le certificat doit couvrir le nom utilisé via SAN, être dans sa période de validité et présenter une chaîne de confiance complète.
  • Avec SNI, tester l’IP seule peut présenter un certificat différent de celui du nom DNS.

OpenSSL + HTTP

Tester le handshake avec le bon servername puis lire le statut HTTP séparément.

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -I https://example.com/

Pièges spécifiques

  • Ne pas confondre certificat expiré et chaîne intermédiaire manquante : les messages clients diffèrent.
  • Schannel 36874/36888 doit être corrélé au protocole/cipher et au client qui déclenche l’alerte.

Comment valider

  • Le nom, la chaîne, les dates et le protocole sont valides depuis un client représentatif.
  • La requête HTTP atteint le backend attendu et retourne le statut prévu.

Références de validation

Source primaire : Microsoft Learn — TLS/SSL (Schannel SSP) overview.

♡ 0