J'ai documenté comment tester OCSP stapling. Mais pas comment tester OCSP tout court. Vu que j'en ai eu besoin, il est temps de le faire. :)
Ces notes sont fortement inspirées de ce tutoriel : OCSP Validation with OpenSSL – Akshay Ranganath's Blogs.

OCSP = protocole qui permet à un client TLS (un navigateur web, par exemple) de vérifier, en direct, lors de l'accès à une ressource (un site web via le protocole HTTPS, par exemple), la validité d'un certificat x509. Cette vérification se fait en interrogeant l'autorité de certification (AC) qui a émis le certificat x509. But ? Vérifier que le certificat n'a pas été révoqué car la clé privée utilisée pour sa génération a été compromise, par exemple.

Cela pose un problème de respect de la vie privée, surtout quand une autorité de certification est hégémonique (comme Let's Encrypt, par exemple). J'ai expliqué cela en détail ici.

OCSP stapling remédie à ce problème puisque c'est le site web visité qui communique la preuve de validité de son certificat x509 lors de la poignée de main TLS (via une extension TLS). Cette preuve ne peut pas être falsifiée puisqu'elle est signée par l'autorité de certification. Ainsi, l'AC n'est pas interrogée par les navigateurs web qui visitent le site web, mais uniquement par le serveur de ce site (et la réponse est mise en cache), donc la vie privée est préservée.

Il faut penser à désactiver OCSP et à vérifier qu'OCSP stapling est bien activé dans la configuration de son navigateur web (et autres clients TLS comme un logiciel de courriels). Voir ici pour Firefox.

Tester un répondeur OCSP. Ici, celui d'iPXE :

# Récupérer un certificat signé par l'AC :
wget http://ca.ipxe.org/cross-ca.crt

# Récupérer le certificat de l'AC (il n'y a pas de certificat intermédiaire) :
wget https://ca.ipxe.org/ca.crt

# Dépiauter l'URL du répondeur OCSP
openssl x509 -in cross-ca.crt -ocsp_uri -noout

# Tester le répondeur OCSP
openssl ocsp -issuer ca.crt -cert cross-ca.crt -text -url http://ocsp.ipxe.org/ocsp/root/

Résultat :

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9D22406E09E917C47B5C2317E37F3A895110EF1F
          Issuer Key Hash: AB41305C0BB30C7107313C337644981C51D42A72
          Serial Number: 4C
    Request Extensions:
        OCSP Nonce: 
            0410FA5B843E6EA96F70F9C2DA6F75A955DA
Responder Error: trylater (3)

Ha, le répondeur OCSP du projet iPXE est hors service.

Un cas plus difficile. Récupération des certificats lors de la poignée de main TLS et présence d'un certificat intermédiaire :

# Récupérer la chaîne de certification du service TLS
openssl s_client -connect ent.univ-avignon.fr:443 -showcerts < /dev/null 2>&1 |  sed -n '/-----BEGIN/,/-----END/p' > chaine.crt

# Isoler le certificat feuille (celui du service TLS) dans un fichier dédié et l'effacer de la chaîne (sinon OpenSSL échoue, « unauthorized ») :
sed -n '1,/-----END/p' chain.cert > ent.crt ; sed -in '1,/-----END/d' chaine.crt

# Dépiauter l'URL du répondeur OCSP
openssl x509 -in ent.crt -ocsp_uri -noout

# Tester le répondeur OCSP
openssl ocsp -issuer chaine.crt -cert ent.crt -text -url http://GEANT.ocsp.sectigo.com

Attention : s'il est obligatoire (par la norme) que le certificat feuille soit le premier dans la liste communiquée par un serveur TLS, le certificat intermédiaire ne sera pas toujours le deuxième, car cela dépend de la rigueur de l'administrateur du serveur TLS. Ce choix, très courant, a été acté dans la norme TLS 1.3. Donc, il faut parfois s'adapter, et vérifier l'ordre des certificats + s'assurer que chaque certificat est dans le bon fichier passé au bon paramètre d'OpenSSL, est la première chose à faire quand OpenSSL crache une erreur « unauthorized ».

Résultat :

OCSP Request Data:
      Version: 1 (0x0)
      Requestor List:
          Certificate ID:
            Hash Algorithm: sha1
            Issuer Name Hash: C3FDEA1EAA0EBEDE75016EEC6E5BB393F0F12E5D
            Issuer Key Hash: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
            Serial Number: B3A8B670D4517A753871ED8F2EF46450
      Request Extensions:
          OCSP Nonce: 
              041034E12F9591DFFCCE41926E4C9834F0F5
  OCSP Response Data:
      OCSP Response Status: successful (0x0)
      Response Type: Basic OCSP Response
      Version: 1 (0x0)
      Responder Id: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
      Produced At: Apr 15 15:24:27 2022 GMT
      Responses:
      Certificate ID:
        Hash Algorithm: sha1
        Issuer Name Hash: C3FDEA1EAA0EBEDE75016EEC6E5BB393F0F12E5D
        Issuer Key Hash: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
        Serial Number: B3A8B670D4517A753871ED8F2EF46450
      Cert Status: good
      This Update: Apr 15 15:24:27 2022 GMT
      Next Update: Apr 22 15:24:27 2022 GMT

      Signature Algorithm: sha384WithRSAEncryption
           5b:1a:4f:4d:71:7c:d5:81:37:36:a7:e6:5a:80:47:fc:ec:d5:
           a5:18:49:86:b1:2f:05:0d:e9:30:0c:61:75:36:cf:fd:d0:10:
           b2:9b:fa:15:92:c1:91:5c:e5:28:ee:06:c5:50:fb:8b:18:58:
           04:5c:b9:07:f2:f3:37:8d:e7:0f:be:3e:58:7d:ca:b8:83:08:
           b3:c7:a0:40:ae:d2:0a:7a:c2:18:0b:f4:e9:67:9d:ca:b7:d9:
           0c:88:35:3b:d7:7f:95:e6:b5:92:c0:78:8a:26:72:26:1c:1e:
           e0:32:2e:03:4c:84:0e:bf:3c:9a:6d:e1:93:83:76:1d:e5:04:
           3b:62:3e:c4:6a:01:8e:fb:b6:1a:0a:4e:64:cd:7c:9d:99:d3:
           05:50:f5:52:71:bf:36:26:f0:d7:ad:7e:a5:7c:fc:e5:db:6e:
           c7:ae:a4:66:ef:94:a8:53:8c:3a:c5:5b:cc:bb:a4:89:c9:c6:
           60:ca:fc:f9:cd:e0:af:39:f0:6e:ea:8e:e6:21:d5:78:ae:f9:
           d5:bc:3d:ac:3b:e4:7e:d6:7e:c1:3a:ce:21:dd:7e:aa:ca:82:
           e1:b5:74:f4:10:62:69:6e:be:60:dd:fb:78:e7:7e:52:82:1c:
           3d:73:b1:db:84:65:a4:14:ee:29:99:11:31:a9:3f:42:5a:b2:
           0f:e3:e9:2c:d0:40:56:0f:b0:04:1a:e0:51:09:6e:47:56:c1:
           b5:f2:72:da:68:ec:3f:cc:4b:fd:8e:c3:9b:6f:0f:78:a3:22:
           83:f7:28:ee:f5:4f:5b:82:bf:17:2f:eb:c9:fa:3d:28:d2:ef:
           0f:90:ed:3e:1c:be:78:89:d9:2d:b9:f1:68:1b:79:7d:a7:6d:
           93:c0:13:15:4f:73:6c:a7:39:77:97:17:5d:79:f9:ef:fb:1d:
           67:cb:79:72:e5:2a:ca:66:b6:cf:7b:4e:cc:23:a0:5b:f4:ae:
           33:b2:0d:95:54:44:e8:e0:18:3a:79:49:67:2d:ac:c8:cf:d8:
           43:3b:6a:7a:4d:8f:f4:6d:77:d9:bf:55:48:6f:50:3f:da:07:
           d3:58:dc:9d:e8:78:20:09:49:e5:7c:8b:1e:a4:79:95:5d:37:
           69:d0:b3:0f:f3:47:d5:92:74:16:34:b5:6a:a0:47:9a:54:b9:
           ad:fd:13:2a:b8:60:39:d7:f7:0d:b4:9d:0a:b9:2d:09:99:51:
           91:e5:c0:ea:03:68:30:10:00:94:aa:cd:31:3a:57:8b:0d:82:
           df:8a:d0:64:d3:69:7f:84:ac:25:ce:10:18:65:db:36:58:6c:
           0c:28:59:de:ad:a9:c7:05:0d:35:b3:7a:73:b7:d9:61:91:39:
           ee:9f:da:f8:f5:c4:57:54
  WARNING: no nonce in response
  Response verify OK
  ent.crt: good
      This Update: Apr 15 15:24:27 2022 GMT
      Next Update: Apr 22 15:24:27 2022 GMT

Les lignes importantes :

• « OCSP Response Status: successful (0x0) » : répondeur OK ;
  
  
• « Response verify OK » : authentification cryptographique de la réponse OK ;
  
  
• « ent.crt: good » : certificat valide.

En fonction de la panne que l'on diagnostique, et afin d'être rigoureux, il faudrait également vérifier que le répondeur de l'AC qui a signé le certificat intermédiaire répond et que ce dernier n'est pas révoqué. Pour ce faire, il suffit de déplacer le certificat intermédiaire dans un fichier, de passer ce fichier en paramètre de -cert et le certificat racine (que l'on peut télécharger sur le site web de l'AC ou récupérer dans le navigateur web : icône cadenas dans la barre d'URL, « connexions sécurisée », « plus d'informations », identifier le certificat, et cliquer sur « PEM (cert) » sur la ligne « Télécharger »), en paramètre de -issuer.

Avec un certificat révoqué, il y a uniquement la fin qui change :

XXXXXXXXXX.crt: revoked
    This Update: Apr 16 14:41:26 2022 GMT
    Next Update: Apr 23 14:41:26 2022 GMT
    Revocation Time: Apr 16 14:41:22 2022 GMT

The Web Console: […] Enables you to interact with a web page by executing JavaScript expressions in the context of the page

Je ne savais pas (ou j'ai oublié), que la console web des outils de développement web de Firefox permet d'interagir avec une page web en causant JavaScript.

Dans ladite console, il y a deux chevrons grisés à gauche (sous l'icône corbeille). Il suffit de cliquer en face d'eux dans la zone blanche et de saisir du JavaScript, genre, sur ce shaarli, document.getElementById("menu");. Si l'objet existe, il est retourné, sinon « null » est retourné.

Une collègue m'a montré cela alors que nous cherchions à comprendre pourquoi le logiciel web bbb-recorder, qui permet de faire un screencast d'un enregistrement BigBlueButton (BBB) afin de le rendre indépendant du lecteur interne de BBB (et donc, de l'exporter).
Depuis quelques jours, il n'arrivait plus à récupérer la durée d'un enregistrement BBB et donc à lancer le screencast.

Si l'on regarde le code, l'élément du DOM contenant la durée est recherché. Le nom de cet élément change en fonction de la version de l'API de Scalelite (et non pas de la version de BBB, la variable « bbbVersionIs23 » est mal nommée).

Ma collègue ajoute un console.log(url); afin que l'on récupère, dans le journal de l'application sur le serveur (et pas dans la console web comme on pourrait s'y attendre), l'URL du lecteur BBB pour un enregistrement donné. On y accède avec nos navigateurs web. J'ai le réflexe de regarder le code source de la page… et j'y trouve ni élément avec l'ID « vjs_video_3_html5_api », ni élément avec l'ID « video ». :O Ma collègue, qui a utilisé la console web de Firefox, a trouvé l'élément avec l'ID « video ».

C'est un classique, la page « view-source » qui n'affiche pas forcément le code qui correspond à ce que l'on voit à l'écran (car JavaScript peut manipuler la page web, par exemple).
Mais ça n'échappe pas à un requêtage via la console web, c'est noté.

Notons que, lors du premier copier+coller d'un code JavaScript en son sein, la console demande à débloquer explicitement le copier+coller en saisissant une phrase.

Merci Jade de m'avoir appris (ou rappelé) cette possibilité de la console web. :)