Questions SSL/Curl etc.

Le
Francois Lafont
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 ?

Merci d'avance pour votre aide.
À+

--
François Lafont
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Francois BILLAUD
Le #26492574
On 13/10/2018 00:34, Francois Lafont wrote:
Bonjour à tous,

Bonjour,
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

SSLLabs dit qu'il manque un certificat intermédiaire :
https://www.ssllabs.com/ssltest/analyze.html?d=test1.syndicat.ac-versailles.fr&hideResults=on
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 ?

Hypothèse (pas fait de test) : Firefox a peut-être déjà le certificat TERENA dans son cache
suite à la visite du 1er site.
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 ?

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).
JFB
Francois Lafont
Le #26492590
Bonjour,
On 10/13/2018 08:03 AM, Jean-Francois BILLAUD wrote:
SSLLabs dit qu'il manque un certificat intermédiaire :
https://www.ssllabs.com/ssltest/analyze.html?d=test1.syndicat.ac-versailles.fr&hideResults=on

En effet, sur SSL Lab c'est parfaitement clair : c'est le certificat
TERENA SSL CA 3 qui est manquant.
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.

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) ?
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

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...
Merci beaucoup pour ton aide efficace. ;)
À+
--
François Lafont
Jean-Francois Billaud
Le #26492591
On 13/10/2018 15:01, Francois Lafont wrote:
Bonjour,
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_.

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)
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).

Marche aussi sans -connect (openssl 1.1.1).
voir aussi gnutls-cli et tstclnt (nss).
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...

Il faut ouvrir un ticket (les rectorats adorent les tickets.)
JFB
Francois Lafont
Le #26492622
Hello,
On 10/13/2018 03:28 PM, Jean-Francois Billaud wrote:
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA

Ok, dans ma version de Firefox (62.0.3) c'est dans :
Preferences => "Privacy & Security" => Certificates" => "View Certificates..."
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)

Ah ça, j'ai pas trouvé.
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 ?
Marche aussi sans -connect (openssl 1.1.1).

Ah ok, au temps pour moi. Sur ma Ubuntu 18.04, j'ai la version 1.1.0g seulement.
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 certification 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).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)

:))
--
François Lafont
Francois Lafont
Le #26492621
Hello,
On 10/13/2018 03:28 PM, Jean-Francois Billaud wrote:
Pas le cache des pages, le cache des certificats.
Firefox / Privacy & Security / Certificates / View certificates / Authorities
-> Digisert -> TERENA

Ok, dans ma version de Firefox (62.0.3) c'est dans :
Preferences => "Privacy & Security" => Certificates" => "View Certificates..."
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)

Ah ça, j'ai pas trouvé sur mon Firefox.
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 ?
Marche aussi sans -connect (openssl 1.1.1).

Ah ok, au temps pour moi. Sur ma Ubuntu 18.04, j'ai la version 1.1.0g seulement.
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).
Il faut ouvrir un ticket (les rectorats adorent les tickets.)

:))
--
François Lafont
Francois Lafont
Le #26492626
Désolé pour le doublon, j'ai eu un problème avec mon client de messagerie.
--
François Lafont
Olivier Miakinen
Le #26492627
[copie et suivi vers fr.comp.usenet.lecteurs-de-news]
Le 14/10/2018 12:03, Francois Lafont a écrit :
Désolé pour le doublon, j'ai eu un problème avec mon client de messagerie.

Vu que tu utilises Thunderbird et que tu passes par un serveur de bonne
tenue (Free) tu peux annuler l'un des articles : dans le menu Message
tu as « Cancel Message » qui fait ça. Attention à ne pas confondre avec
« Delete Message » accessible par clic droit, qui ne l'efface que chez
toi.
--
Olivier Miakinen
Jean-Francois Billaud
Le #26492644
On 14/10/2018 11:56, Francois Lafont wrote:
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 ?

CA root ou intermédiaire.
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).

Désolé, pas trouvé.
JFB
Publicité
Poster une réponse
Anonyme