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 :
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