La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 13 avril 2015 à 17:28:04
-
Pour analyser le TLS et les certificats, il y a aussi https://tls.so/ (https://tls.so/)
Voici la fiche de lafibre.info : https://tls.so/results/saved.lafibreinfo.1428925462.1acde0d8176ce33243bfa7dd0052ac49.html (https://tls.so/results/saved.lafibreinfo.1428925462.1acde0d8176ce33243bfa7dd0052ac49.html)
Intéressant, ils affichent des informations différentes de SSL labs
Je vois que je pourrais éviter à tous ceux qui ont Firefox de faire systématiquement une requête vers Akamai pour vérifier si le certificat de LaFibre.info est révoqué.
=> C'est la fonctionnalité OCSP Stapling qui permet à mon serveur de cacher la réponse
Je vais l'activer.
Tutoriel en anglais : https://raymii.org/s/tutorials/OCSP_Stapling_on_Apache2.html
(https://lafibre.info/images/ssl/201504_lafibre_avec_ocsp_stapling.png)
-
J'ai un peu de mal a comprendre pour l'activation de OCSP Stapling
Quand je rajoute
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Apache me répond :
SSLStaplingCache cannot occur within <VirtualHost> section
SSLStaplingCache serait incompatible avec un VirtualHost ?
Pour tant la doc parle bien d'un virtualhost :
Add the below configuration to your virtualhost:
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Un point positif, SSL Labs sait détecter les pb avec OCSP :
(https://lafibre.info/images/tuto/201504_ssl_labs_ocsp_error.png)
-
Dans /etc/apache2/mods-enabled/ssl.conf, cela est OK
Edit : en fait, il semble que les instructions doivent être dans un <IfModule>
Donc, si j'ai un truc comme cela, ça fonctionne:
<VirtualHost *:80>
<IfModule mod_ssl.c>
SSLUseStapling on
</IfModule>
</VirtualHost>
Edit2: SSLStaplingCache ne peut être dans un vhost
-
J'ai essayé de mettre ça :
<IfModule mod_ssl.c>
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
</IfModule>
et ça :
<IfModule ssl_module>
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
</IfModule>
Mais dans les deux cas, j'ai :
SSLStaplingCache cannot occur within <VirtualHost> section
Action 'configtest' failed.
-
Ok j'ai compris
SSLUseStapling peut-être dans un vhost (pas besoin de <IfModule>)
SSLStaplingCache, en revanche, ne peut pas être dans un vhost
En relisant la doc, c'est ce qui est écrit et c'est logique : le cache se configure en global, et il est possible de n'activer / désactiver le truc que pour certain vhost.
-
Pour Ubuntu 13.10 et supérieur / Debian 8 :
Éditer le fichier /etc/apache2/mods-enabled/ssl.conf
Rajouter, à la fin, avant </IfModule> :
SSLUseStapling On
SSLStaplingCache "shmcb:ssl_stapling(32768)"
En cas de mauvaise configuration, Firefox bloquera l’accès au site, sans moyen de contourner le blocage :
(https://lafibre.info/images/tuto/201504_ocsp_error.png)
Aide sur le site Apache : http://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
-
Vérification avec OPenSSL :
$ openssl s_client -connect iperf.fr:443 -status -servername iperf.fr
CONNECTED(00000003)
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = IL, O = StartCom Ltd. (Start Commercial Limited), CN = StartCom Class 1 Server OCSP Signer
Produced At: Apr 17 02:24:09 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 6568874F40750F016A3475625E1F5C93E5A26D58
Issuer Key Hash: EB4234D098B0AB9FF41B6B08F7CC642EEF0E2C45
Serial Number: 10E6DC
Cert Status: good
This Update: Apr 17 02:24:09 2015 GMT
Next Update: Apr 19 02:24:09 2015 GMT
Signature Algorithm: sha1WithRSAEncryption
40:f3:e7:17:95:6c:55:ca:6d:91:8d:03:d1:dd:bd:bb:19:25:
79:81:a5:51:38:91:c7:89:93:0c:26:6c:cc:d1:b5:20:29:c6:
44:6c:ae:75:97:f2:31:72:05:fa:98:d6:d7:f1:1d:42:ff:67:
81:7a:d5:7e:43:8f:a2:55:2e:c5:5f:2d:41:b8:72:29:1c:8c:
39:a2:bb:f1:01:85:1c:e8:a4:bc:9d:36:43:12:b7:12:74:6b:
c3:75:99:de:44:8e:f7:92:79:9a:62:8c:d2:3f:22:13:02:79:
92:99:e4:86:a1:47:61:d7:a2:36:f6:ee:64:1c:1a:d0:47:76:
dc:ce:6f:cf:0a:ca:b4:f1:24:ab:7e:98:a8:25:8c:ec:e6:34:
69:9d:85:59:b7:01:11:9e:96:7a:c3:35:fc:7b:d0:ad:3f:67:
37:a8:c3:78:a2:68:b2:97:15:93:f3:a0:d6:94:39:52:af:25:
5f:27:ff:bc:45:34:33:09:01:d2:e4:f5:3c:05:58:5f:0b:b4:
39:ec:90:e7:41:cc:d9:fa:7a:b6:9e:6c:ac:5c:a7:86:04:17:
43:a0:f2:ed:d4:36:53:ad:a4:e6:0e:77:d7:b9:7e:92:cf:6c:
60:fb:c0:f2:2d:dd:a1:30:82:79:3f:d6:fb:7e:59:03:7e:7d:
00:c9:97:74
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1531175 (0x175d27)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 1 Primary Intermediate Server CA
Validity
Not Before: Mar 22 22:07:45 2015 GMT
Not After : May 2 02:12:05 2015 GMT
Subject: C=IL, O=StartCom Ltd. (Start Commercial Limited), CN=StartCom Class 1 Server OCSP Signer
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b9:56:1b:4c:45:31:87:17:17:80:84:e9:6e:17:
8d:f2:25:5e:18:ed:8d:8e:cc:7c:2b:7b:51:a6:c1:
c2:e6:bf:0a:a3:60:30:66:f1:32:fe:10:ae:97:b5:
0e:99:fa:24:b8:3f:c5:3d:d2:77:74:96:38:7d:14:
e1:c3:a9:b6:a4:93:3e:2a:c1:24:13:d0:85:57:0a:
95:b8:14:74:14:a0:bc:00:7c:7b:cf:22:24:46:ef:
7f:1a:15:6d:7e:a1:c5:77:fc:5f:0f:ac:df:d4:2e:
b0:f5:97:49:90:cb:2f:5c:ef:eb:ce:ef:4d:1b:dc:
7a:e5:c1:07:5c:5a:99:a9:31:71:f2:b0:84:5b:4f:
f0:86:4e:97:3f:cf:e3:2f:9d:75:11:ff:87:a3:e9:
43:41:0c:90:a4:49:3a:30:6b:69:44:35:93:40:a9:
ca:96:f0:2b:66:ce:67:f0:28:df:29:80:a6:aa:ee:
8d:5d:5d:45:2b:8b:0e:b9:3f:92:3c:c1:e2:3f:cc:
cb:db:e7:ff:cb:11:4d:08:fa:7a:6a:3c:40:4f:82:
5d:1a:0e:71:59:35:cf:62:3a:8c:7b:59:67:00:14:
ed:06:22:f6:08:9a:94:47:a7:a1:90:10:f7:fe:58:
f8:41:29:a2:76:5e:a3:67:82:4d:1c:3b:b2:fd:a3:
08:53
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
OCSP Signing, OCSP No Check
X509v3 Subject Key Identifier:
45:E0:A3:66:95:41:4C:5D:D4:49:BC:00:E3:3C:DC:DB:D2:34:3E:17
X509v3 Authority Key Identifier:
keyid:EB:42:34:D0:98:B0:AB:9F:F4:1B:6B:08:F7:CC:64:2E:EF:0E:2C:45
X509v3 Issuer Alternative Name:
URI:http://www.startssl.com/
Signature Algorithm: sha1WithRSAEncryption
3f:59:f8:17:f5:18:75:33:d4:d4:92:40:dd:1c:22:55:47:32:
e8:18:95:0d:b0:71:72:dd:32:1e:0d:b1:34:08:41:73:a2:06:
a7:be:bd:49:81:56:1b:7e:fd:23:36:be:d4:f3:58:4b:bb:b5:
39:16:4c:ef:0c:77:2b:f6:ec:7d:7a:9f:9b:16:7f:c1:6d:51:
9c:68:bf:c8:26:18:bc:5c:9d:df:16:87:e0:3d:84:59:d6:66:
72:ef:a0:57:5e:ca:01:31:41:a0:c7:77:7f:5c:09:ab:e0:be:
09:39:c0:37:1b:57:a5:82:aa:20:8f:0a:35:6a:86:c3:c8:8f:
ce:de:5d:39:cc:a2:90:25:5d:e2:7c:66:ed:10:ac:60:d3:31:
74:dc:1e:43:19:bd:df:e2:36:a4:d3:03:d6:ec:41:a8:b1:69:
28:7e:4f:d0:7d:7a:33:32:48:44:07:7d:74:4f:07:ce:da:54:
58:ad:c3:a5:f4:ee:ae:6b:8b:53:3b:2a:64:c6:c9:8d:40:38:
81:f0:d1:c5:fc:19:f0:06:de:96:b2:5b:6c:5d:52:37:d3:b5:
d2:f8:5f:87:7a:04:dd:0d:39:1e:4f:c4:8a:84:98:f9:9a:bc:
ba:15:36:08:52:ca:32:b8:67:94:73:e6:53:e5:53:11:48:90:
c3:a2:9f:e2
-----BEGIN CERTIFICATE-----
MIIEGTCCAwGgAwIBAgIDF10nMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTUwMzIyMjIwNzQ1
WhcNMTUwNTAyMDIxMjA1WjBuMQswCQYDVQQGEwJJTDExMC8GA1UEChMoU3RhcnRD
b20gTHRkLiAoU3RhcnQgQ29tbWVyY2lhbCBMaW1pdGVkKTEsMCoGA1UEAxMjU3Rh
cnRDb20gQ2xhc3MgMSBTZXJ2ZXIgT0NTUCBTaWduZXIwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC5VhtMRTGHFxeAhOluF43yJV4Y7Y2OzHwre1GmwcLm
vwqjYDBm8TL+EK6XtQ6Z+iS4P8U90nd0ljh9FOHDqbakkz4qwSQT0IVXCpW4FHQU
oLwAfHvPIiRG738aFW1+ocV3/F8PrN/ULrD1l0mQyy9c7+vO700b3HrlwQdcWpmp
MXHysIRbT/CGTpc/z+MvnXUR/4ej6UNBDJCkSTowa2lENZNAqcqW8CtmzmfwKN8p
gKaq7o1dXUUriw65P5I8weI/zMvb5//LEU0I+npqPEBPgl0aDnFZNc9iOox7WWcA
FO0GIvYImpRHp6GQEPf+WPhBKaJ2XqNngk0cO7L9owhTAgMBAAGjgaAwgZ0wCQYD
VR0TBAIwADALBgNVHQ8EBAMCA6gwHgYDVR0lBBcwFQYIKwYBBQUHAwkGCSsGAQUF
BzABBTAdBgNVHQ4EFgQUReCjZpVBTF3USbwA4zzc29I0PhcwHwYDVR0jBBgwFoAU
60I00Jiwq5/0G2sI98xkLu8OLEUwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQA/WfgX9Rh1M9TUkkDdHCJVRzLo
GJUNsHFy3TIeDbE0CEFzoganvr1JgVYbfv0jNr7U81hLu7U5FkzvDHcr9ux9ep+b
Fn/BbVGcaL/IJhi8XJ3fFofgPYRZ1mZy76BXXsoBMUGgx3d/XAmr4L4JOcA3G1el
gqogjwo1aobDyI/O3l05zKKQJV3ifGbtEKxg0zF03B5DGb3f4jak0wPW7EGosWko
fk/QfXozMkhEB310TwfO2lRYrcOl9O6ua4tTOypkxsmNQDiB8NHF/BnwBt6Wslts
XVI307XS+F+HegTdDTkeT8SKhJj5mry6FTYIUsoyuGeUc+ZT5VMRSJDDop/i
-----END CERTIFICATE-----
======================================
---
Certificate chain
0 s:/C=FR/CN=www.iperf.fr/emailAddress=postmaster@iperf.fr
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHLzCCBhegAwIBAgIDEObcMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTQwNjA0MjI0MTUy
WhcNMTUwNjA1MjM0MTIwWjBIMQswCQYDVQQGEwJGUjEVMBMGA1UEAxMMd3d3Lmlw
ZXJmLmZyMSIwIAYJKoZIhvcNAQkBFhNwb3N0bWFzdGVyQGlwZXJmLmZyMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA1+1nAcQOqasU1lBbU3DMOvwvKKlM
ha5j0mKf4QWPE2Ni2GVL3l79tRkb9sphcULjWtcObQ6mZdYjX0pFS8C6pN0Rz5/V
lrXjMC3Xyxf07H/ao3lRGgJOOT3JPBTtXApaZ4Ncxd+nURpen/+KtTadVe38T5Do
aaW/HWH5yKNwC3fKSnxxE8EdGFPKgl7nXVyw5wCDQ4YqmvC9XBX2Njk3re4qzafu
fZ30H8L724PAF75Or1emE85h5D7lFnVx0xPbAUV9K1ZASrPYa7u8fHw/xjGRXC+v
0SrdrZkRW7EbQlaeML1iHEzo2rSB+9ti1NHDrTpyboqtg/QA4Y0cxFu3RYMj6IKy
QEaQI6q9JnJeygemAvhyzEZp9HyZM6F7ZU6KOXBH5BqvdwJKBNp0Qy+vZFhGcRal
ecgR3cQpgqTW43rTIWsFPbqF3RD5L6nSc0DN4m2lo3gOOoZckQR34cOlX6pitqpj
fN4oee5qsuXJ3DxIrknBYaQHoQt334Y6XUQ4/58rfYq0pokXz65KcJy9N8dNc9vb
FYV9T9buILhRSfe2FSt7y/Dva16WdRivZXy6/WvIpFYVBcZ9z8XdNCO5wh6/QZJV
Xz8D2wF/27zOiqz0509jhTrPSJF30896HS9/Aci3GrVGWvqHP31KGS+AM/R86Bhx
/+CsOf19yKkb5fkCAwEAAaOCAtswggLXMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgOo
MBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBRRFMIjzrOMRzuvCRNWRYVI
91fMcjAfBgNVHSMEGDAWgBTrQjTQmLCrn/Qbawj3zGQu7w4sRTAhBgNVHREEGjAY
ggx3d3cuaXBlcmYuZnKCCGlwZXJmLmZyMIIBVgYDVR0gBIIBTTCCAUkwCAYGZ4EM
AQIBMIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3
LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy
dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZp
Y2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0
aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp
YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNl
IG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA1BgNVHR8ELjAsMCqg
KKAmhiRodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnQxLWNybC5jcmwwgY4GCCsG
AQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNv
bS9zdWIvY2xhc3MxL3NlcnZlci9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5z
dGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5zZXJ2ZXIuY2EuY3J0MCMGA1Ud
EgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOC
AQEAK4NOozk70hsdoZDO00YiW9QOt9oGIC3yeeimYEUrvL+d/whFRVg0yQqosmpc
eeniXLdx14TvIfZ3oPZKxTdTAoLyzKxLx2dwBYzbfc/LXn0oFjrAzxUDaHt8DroK
LJTwkVvxQXWkrTbwTSnqnZmkSQcTAxyUEaa4AaWIxKjz/hnWc70H+uv3wDM2t6fY
uxRM3Pgqm/ljvP2l5lTBKpcoyOu6wEHFldVx7KUtFpjNIQKoqTHbBcqP9RSc5Tf3
v0GJ//m+tMJ86+PrhwD1uformaRLn82SRo0w11oVz5IngBFZjIVRpxPVgQGFOdn3
iqj5rz0niiTcvDx9qXzOK7oL2w==
-----END CERTIFICATE-----
subject=/C=FR/CN=www.iperf.fr/emailAddress=postmaster@iperf.fr
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6038 bytes and written 461 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: EAEDCF6F751E4E2CC71A6220181492A65B30F0D4732443691632313816844DA5
Session-ID-ctx:
Master-Key: 4DB87E0551F55D17F2BC20542926083E30F25CD1B9BD6DA4FEFD0773F8093A59AD30077A0A7838AC374909FDECBBD42B
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f2 49 26 15 4d c7 25 4e-a1 36 a6 a8 98 0f 3d e9 .I&.M.%N.6....=.
0010 - bf e2 09 a8 96 b0 6a 01-bf 9c e4 72 0b 64 52 01 ......j....r.dR.
0020 - 2a e3 bd 6a b6 27 80 ff-e6 46 8b 84 d3 7c 6b f3 *..j.'...F...|k.
0030 - 09 86 e1 40 1c 03 45 90-6b 13 9a 3c f6 6e 26 27 ...@..E.k..<.n&'
0040 - 42 d3 ac f1 59 00 a3 72-f1 e3 91 1c 09 4e db d3 B...Y..r.....N..
0050 - 6e 76 76 27 21 58 0c 23-cb ad 8f 06 1d 47 91 c2 nvv'!X.#.....G..
0060 - f2 4b 7d 38 56 87 c0 c9-e0 60 48 c0 6a cc 51 ed .K}8V....`H.j.Q.
0070 - 95 90 12 55 99 9a 4f e9-8c da 36 75 f2 fc 60 d6 ...U..O...6u..`.
0080 - 17 e6 fe e1 cf 4f a0 87-2b 26 3c 3c ec 2f 2c 65 .....O..+&<<./,e
0090 - 54 49 33 c8 d9 d5 1c c5-16 0e 9a f9 34 67 77 01 TI3.........4gw.
00a0 - 6b 0f 86 50 1d 1a 7f ba-67 87 ee 10 92 0f 4f c6 k..P....g.....O.
00b0 - d0 c9 26 0f 9a f3 6f e5-ea d4 c2 16 a2 ec 3f f1 ..&...o.......?.
00c0 - 3b 32 0f ca a7 8f 41 2f-d9 94 67 fa d8 cc 04 4d ;2....A/..g....M
Start Time: 1429249071
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
-
J'ai oublié de préciser que j'ai eu plusieurs problèmess avec OCSP Stapling il y a deux ans, quand j'étais avec un certificat StartSSL.
Avec Let's Encrypt, je l'ai réactivé.
SSLUseStapling on
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)
Aujourd'hui accès impossible depuis Firefox :
(https://lafibre.info/images/ssl/201705_ocsp_error_1.png)
OpenSSL confirme :
$ openssl s_client -connect lafivbre.info:443 -status -servername lafibre.info
gethostbyname failure
connect:errno=0
SSL Labs met "OCSP ERROR: Exception: Read timed out [http://ocsp.int-x3.letsencrypt.org/]"
(https://lafibre.info/images/ssl/201705_ocsp_error_2.png)
ocsp.int-x3.letsencrypt.org est bien joignable, c'est Akamai qui le gère :
$ mtr -zrwc100 ocsp.int-x3.letsencrypt.org
Start: Fri May 19 13:43:48 2017
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 bgp1.adeli.biz 0.0% 100 0.5 1.6 0.2 68.0 7.3
2. AS??? e513-e-rbrrt-3-xe5.ipv6.cern.ch 0.0% 100 2.1 2.5 2.0 9.0 1.0
3. AS513 2001:1458:1:106::c05b:f4e6 0.0% 100 2.0 2.1 1.9 5.7 0.5
IPv4 en cas d'échec en IPv6 :
$ mtr -4zrwc100 ocsp.int-x3.letsencrypt.org
Start: Fri May 19 13:47:41 2017
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz 1.0% 100 0.2 1.0 0.2 31.2 3.3
2. AS174 gi0-0-0-16.219.agr12.lys01.atlas.cogentco.com 0.0% 100 8.3 8.3 8.2 8.7 0.0
3. AS174 te0-0-1-6.rcr21.lys01.atlas.cogentco.com 0.0% 100 8.3 8.2 8.0 9.3 0.1
4. AS174 be2471.ccr41.par01.atlas.cogentco.com 0.0% 100 8.1 8.1 7.9 9.3 0.2
5. AS174 be3183.ccr31.par04.atlas.cogentco.com 0.0% 100 7.7 7.9 7.6 8.6 0.0
6. AS174 telecomitalia.par04.atlas.cogentco.com 4.0% 100 8.0 9.8 7.6 64.2 8.0
7. AS6762 ae1.parigi16.par.seabone.net 0.0% 100 8.3 8.5 8.2 22.7 1.4
8. AS6762 5.178.43.32 0.0% 100 8.2 8.1 8.1 8.4 0.0
Un restart du serveur ne change rien, alors que dans le passé cela permettais de recharger.
Bref, j'ai de nouveau désactivé OCSP Stapling.
-
Let's Encrypt est cassé depuis ce matin : http://letsencrypt.status.io/
(https://lafibre.info/images/ssl/201705_ocsp_error_3.png)
-
Tu peux réactiver OCSP Stapling, ce n'est pas la cause de ton souci :)
D'ailleurs sur ta conf SSLLabs, on voit bien que le stapling est désactivé, tu devrais verifier ta config !
-
J'ai désactivé OCSP Stapling et il ne faut pas que je le ré-active tant que le bug OCSP Service Disruption (cf http://letsencrypt.status.io/) n'est pas résolut.
La désactivation d' OCSP Stapling permets aux clients Frirefox de consulter de nouveau le site.
-
La désactivation d' OCSP Stapling permets aux clients Frirefox de consulter de nouveau le site.
C'est de la poudre de perlimpinpin, l'incident existe toujours, il concerne juste un peu moins de monde.
-
Je ne résout pas le pb pour les autres sites concernés (attention, même si le service OCSP Stapling est entièrement tombé, seuls les sites qui ont demandé le renouvellement sont impactés)
Par contre cela résout le pb pour mon serveur.
iperf.fr, est lui aussi avec OCSP Stapling avec Let's Encrypt et il n'est pour le moment pas impacté :
$ openssl s_client -connect iperf.fr:443 -status -servername iperf.fr
CONNECTED(00000003)
OCSP response: no response sent
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = iperf.fr
verify return:1
---
Certificate chain
0 s:/CN=iperf.fr
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIDCCBAigAwIBAgISA+98NKHhFn0XUXihJMxZ/I3sMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA1MTQxMDU4MDBaFw0x
NzA4MTIxMDU4MDBaMBMxETAPBgNVBAMTCGlwZXJmLmZyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAyaS7UG2dHdGoYucb3Vc8jKUT8CFH6b8uQ2cusm3A
hfoz5Ytf5vSOUGQRQxGxGYoaNsL5BbrYc6ZQfM0Z7j/Jvy7EISJ80g+lXBDgwaR8
XvO3FwY4kHlPVPQunxvG+4XI77hIpz//HWu2otxKE3st672ui67+SAXP/NPoej/o
Y5agiiwteRoKSnJi8OEd4jJHnsDxQyLm8+Q9PaKvCzEDQZyAvEz+Lu3JjoSCy/Gl
cmELl36fUkLihTN2N5tyL5uw9/p8x9aFk5Q5Asu+bt1gnCITjXUzrBYuKCHITJhH
yy4jBZHc5c2rQoI3dUAJuvQsPBVpDRdZUDIrlzj1ciNkOwIDAQABo4ICNTCCAjEw
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAM
BgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSACwEO9agPJqdsCRBYiW5NzEr2KDAfBgNV
HSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBwBggrBgEFBQcBAQRkMGIwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5vcmcvMC8G
CCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5cHQub3JnLzA/
BgNVHREEODA2gghpcGVyZi5mcoINaXB2NC5pcGVyZi5mcoINaXB2Ni5pcGVyZi5m
coIMd3d3LmlwZXJmLmZyMIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEE
AYLfEwEBATCB1jAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5v
cmcwgasGCCsGAQUFBwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBi
ZSByZWxpZWQgdXBvbiBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNj
b3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0
cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQAD
ggEBAI87Sn0TukwTiev+rZRem3Vmq92qzponIad/GMxqdhFiVVvozJ8KoUuFPv76
Ohclc1kHlpojuWWQPj2lMjy3iJZeZDc35IjIBbwtD2jEDZeHtgPEphU2v6KHHKc7
VZmS7Zv406rdSAs8zGw7yFJWdoZRuAQXr2USLZqgoBDf0h1L9jTjUtb/eDyhu1c1
6qM488SXv1qHgZqBIyI5Zzyq/wVexahasMiUbetPoz+fJojsVF690iHuvXE6YeV5
HsvCSx6Jf7d9py9ebvrjQpLZcN0nZxX/vpTMx24tF+Qo6pi9O00YUm2HlhHbFV4K
47EcezYnr1gozFOwyliqvMiaGFQ=
-----END CERTIFICATE-----
subject=/CN=iperf.fr
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3188 bytes and written 457 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 934B3587359851ECE1F1952B7532A00E9D6819A493D4113C0C5DABF926A5B527
Session-ID-ctx:
Master-Key: 7CD0F4EE10700CAE9CFB27720B1EA19A00D6E05B7849E016FADBBAEBB59CB8F20B0C8EE2D6AB71983483DA6263D66E12
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 15 6e cc 64 75 83 36 40-71 d3 25 c8 74 27 ae 7c .n.du.6@q.%.t'.|
0010 - 0d 5e 0c a8 8a 43 b7 c9-6d ed 95 40 c8 08 e0 de .^...C..m..@....
0020 - 9f 6c 86 fd 05 62 b4 f3-ff dc 9e e1 3c 0a e7 ab .l...b......<...
0030 - f1 89 7a e3 de 7a 60 10-86 c3 3f c5 65 25 f4 b3 ..z..z`...?.e%..
0040 - 17 3f a7 b5 f1 d7 1b 75-3b 49 83 cd d1 2e d9 8e .?.....u;I......
0050 - a8 09 8a 16 9b 49 59 3a-28 5e 8c 43 c6 07 85 20 .....IY:(^.C...
0060 - 17 71 a9 50 fb 13 fe e1-19 1e 0e 15 45 c8 6b 40 .q.P........E.k@
0070 - e4 9c 55 b6 76 fb 0e cf-ee 50 c3 09 74 1c d2 33 ..U.v....P..t..3
0080 - 22 5f 12 a7 29 47 3b 25-95 e4 60 fc 00 ab ff 5e "_..)G;%..`....^
0090 - 97 39 00 dc 3e 96 6a 77-39 b9 63 af 9d f9 72 2f .9..>.jw9.c...r/
00a0 - b8 a1 68 a7 f0 c7 33 05-79 e7 64 c9 5d 87 e5 58 ..h...3.y.d.]..X
00b0 - 98 25 1b b4 67 62 39 95-d7 c1 fc 2d a8 8c ee be .%..gb9....-....
Start Time: 1495197647
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
-
Let's Encrypt est cassé depuis ce matin : http://letsencrypt.status.io/
C'est résolut, j'ai ré-activé OCSP Stapling sur LaFibre.info et cela fonctionne.
$ openssl s_client -connect lafibre.info:443 -status -servername lafibre.info
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = lafibre.info
verify return:1
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: May 19 11:58:00 2017 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 03172E2CD17A1C60971E12C4C08FEC3A915A
Cert Status: good
This Update: May 19 11:00:00 2017 GMT
Next Update: May 26 11:00:00 2017 GMT
Signature Algorithm: sha256WithRSAEncryption
1f:13:bd:80:53:18:bf:ac:a0:c1:c8:e0:de:b5:09:46:29:65:
29:25:10:aa:d1:3a:91:06:37:d1:6c:d7:9d:7e:e7:33:07:1e:
02:c2:0f:9d:8b:83:fe:32:d6:e5:71:b1:04:b4:04:0e:3b:55:
5e:91:c5:bb:23:e9:59:f0:a2:db:8f:1e:35:55:50:73:1e:1f:
ef:7a:5d:b7:29:4b:a0:c2:52:e7:da:71:5a:08:14:82:eb:65:
ed:95:c4:63:73:27:f5:9a:93:6c:f4:6d:ba:52:96:9d:ef:4b:
ea:ca:b4:b3:15:81:76:28:ac:8e:11:b7:4f:9d:4a:c6:cd:a9:
54:17:0b:8e:b1:55:0f:dd:b4:bc:5c:48:9f:36:7f:d8:32:df:
ad:2f:dc:59:ee:3c:e3:38:f0:7c:30:a7:e7:cd:b0:a9:2e:2b:
5e:61:69:de:ce:a5:36:ca:7a:a1:47:68:b2:69:33:b1:b6:48:
6d:76:30:8c:29:ea:81:94:dc:72:63:f7:cf:2f:e3:f8:b3:f2:
29:c0:26:03:dc:af:35:7b:de:88:c1:54:f5:a8:ab:47:a4:46:
40:c4:b7:19:58:ac:32:c2:f7:a8:74:81:70:f2:8f:c2:fe:68:
f0:5b:22:5a:6c:aa:e4:0e:e4:3f:20:4a:5e:a8:8d:a5:54:28:
fb:32:a3:f2
======================================
---
Certificate chain
0 s:/CN=lafibre.info
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFzjCCBLagAwIBAgISAxcuLNF6HGCXHhLEwI/sOpFaMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA1MTYxMDU3MDBaFw0x
NzA4MTQxMDU3MDBaMBcxFTATBgNVBAMTDGxhZmlicmUuaW5mbzCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANvM6Id3Z4n1nzTW1VyJ1drUxT/XfKAAX72z
i1Psa0vp0qKF2RNkqX3008V0N7JDq00TNgpyUq1UdZFIfRY/jKnXsX4CRLTl8pfW
MJZnJPFHt34BgJmKMU75yzcNIltzBGho8OBXoY+zmubBgYi6IKENCvP01VcKh49I
cT8kuCsQiP4gtTXClQa1soggMxVG0nVkqcnBbVPoRd1cVN60C0rSpINNeKlYG/ZA
BCA6puZFJGczHAD0lPnQZLOX2wcX4yvL9Ib2Ag1UWIZya2eH0nlx0mSRAZmvl/T0
GbUz2VCWh35bxZ/wcK4YMLgKIjrd1Duf017Se6fR5rFtyb6GknsCAwEAAaOCAt8w
ggLbMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU3W6Vv21nhvlzOf2NoCEapz5EQZkw
HwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEwcAYIKwYBBQUHAQEEZDBi
MC8GCCsGAQUFBzABhiNodHRwOi8vb2NzcC5pbnQteDMubGV0c2VuY3J5cHQub3Jn
LzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wgegGA1UdEQSB4DCB3YIPaXAubGFmaWJyZS5pbmZvghNpcHY0LWMubGFmaWJy
ZS5pbmZvghZpcHY0LWpzb24ubGFmaWJyZS5pbmZvghFpcHY0LmxhZmlicmUuaW5m
b4IVaXB2NHY2LWMubGFmaWJyZS5pbmZvghNpcHY0djYubGFmaWJyZS5pbmZvghNp
cHY2LWMubGFmaWJyZS5pbmZvghZpcHY2LWpzb24ubGFmaWJyZS5pbmZvghFpcHY2
LmxhZmlicmUuaW5mb4IMbGFmaWJyZS5pbmZvghB3d3cubGFmaWJyZS5pbmZvMIH+
BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEF
BQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGe
DIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBS
ZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBD
ZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5v
cmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBADP+jtRsBUSKcczHRqt6
+qj67RskdGOswxM/sXXf0pDgHx2gzCTPoQQwx/pagXxK8SKusnTEyimj1dwToKAE
kYWPMNP1RfmbWMZ2tWfPYO27YD1q83v05gLfQRJw9DlxZ+RtUvaJi+UE8rmV5P74
stMqHsxyxqtmDA3egOIGOTn7NA+qEzTFkcxG5/v5YprHisScM7AWq52zgofVLXLG
9fJbOucRSWdVjT0EN4WibNZM1h2rJx3+N//6ALRVMZ9NWfYFOmu3qqXx8P24MdB4
S1tBBgVNNPYLVzxwXNWMmxzFxXosezBYsSzcE3aMgBun5rYdfoDb6uG6iq0opPoo
kvM=
-----END CERTIFICATE-----
subject=/CN=lafibre.info
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3922 bytes and written 461 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: B4B15FE5A07E503A85C891C9CA5A30F3291C0171B4C439025A7C71FC25014B56
Session-ID-ctx:
Master-Key: AE3057F21CA802C45E8DC7DB0CEECE7B9267938B1BBE90D67967DB9AD6A01CDF773E20232F9E8653F0146289D7E547B4
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 8b 4d fb 6f de 06 8b 73-83 48 94 cf 8c 85 fb 9b .M.o...s.H......
0010 - 08 5b 38 60 80 2a d0 18-78 14 74 eb 13 97 4c 0f .[8`.*..x.t...L.
0020 - 45 eb 4c da 97 f7 c0 9a-44 bd 1a b9 82 92 f6 1f E.L.....D.......
0030 - 80 a6 a7 d0 83 2b 91 f6-0c ed af c1 91 86 c6 fd .....+..........
0040 - b0 40 28 c5 e5 4e 30 66-5f 76 7c 99 f9 ab ad 8a .@(..N0f_v|.....
0050 - 12 82 01 2b 77 61 b4 b7-a5 66 c6 dd f2 d5 0b d7 ...+wa...f......
0060 - d2 40 28 5f 93 0a 32 87-6f 1b f3 60 fa 7d 54 98 .@(_..2.o..`.}T.
0070 - ae b2 ba 50 81 7b cf 47-e0 1c 3a 25 1c 68 67 c2 ...P.{.G..:%.hg.
0080 - 6f 83 96 9e 47 38 01 a0-66 92 8a d8 96 6f f5 11 o...G8..f....o..
0090 - aa b2 b9 29 d3 36 b1 e7-e9 23 bd 5e e9 26 50 ad ...).6...#.^.&P.
00a0 - 55 3a 48 86 26 cd 53 dc-04 97 f2 40 91 3a 53 07 U:H.&.S....@.:S.
00b0 - 1e d5 16 e8 d9 c0 90 62-46 09 45 83 3c 74 6f 60 .......bF.E.<to`
00c0 - 2f 7d e6 bf 9b 60 ee 05-bb 52 55 7a 81 54 5f 1d /}...`...RUz.T_.
Start Time: 1495204479
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
HTTP/1.1 400 Bad Request
Date: Fri, 19 May 2017 14:34:45 GMT
Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
read:errno=0
-
Le serveur de renouvellement acme ne fonctionne toujours pas...
Et comme j'ai mis du HSTS sur mon Apache, ya plus de site...
-
Le serveur de renouvellement acme ne fonctionne toujours pas...
Et comme j'ai mis du HSTS sur mon Apache, ya plus de site...
T'as laissé ton certificat s'expirer ? :o faut toujours prendre quelques jours de marge et pas renouveller dans la dernière heure !
-
Le certificat se renouvelle automatiquement un mois avant l'expiration.
Si vous avez du mal avec le renouvellement automatique, je peux aider.
-
Voici un article (https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html) qui explique que Apache et nginx n'implemente pas correctement l'OCSP Stapling.
L’implèmentation serveur doit mettre en cache la réponse OCSP valide (en la renouvelant dès que possible).
L'auteur de l'article conseille la configuration suivante pour Apache afin de limiter les dégâts:
SSLStaplingCache shmcb:/var/tmp/ocsp-stapling-cache/cache(128000000)
SSLUseStapling on
SSLStaplingResponderTimeout 2
SSLStaplingReturnResponderErrors off
SSLStaplingFakeTryLater off
SSLStaplingStandardCacheTimeout 86400
-
/me note une raison supplèmentaire de jeter apache à la poubelle
-
Apache et nginx n'implemente pas correctement l'OCSP Stapling.
/me tend une paire de lunettes à Jack
;)
-
Tu peux ensuite lire le document en question et te ranger à mon avis :)
-
Nginx sends out the first reply after startup WITHOUT a stapled OCSP response included. It notices afterwards that it didn't and initiates a lazy OCSP query. At some point in the future it'll include them.
Tes n premiers clients vont se prendre un blocage avec Firefox ...
Tu trouve ce comportement meilleur ?
-
s/Tes n premiers clients vont se prendre un blocage avec Firefox .../Ta première connexion va être problématique si le client est Firefox/
100ms avant, c'était un connexion refused, ne l'oublions pas.
-
Tu peux ensuite lire le document en question et te ranger à mon avis :)
Bof, tu connais mon avis sur nginx.
-
Très bel article sur le Hanno' blog (https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html).
Voici après une traduction rapide en Français: (et il donne les commandes à rajouter dans /etc/apache2/mods-available/ssl.conf pour avoir avec Apache un site qui fonctionne systématiquement, même en cas de panne du serveur OCSP Stapling (OCSP Stapling sera alors désactivé - ok ce n'est pas idéal comme comportement mais cela évite ce qui s'est passé sur LaFibre.info hier)
Le problème avec OCSP Stapling, ou pourquoi la révocation d'un certificat n'est pas fiable
Aujourd'hui , les serveurs OCSP de Let’s Encrypt étaient hors-ligne pendant un certain temps. Cela a causé beaucoup plus de problèmes qu'il ne l'aurait dû, car en théorie, nous avons toutes les technologies disponibles pour gérer un tel incident. Cependant, en raison des échecs dans la façon dont ils sont mis en œuvre, ils ne fonctionnent pas vraiment.
Nous devons comprendre certains antécédents. Les connexions cryptées utilisant le protocole TLS, comme les certificats HTTPS. Ce sont essentiellement des clés publiques cryptographiques, avec une déclaration signée d'une autorité de certification qui appartiennent à un certain nom d'hôte.
CRL et OCSP - deux technologies qui ne fonctionnent pas.
Les certificats peuvent être révoqués. Cela signifie que, pour une raison quelconque, le certificat ne devrait plus être utilisé. Un scénario typique est lorsque le propriétaire d'un certificat apprend que ses serveurs ont été piratés et que leurs clés privées ont été volées. Dans ce cas, il est bon d'éviter que les clés volées et leurs certificats correspondants puissent encore être utilisés. Par conséquent, un client TLS comme un navigateur devrait vérifier qu'un certificat fourni par un serveur n'est pas révoqué.
C'est au moins la théorie. Cependant, l'historique de la révocation des certificats est une histoire de deux technologies qui ne fonctionnent pas vraiment.
Une méthode pour vérifier si un certificat est révoqué est la certificate revocation lists (CRL). C'est assez simple: une autorité de certification fournit une liste de certificats qui sont révoqués. Cela a une limitation évidente: ces listes sont de grande taille. Étant donné qu'une vérification de révocation doit se produire au cours d'une connexion, il est évident que cela n'est pas réalisable de télécharge la liste complète.
La deuxième méthode s'appelle OCSP (Online Certificate Status Protocol). Ici, un client peut interroger un serveur sur l'état d'un certificat unique et obtenir une réponse signée. Cela évite le problème de taille des CRL, mais il a encore un certain nombre de problèmes. Étant donné que les connexions devraient être rapides, il est très coûteux (en temps) pour un client de se connecter à un serveur OCSP pendant chaque connexions. Cela pose également des problèmes pour la confidentialité : L'opérateur d'un serveur OCSP récupère beaucoup d'informations.
Cependant, il y a un problème plus grave: que se passe-t-il si un serveur OCSP n'est pas disponible? Du point de vue de la sécurité, on pourrait dire qu'un certificat qui ne peut pas être vérifié OCSP doit être considéré comme non valide. Cependant, les serveurs OCSP sont trop peu fiables. Donc, pratiquement tous les clients implèmentent OCSP en mode soft fail (ou pas du tout). L'échec doux signifie que si le serveur OCSP n'est pas disponible, le certificat est considéré comme valide.
Cela rend tout le concept OCSP inutile: si un attaquant essaie d'abuser d'un certificat volé et révoqué, il peut simplement bloquer la connexion au serveur OCSP - et donc un client ne peut pas apprendre qu'il est révoqué. En raison de cette panne de sécurité inhérente, Chrome a décidé de désactiver totalement le contrôle OCSP (https://www.imperialviolet.org/2012/02/05/crlsets.html). Comme solution de contournement, ils ont quelque chose appelé CRLsets et Mozilla a quelque chose de similaire appelé OneCRL (https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/), qui est essentiellement une grande liste de révocation, pour les révocations importantes gérées par le fournisseur du navigateur. Toutefois, il s'agit d'une solution de contournement faible qui ne couvre pas la plupart des certificats.
L'agrafage OCSP (en anglais : OCSP Stapling) à la rescousse
Il existe deux technologies qui pourraient résoudre ceci: OCSP Stapling (agrafage OCSP en Français) et OSCP Must-Staple.
OCSP Stapling déplace l'interrogation du serveur OCSP du client vers le serveur web. Le serveur web obtient les réponses OCSP puis les envoie dans la poignée de main TLS. Cela présente plusieurs avantages: il y a un gain important de latence en évitant pluisuers aller/retour et un gain de confidentialité. Cela permet également de survivre aux courts arrêts des serveurs OCSP, car un serveur web TLS peut mettre en cache les réponses OCSP (elles sont habituellement valides pendant plusieurs jours).
Cependant, cela ne résout pas encore le problème de sécurité: si un attaquant a un certificat volé et révoqué, il lui suffit de ne pas mettre l'agrafage OSCP. Le navigateur ne le saurera pas et interroge le serveur OCSP directement, cette demande peut encore être bloquée par l'attaquant et le navigateur acceptera le certificat.
Par conséquent, une extension pour les certificats a été introduite qui nous permet d'exiger l'agrafage OSCP. Il est généralement appelé OCSP Must-Staple et est défini dans la RFC 7633 (https://tools.ietf.org/html/rfc7633) (bien que la RFC ne mentionne pas le nom OSCP Must-Staple, ce qui peut causer une certaine confusion). Si un navigateur voit un certificat avec l'extension OCSP Must-Staple, qui est utilisé sans OCSP Stapling, il ne doit pas l'accepter.
Nous devrions donc être bien. Avec OCSP Stapling, nous pouvons éviter les problèmes de latence et de confidentialité de OCSP et nous pouvons éviter d'échouer, lorsque les serveurs OCSP ont des temps d'arrêt courts. Avec OCSP Must-Staple, nous réparons les problèmes de sécurité. Plus de problème logiciel, n'est-ce pas ?
Les implèmentations OCSP Stapling d'Apache et Nginx sont incorrectes.
Eh bien, voici les implèmentations. Bien que beaucoup de protocoles utilisent TLS, le cas d'utilisation le plus courant est le Web et HTTPS. Selon les statistiques html de Netcraft (https://news.netcraft.com/archives/2017/04/21/april-2017-web-server-survey.html), la plus grande partie des sites actifs sur Internet utilisent le servuer web Apache (environ 46%), suivi de Nginx (environ 20%). côté du serveur, ce n'est que l'agrégation OCSP Stapling, car OCSP Must Staple doit uniquement être vérifié par le client.
Qu'attendez-vous d'une implèmentation OPSP Stapling opérationnelle ? Elle devrait essayer d'éviter une situation où il n'est pas possible d'envoyer une réponse OCSP valide. Ainsi, un serveur web devrait récupérer une réponse OCSP valide dès que possible et la mettre en cache jusqu'à ce qu'il en voie une nouvelle (ou qu'elle expire). Le serveur web devrait en outre essayer d'obtenir une nouvelle réponse OCSP bien avant que l'ancienne expire (idéalement plusieurs jours). Autre chose : il ne faut jamais jeter une réponse OSCP valide, à moins que le serveur web en ait récupéré une nouvelle qui est valide. Le développeur de Google, Ryan Sleevi, a écrit une description détaillée de la façon dont une implèmentation OCSP Stapling appropriée devrait ressembler (https://gist.github.com/sleevi/5efe9ef98961ecfb4da8).
Le serveur web Apache ne fait rien de tout cela.
Si Apache essaie de renouveler la réponse OCSP et obtient une erreur du serveur OCSP - par exemple, parce qu'il ne fonctionne pas actuellement - il éliminera la réponse OCSP actuelle et toujours valide pour la remplacera par l'erreur. Il enverra ensuite des erreurs OCSP agrafées, ce qui n'a aucun sens. Dans ce cas là, Firefox affichera une erreur et bloquera le chargement du site. Cela a été signalé en 2014 et n'est toujours pas fixé (https://bz.apache.org/bugzilla/show_bug.cgi?id=57121).
Maintenant, il existe une option dans Apache pour éviter ce comportement: SSLStaplingReturnResponderErrors (https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingreturnrespondererrors). Il est par défaut. Si vous l'éteignez (off), vous n'obtiendrez pas un comportement sain (c'est-à-dire utiliser la réponse en cours encore en cours) : Apache désactive l'agrafage tant qu'il reçoit des erreurs du serveur OCSP. C'est mieux que d'envoyer des erreurs, mais évidemment, il faut désactiver OCSP Must Staple.
Cela devient encore plus fou. J'ai réglé SSLStaplingReturnResponderErrors (https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingreturnrespondererrors) à off, mais ce matin, j'ai toujours des plaintes d'utilisateurs de Firefox, voyaient des erreurs. C'est parce que dans ce cas, le serveur OCSP n'èmettait pas d'erreurs, il était complètement indisponible. Pour cette situation, Apache dispose d'une fonctionnalité qui va envoyer une erreur "tryLater" au client. Cela n'a aucun sens: l'erreur "tryLater" d'OCSP est inutile dans TLS, car vous ne pouvez pas essayer plus tard (la poignée de main qui ne peut pas dépasser quelques secondes).
Ceci est contrôlé par une autre option: SSLStaplingFakeTryLater (https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingfaketrylater). Cependant, la documentation dit: "Uniquement efficace si SSLStaplingReturnResponderErrors (https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingreturnrespondererrors) est également activé." Donc, si nous avons désactivé SSLStaplingReturnResponderErrors (https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingreturnrespondererrors), cela ne devrait pas fonctionner, n'est-ce pas? Eh bien: la documentation est incorrecte.
Il y a encore d'autres problèmes: Apache n'obtient pas les réponses OCSP lors du démarrage, il ne les récupère que pendant la poignée de main. Cela provoque une latence supplèmentaire sur la première connexion et augmente le risque d'arriver dans une situation où vous n'avez pas une réponse OCSP valide. Les réponses OCSP mises en cache ne survivent pas aux redémarrages du serveur, elles sont conservées dans un cache en mémoire.
Il n'existe actuellement aucun moyen de configurer Apache pour gérer implèmentation OCSP Stapling appropriée. Voici la configuration Apache que j'utilise, qui s'assurera au moins que cela n'èmettra pas d'erreurs et mettra en cache les réponses un peu plus longtemps que par défaut:
SSLStaplingCache shmcb:/var/tmp/ocsp-stapling-cache/cache(128000000)
SSLUseStapling on
SSLStaplingResponderTimeout 2
SSLStaplingReturnResponderErrors off
SSLStaplingFakeTryLater off
SSLStaplingStandardCacheTimeout 86400
Je suis moins familier avec le serveur web Nginx, mais de ce que j'entends, ce n'est pas beaucoup mieux. Selon blog.crashed.org (https://blog.crashed.org/nginx-stapling-busted/), il ne récupère pas les réponses OCSP au démarrage et enverra les premières connexions TLS sans agrafage OCSP Staging, même si OCSP Staging est activé. Voici une publication sur le blog qui recommande de contourner cela en se connectant à tous les hôtes configurés après le démarrage du serveur (https://unmitigatedrisk.com/?p=241).
Pour résumer: c'est tout un gros désordre. Les serveurs web Apache et Nginx ont tous deux des implèmentations OCSP Staging qui sont incomplètes. Tant que vous utilisez l'un ou l'autre, le fait d'activer OCSP Must-Staple est un moyen de vous tirer sur le pied et d'avoir des problèmes. Ne l'activez pas, si vous prévoyez d'utiliser Apache ou Nginx.
La révocation d'un certificat n'est pas fiable. C'est le cas depuis l'invention de SSL et c'est encore le cas aujourd'hui. OCSP Stapping et OCSP Must-Staple devrait permettre de fiabiliser les révocations, mais cela nécessiterait des implèmentations fonctionnelles et stables dans les produits serveur les plus utilisés.
Source : Hanno' blog (https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html), le 19 mai 2017. Traduit de l'Anglais par Vivien Guéant.
-
Ce que j'ai rajouté dans /etc/apache2/mods-available/ssl.conf pour un Ubuntu server avec Apache 2.4 : (pour rappel, le module mod_socache_shmcb doit être chargé pour activer l'OCSP Stapling)
SSLUseStapling on
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)
SSLStaplingResponderTimeout 2
SSLStaplingReturnResponderErrors off
SSLStaplingFakeTryLater off
SSLStaplingStandardCacheTimeout 86400
Liens vers la documentation en français d’Apache 2.4 :
SSLUseStapling on
=> https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslusestapling
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)
=> https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingcache
SSLStaplingResponderTimeout 2
=> https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingrespondertimeout
SSLStaplingReturnResponderErrors off
=> https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingreturnrespondererrors
SSLStaplingFakeTryLater off
=>https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingfaketrylater
SSLStaplingStandardCacheTimeout 86400
=> https://httpd.apache.org/docs/current/fr/mod/mod_ssl.html#sslstaplingstandardcachetimeout