Bonjour à tous,
J'essaye de comprendre quelque chose à une histoire de HTTPS et de
certifs mais j'ai du mal. Voici deux urls :
- https://test1.electionspro2018.ac-versailles.fr/sympa
- https://test1.syndicat.ac-versailles.fr/sympa
Normalement, les deux fonctionnent avec un navigateur Web. Perso,
c'est le cas sur ma Ubuntu 18.04 avec mon Firefox (version 62.0.3
dans mon cas).
Par contre, toujours sur ma Ubuntu, si je teste avec curl (version
7.58.0) en ligne de commandes alors là, j'ai un problème SSL avec la
deuxième URL :
---------------------------------------------------------------
~$ curl -I https://test1.electionspro2018.ac-versailles.fr/sympa
HTTP/1.1 200 OK
Date: Fri, 12 Oct 2018 22:23:50 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_fcgid/2.3.9
Cache-control: max-age=0
X-UA-Compatible: IE0
Content-Type: text/html; charset=utf-8
Set-Cookie: sympa_session 0cfce901ccad6b3b1bc78b4878c614c5; path=/; HttpOnly
Connection: close
# Paf !
~$ curl -I https://test1.syndicat.ac-versailles.fr/sympa
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
---------------------------------------------------------------
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Mais mon incompréhension ne s'arrête pas là. Si je regarde avec Firefox
les certifs utilisés par ces deux pages, je constate que ce n'est certes pas
les mêmes certifs d'une url à l'autre mais par contre la chaîne de certifs
est exactement la même, à savoir :
* DigiCert Assured ID Root CA
* TERENA SSL CA 3
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
Bonjour à tous,
J'essaye de comprendre quelque chose à une histoire de HTTPS et de
certifs mais j'ai du mal. Voici deux urls :
- https://test1.electionspro2018.ac-versailles.fr/sympa
- https://test1.syndicat.ac-versailles.fr/sympa
Normalement, les deux fonctionnent avec un navigateur Web. Perso,
c'est le cas sur ma Ubuntu 18.04 avec mon Firefox (version 62.0.3
dans mon cas).
Par contre, toujours sur ma Ubuntu, si je teste avec curl (version
7.58.0) en ligne de commandes alors là, j'ai un problème SSL avec la
deuxième URL :
---------------------------------------------------------------
~$ curl -I https://test1.electionspro2018.ac-versailles.fr/sympa
HTTP/1.1 200 OK
Date: Fri, 12 Oct 2018 22:23:50 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_fcgid/2.3.9
Cache-control: max-age=0
X-UA-Compatible: IE0
Content-Type: text/html; charset=utf-8
Set-Cookie: sympa_session 0cfce901ccad6b3b1bc78b4878c614c5; path=/; HttpOnly
Connection: close
# Paf !
~$ curl -I https://test1.syndicat.ac-versailles.fr/sympa
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
---------------------------------------------------------------
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Mais mon incompréhension ne s'arrête pas là. Si je regarde avec Firefox
les certifs utilisés par ces deux pages, je constate que ce n'est certes pas
les mêmes certifs d'une url à l'autre mais par contre la chaîne de certifs
est exactement la même, à savoir :
* DigiCert Assured ID Root CA
* TERENA SSL CA 3
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
Bonjour à tous,
J'essaye de comprendre quelque chose à une histoire de HTTPS et de
certifs mais j'ai du mal. Voici deux urls :
- https://test1.electionspro2018.ac-versailles.fr/sympa
- https://test1.syndicat.ac-versailles.fr/sympa
Normalement, les deux fonctionnent avec un navigateur Web. Perso,
c'est le cas sur ma Ubuntu 18.04 avec mon Firefox (version 62.0.3
dans mon cas).
Par contre, toujours sur ma Ubuntu, si je teste avec curl (version
7.58.0) en ligne de commandes alors là, j'ai un problème SSL avec la
deuxième URL :
---------------------------------------------------------------
~$ curl -I https://test1.electionspro2018.ac-versailles.fr/sympa
HTTP/1.1 200 OK
Date: Fri, 12 Oct 2018 22:23:50 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_fcgid/2.3.9
Cache-control: max-age=0
X-UA-Compatible: IE0
Content-Type: text/html; charset=utf-8
Set-Cookie: sympa_session 0cfce901ccad6b3b1bc78b4878c614c5; path=/; HttpOnly
Connection: close
# Paf !
~$ curl -I https://test1.syndicat.ac-versailles.fr/sympa
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
---------------------------------------------------------------
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Mais mon incompréhension ne s'arrête pas là. Si je regarde avec Firefox
les certifs utilisés par ces deux pages, je constate que ce n'est certes pas
les mêmes certifs d'une url à l'autre mais par contre la chaîne de certifs
est exactement la même, à savoir :
* DigiCert Assured ID Root CA
* TERENA SSL CA 3
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
SSLLabs dit qu'il manque un certificat intermédiaire :
https://www.ssllabs.com/ssltest/analyze.html?d=test1.syndicat.ac-versailles.fr&hideResults=on
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Hypothèse (pas fait de test) : Firefox a peut-être déjà le certificat TERENA dans son cache
suite à la visite du 1er site.
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
Parce qu'il manque un certificat.
Tester avec openssl :
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
SSLLabs dit qu'il manque un certificat intermédiaire :
https://www.ssllabs.com/ssltest/analyze.html?d=test1.syndicat.ac-versailles.fr&hideResults=on
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Hypothèse (pas fait de test) : Firefox a peut-être déjà le certificat TERENA dans son cache
suite à la visite du 1er site.
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
Parce qu'il manque un certificat.
Tester avec openssl :
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
SSLLabs dit qu'il manque un certificat intermédiaire :
https://www.ssllabs.com/ssltest/analyze.html?d=test1.syndicat.ac-versailles.fr&hideResults=on
Déjà ma première question est : pourquoi tout marche avec Firefox alors que,
avec curl sur le _même_ OS, une des urls plante ?
Hypothèse (pas fait de test) : Firefox a peut-être déjà le certificat TERENA dans son cache
suite à la visite du 1er site.
Du coup, ma deuxième question est : sachant que les deux certifs des deux
urls utilisent exactement la même chaîne de certificats, comment il est
possible que curl plante pour l'url 2 mais pas pour l'url 1 ?
Parce qu'il manque un certificat.
Tester avec openssl :
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
Ok, c'est sûrement un truc comme ça. En fait, je pense que c'est au
delà du cache. Sur mon Firefox, je vide le cache à chaque fermeture
et je supprime tout ce qui est possible (j'ai coché toutes les cases)
et mon Firefox semble stocker pourtant le certificat "TERENA SSL CA 3"
de manière _permanente_.
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Ok, je crois qu'il manque l'option -connect juste avant le « fqdn:port »
mais merci beaucoup car ça m'a fait découvrir l'option -showcerts qui
met bien en évidence le certificat manquant (et sans passer par SSL Lab
du coup).
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
Arf, c'est possible que ce ne soit pas au top de la sécu...
Ok, c'est sûrement un truc comme ça. En fait, je pense que c'est au
delà du cache. Sur mon Firefox, je vide le cache à chaque fermeture
et je supprime tout ce qui est possible (j'ai coché toutes les cases)
et mon Firefox semble stocker pourtant le certificat "TERENA SSL CA 3"
de manière _permanente_.
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Ok, je crois qu'il manque l'option -connect juste avant le « fqdn:port »
mais merci beaucoup car ça m'a fait découvrir l'option -showcerts qui
met bien en évidence le certificat manquant (et sans passer par SSL Lab
du coup).
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
Arf, c'est possible que ce ne soit pas au top de la sécu...
Ok, c'est sûrement un truc comme ça. En fait, je pense que c'est au
delà du cache. Sur mon Firefox, je vide le cache à chaque fermeture
et je supprime tout ce qui est possible (j'ai coché toutes les cases)
et mon Firefox semble stocker pourtant le certificat "TERENA SSL CA 3"
de manière _permanente_.
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
openssl s_client -showcerts test1.electionspro2018.ac-versailles.fr:443
openssl s_client -showcerts test1.syndicat.ac-versailles.fr:443
Ok, je crois qu'il manque l'option -connect juste avant le « fqdn:port »
mais merci beaucoup car ça m'a fait découvrir l'option -showcerts qui
met bien en évidence le certificat manquant (et sans passer par SSL Lab
du coup).
Conclusion : serveur mal configuré pour les certificats (pas terrible non plus
pour le chiffrement : RC4, PFS, AEAD - on dirait une configuration d'il y a
quelques années).
Arf, c'est possible que ce ne soit pas au top de la sécu...
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.
Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.
Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA
Est-ce correct de dire que les outils CLI comme curl ou "openssl s_client"
se limitent uniquement aux Root CA (par défaut et sauf ajout manuel de certificat)
alors qu'un navigateur comme Firefox contient d'autres certificats en plus ?
Oui.Mais dans ce cas, si Firefox va au delà des Root CA, jusqu'où va-t-il ?
Est-ce qu'il stocke de manière permanente tous les certificats qu'il
rencontre (et qui ont une chaîne valide) ?
Peut-être seulement les "Certificates Signers" (pas vérifié)
(View / Details / Certificate Key Usage -> Certificate Signer)
Marche aussi sans -connect (openssl 1.1.1).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)
Désolé pour le doublon, j'ai eu un problème avec mon client de messagerie.
Désolé pour le doublon, j'ai eu un problème avec mon client de messagerie.
Désolé pour le doublon, j'ai eu un problème avec mon client de messagerie.
Les "certificates signers", ce sont les certificats qui signent d'autres
certificats, autrement dit les certificats qui ne sont pas en bout de chaîne,
j'ai bon ?
D'ailleurs, j'ai une petite question sur "openssl s_client". Puisqu'il est
maintenant établi que c'est le certificat intermédiaire "TERENA SSL CA 3"
qui est manquant (car pas envoyé par le serveur Web), j'aimerais malgré
tout faire fonctionner ma commande "openssl s_client" en lui ajoutant
manuellement ce certificat. Voici ce que j'ai fait. Sur mon Firefox, j'ai
exporté ce certificat manquant dans le fichier ~/tmp/CA/TERENASSLCA3.crt,
puis j'ai lancé la commande suivante :
echo | openssl s_client -connect test1.syndicat.ac-versailles.fr:443
-servername test1.syndicat.ac-versailles.fr -CAfile ~/tmp/CA/TERENASSLCA3.crt
Et bien j'ai toujours l'erreur « Verification error: unable to get issuer certificate ».
Pourquoi donc ?
J'ai peut-être mal compris la signification de l'option -CAfile. Pourtant
quand je lis le man s_client(1SSL), je vois :
-CAfile file
A file containing trusted certificates **to use during server authentication**
and to use when attempting to build the client certificate chain.
J'ai pas bon ? -CAfile est utilisé uniquement pour définir un certificat côté
client mais pas côté serveur ? Y'a-t-il une option pour ajouter à la volée un
certificat à la commande openssl afin de lui compléter sa liste (constituée des
Root CA par défaut).
Les "certificates signers", ce sont les certificats qui signent d'autres
certificats, autrement dit les certificats qui ne sont pas en bout de chaîne,
j'ai bon ?
D'ailleurs, j'ai une petite question sur "openssl s_client". Puisqu'il est
maintenant établi que c'est le certificat intermédiaire "TERENA SSL CA 3"
qui est manquant (car pas envoyé par le serveur Web), j'aimerais malgré
tout faire fonctionner ma commande "openssl s_client" en lui ajoutant
manuellement ce certificat. Voici ce que j'ai fait. Sur mon Firefox, j'ai
exporté ce certificat manquant dans le fichier ~/tmp/CA/TERENASSLCA3.crt,
puis j'ai lancé la commande suivante :
echo | openssl s_client -connect test1.syndicat.ac-versailles.fr:443
-servername test1.syndicat.ac-versailles.fr -CAfile ~/tmp/CA/TERENASSLCA3.crt
Et bien j'ai toujours l'erreur « Verification error: unable to get issuer certificate ».
Pourquoi donc ?
J'ai peut-être mal compris la signification de l'option -CAfile. Pourtant
quand je lis le man s_client(1SSL), je vois :
-CAfile file
A file containing trusted certificates **to use during server authentication**
and to use when attempting to build the client certificate chain.
J'ai pas bon ? -CAfile est utilisé uniquement pour définir un certificat côté
client mais pas côté serveur ? Y'a-t-il une option pour ajouter à la volée un
certificat à la commande openssl afin de lui compléter sa liste (constituée des
Root CA par défaut).
Les "certificates signers", ce sont les certificats qui signent d'autres
certificats, autrement dit les certificats qui ne sont pas en bout de chaîne,
j'ai bon ?
D'ailleurs, j'ai une petite question sur "openssl s_client". Puisqu'il est
maintenant établi que c'est le certificat intermédiaire "TERENA SSL CA 3"
qui est manquant (car pas envoyé par le serveur Web), j'aimerais malgré
tout faire fonctionner ma commande "openssl s_client" en lui ajoutant
manuellement ce certificat. Voici ce que j'ai fait. Sur mon Firefox, j'ai
exporté ce certificat manquant dans le fichier ~/tmp/CA/TERENASSLCA3.crt,
puis j'ai lancé la commande suivante :
echo | openssl s_client -connect test1.syndicat.ac-versailles.fr:443
-servername test1.syndicat.ac-versailles.fr -CAfile ~/tmp/CA/TERENASSLCA3.crt
Et bien j'ai toujours l'erreur « Verification error: unable to get issuer certificate ».
Pourquoi donc ?
J'ai peut-être mal compris la signification de l'option -CAfile. Pourtant
quand je lis le man s_client(1SSL), je vois :
-CAfile file
A file containing trusted certificates **to use during server authentication**
and to use when attempting to build the client certificate chain.
J'ai pas bon ? -CAfile est utilisé uniquement pour définir un certificat côté
client mais pas côté serveur ? Y'a-t-il une option pour ajouter à la volée un
certificat à la commande openssl afin de lui compléter sa liste (constituée des
Root CA par défaut).