Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Modifier la durée de validité d'un certificat TLS...
5 views
Skip to first unread message
Yann COHEN
Sep 13, 2015, 6:40:02 AM9/13/15
to
Bonjour,
il y a un an, j'ai utiliser le script cert_manager.sh pour créer des
certificats de plsuieurs site internet (hôtes virtuels sur apache).
Seulement, j'ai zappé de modifier le paramètre default_days et donc
aujourd'hui les certificats ont expirés...
Ai-je un autre moyen que de les recréer pour modifier leur date
d'expiration ?
Cordialement.
Yann.
il y a un an, j'ai utiliser le script cert_manager.sh pour créer des
certificats de plsuieurs site internet (hôtes virtuels sur apache).
Seulement, j'ai zappé de modifier le paramètre default_days et donc
aujourd'hui les certificats ont expirés...
Ai-je un autre moyen que de les recréer pour modifier leur date
d'expiration ?
Cordialement.
Yann.
Belaïd
Sep 13, 2015, 12:50:03 PM9/13/15
to
Bonjour,
Le certificat arrivé a expiration devient invalide pour l'autorité de certification (il entre dans la liste de révocation de cette autorité) donc a mon avis le seul moyen est de générer une autre demande de de certificat CSR que l'autorité signera à nouveau.--
< Belaid >
andre_...@numericable.fr
Sep 13, 2015, 3:20:02 PM9/13/15
to
On Sunday 13 September 2015 18:42:07 Belaïd wrote:
> Le certificat arrivé a expiration devient invalide pour l'autorité de
> certification (il entre dans la liste de révocation de cette autorité) donc
> a mon avis le seul moyen est de générer une autre demande de de certificat
> CSR que l'autorité signera à nouveau.
Il me semble que les certificats TLS, pour les serveurs de mail,
> Le certificat arrivé a expiration devient invalide pour l'autorité de
> certification (il entre dans la liste de révocation de cette autorité) donc
> a mon avis le seul moyen est de générer une autre demande de de certificat
> CSR que l'autorité signera à nouveau.
n'ont pas besoin de la signature d'une autorité officielle (payante),
à moins d'avoir la bénédiction de cacert.org ?
Ce sont, pour l'instant, les certificats de serveurs Web en https
qui doivent être signés par une autorité officielle.
André
Eric Degenetais
Sep 14, 2015, 10:00:04 AM9/14/15
to
bonjour,
à ma connaissance, les clients e-mail ont la même exigence que les navigateurs: connaître l'autorité de certification qui a produit le certificat. Si le certificat n'émane pas d'une autorité reconnue, le TLS ne fonctionnera pas (comme pour un navigateur: affichage d'erreur de handshake).
Pour ne pas utiliser une autorité "officielle", les utilisateurs du serveur mail doivent ajouter dans le truststore de leur client e-mail le certificat de l'autorité qui a signé le certificat.
bonne journée
______________
David Guyot
Sep 14, 2015, 10:10:03 AM9/14/15
to
Le dimanche 13 septembre 2015 à 21:14 +0200, andre_...@numericable.fr
a écrit :
> Il me semble que les certificats TLS, pour les serveurs de mail,
> n'ont pas besoin de la signature d'une autorité officielle (payante),
> à moins d'avoir la bénédiction de cacert.org ?
>
> Ce sont, pour l'instant, les certificats de serveurs Web en https
> qui doivent être signés par une autorité officielle.
>
En fait, les clients mails acceptent souvent les certificats non signés,
mais ils préfèrent quand même les certificats émanant d'une autorité de
certification reconnue.
Sinon, non, on ne peut pas, pour autant que je sache, modifier quelque
paramètre que ce soit dans un certificat déjà fait, à moins de le
refaire, car le modifier rendrait les signatures cryptographiques qu'il
contient invalide. Logique, quand on y pense : ça oblige à refaire le
certificat, donc à repasser par l'autorité de certification, à chaque
modification de certificat. Sinon, ce serait trop facile de repousser
indéfiniment la validité d'un certificat déjà signé ; de plus, ça
empêche que des certificats restent trop longtemps en place, au risque
de finir par être cassés, surtout s'ils utilisent des algorithmes de
signature périmés depuis.
--
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85
a écrit :
> Il me semble que les certificats TLS, pour les serveurs de mail,
> n'ont pas besoin de la signature d'une autorité officielle (payante),
> à moins d'avoir la bénédiction de cacert.org ?
>
> Ce sont, pour l'instant, les certificats de serveurs Web en https
> qui doivent être signés par une autorité officielle.
>
mais ils préfèrent quand même les certificats émanant d'une autorité de
certification reconnue.
Sinon, non, on ne peut pas, pour autant que je sache, modifier quelque
paramètre que ce soit dans un certificat déjà fait, à moins de le
refaire, car le modifier rendrait les signatures cryptographiques qu'il
contient invalide. Logique, quand on y pense : ça oblige à refaire le
certificat, donc à repasser par l'autorité de certification, à chaque
modification de certificat. Sinon, ce serait trop facile de repousser
indéfiniment la validité d'un certificat déjà signé ; de plus, ça
empêche que des certificats restent trop longtemps en place, au risque
de finir par être cassés, surtout s'ils utilisent des algorithmes de
signature périmés depuis.
--
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85
andre_...@numericable.fr
Sep 14, 2015, 10:10:03 AM9/14/15
to
On Monday 14 September 2015 15:50:20 Eric Degenetais wrote:
> à ma connaissance, les clients e-mail ont la même exigence que les
> navigateurs: connaître l'autorité de certification qui a produit le
> certificat. Si le certificat n'émane pas d'une autorité reconnue, le TLS ne
> fonctionnera pas (comme pour un navigateur: affichage d'erreur de
> handshake).
> Pour ne pas utiliser une autorité "officielle", les utilisateurs du serveur
> mail doivent ajouter dans le truststore de leur client e-mail le certificat
> de l'autorité qui a signé le certificat.
> Éric Dégenètais
> à ma connaissance, les clients e-mail ont la même exigence que les
> navigateurs: connaître l'autorité de certification qui a produit le
> certificat. Si le certificat n'émane pas d'une autorité reconnue, le TLS ne
> fonctionnera pas (comme pour un navigateur: affichage d'erreur de
> handshake).
> Pour ne pas utiliser une autorité "officielle", les utilisateurs du serveur
> mail doivent ajouter dans le truststore de leur client e-mail le certificat
> de l'autorité qui a signé le certificat.
Comment se fait-il que mon serveur de mails officiel
accepte les certificats TLS et SSL qui n'émane pas
d'une autorité reconnue, sauf que ce certificat
a été accrédité par "cacert.org".
Et ce, quelquesoit le MUA : kmail, thunderbird, claws-mail,
outlook...
André
Eric Degenetais
Sep 14, 2015, 10:20:03 AM9/14/15
to
Il faut quand même savoir que si c'est OK pour le test, accepter les certificats auto-signés (ou signés par une autorité non reconnue) diminue fortement la sécurité (la connections est chiffrée, mais par contre pour la protection contre le man-in-the-middle c'est comme s'il n'y avait pas de certificat, attendu que tout le monde peut vous envoyer un certificat autosigné ou signé par sa propre autorité...)
andre_...@numericable.fr
Sep 14, 2015, 12:00:03 PM9/14/15
to
On Monday 14 September 2015 16:13:20 Eric Degenetais wrote:
> Il faut quand même savoir que si c'est OK pour le test, accepter les
> certificats auto-signés (ou signés par une autorité non reconnue) diminue
> fortement la sécurité (la connections est chiffrée, mais par contre pour la
> protection contre le man-in-the-middle c'est comme s'il n'y avait pas de
> certificat, attendu que tout le monde peut vous envoyer un certificat
> autosigné ou signé par sa propre autorité...)
> Éric Dégenètais
> Il faut quand même savoir que si c'est OK pour le test, accepter les
> certificats auto-signés (ou signés par une autorité non reconnue) diminue
> fortement la sécurité (la connections est chiffrée, mais par contre pour la
> protection contre le man-in-the-middle c'est comme s'il n'y avait pas de
> certificat, attendu que tout le monde peut vous envoyer un certificat
> autosigné ou signé par sa propre autorité...)
Déjà la première affirmation change... :-)
Les MUA n'indiquent aucun message de warning.
Dans peu de temps on pourra créer ses propres certificats en ligne,
même pour https, et les faire signer * gratuitement * par un
consortium : https://letsencrypt.org/
acceptés par les navigateurs sans couiner.
En quoi des certificats officiels à 5€ / an seraient-ils plus
crédibles que les certificats auto-signés ?
André
Belaïd
Sep 14, 2015, 12:10:04 PM9/14/15
to
Bonjour,
Expérience il y'a tout juste 1h chez un client, le MUA Mail de Mac OS X a râlé sur un certificat auto-signé,
Eric Degenetais
Sep 14, 2015, 12:30:03 PM9/14/15
to
En quoi des certificats officiels à 5€ / an seraient-ils plus
crédibles que les certificats auto-signés ?
crédibles que les certificats auto-signés ?
Ça dépend pour qui.
Oui, j'avais déjà vu un MUA "couiner", et dans la mesure où c'est, franchement, le meilleur comportement pour la sécurité, j'avais un peu naïvement pris mon cas pour une généralité...
En quoi des certificats officiels à 5€ / an seraient-ils plus
crédibles que les certificats auto-signés ?
Attention, ne pas confondre certificat signé bénévolement par une autorité qui ne fait pas payer et certificats auto-signés ou signés par une autorité installé dans son garage, c'est fort différent.
Quand vous vous connectez sur un serveur, c'est la signature de son certificat par une autorité publiquement connue (et à laquelle on fait confiance par un processus social et non technique pour ne pas délivrer n'importe quel certificat à n'importe qui) qui permet à l'utilisateur final d'être confiant sur le fait qu'il se connecte bien sur le serveur qu'il croit contacter.
Donc gratuit ou payant, ce n'est en aucun cas la question, ce qui compte c'est que vous ayez confiance dans l'autorité en question (et confiance dans le fait que c'est bien son certificat qui est dans votre truststore, ce qui implique de faire confiance à l'éditeur du client mail ou u navigateur, et dans votre moyen de distribution des paquets logiciels).
Avec un auto-signé, le client n' AUCUN moyen de savoir si le certificat est bidon ou non (je certifie moi-même que je suis authentique...)
andre_...@numericable.fr
Sep 14, 2015, 12:50:02 PM9/14/15
to
On Monday 14 September 2015 18:02:06 Belaïd wrote:
> Expérience il y'a tout juste 1h chez un client, le MUA Mail de Mac OS X a
> râlé sur un certificat auto-signé.
> Expérience il y'a tout juste 1h chez un client, le MUA Mail de Mac OS X a
On Monday 14 September 2015 18:20:45 Eric Degenetais wrote:
> En quoi des certificats officiels à 5€ / an seraient-ils plus
> crédibles que les certificats auto-signés ?
> Ça dépend pour qui.
> Oui, j'avais déjà vu un MUA "couiner", et dans la mesure où c'est,
> franchement, le meilleur comportement pour la sécurité, j'avais un peu
> naïvement pris mon cas pour une généralité...
> Attention, ne pas confondre certificat signé bénévolement par une autorité
> qui ne fait pas payer et certificats auto-signés ou signés par une autorité
> installé dans son garage, c'est fort différent.
> Quand vous vous connectez sur un serveur, c'est la signature de son
> certificat par une autorité publiquement connue (et à laquelle on fait
> confiance par un processus social et non technique pour ne pas délivrer
> n'importe quel certificat à n'importe qui) qui permet à l'utilisateur final
> d'être confiant sur le fait qu'il se connecte bien sur le serveur qu'il
> croit contacter.
> Donc gratuit ou payant, ce n'est en aucun cas la question, ce qui compte
> c'est que vous ayez confiance dans l'autorité en question (et confiance
> dans le fait que c'est bien son certificat qui est dans votre truststore,
> ce qui implique de faire confiance à l'éditeur du client mail ou u
> navigateur, et dans votre moyen de distribution des paquets logiciels).
> Avec un auto-signé, le client n' AUCUN moyen de savoir si le certificat est
> bidon ou non (je certifie moi-même que je suis authentique...)
Pour les certificats https, il n'y a pas de demi-mesure,
> qui ne fait pas payer et certificats auto-signés ou signés par une autorité
> installé dans son garage, c'est fort différent.
> Quand vous vous connectez sur un serveur, c'est la signature de son
> certificat par une autorité publiquement connue (et à laquelle on fait
> confiance par un processus social et non technique pour ne pas délivrer
> n'importe quel certificat à n'importe qui) qui permet à l'utilisateur final
> d'être confiant sur le fait qu'il se connecte bien sur le serveur qu'il
> croit contacter.
> Donc gratuit ou payant, ce n'est en aucun cas la question, ce qui compte
> c'est que vous ayez confiance dans l'autorité en question (et confiance
> dans le fait que c'est bien son certificat qui est dans votre truststore,
> ce qui implique de faire confiance à l'éditeur du client mail ou u
> navigateur, et dans votre moyen de distribution des paquets logiciels).
> Avec un auto-signé, le client n' AUCUN moyen de savoir si le certificat est
> bidon ou non (je certifie moi-même que je suis authentique...)
soit on, le crée et signe soi même => ça couine,
soit on le, crée et fait signer par une autorité de certification,
la résistance du certificat est liée à son prix qui peut monter très haut.
Pour ceux à 5€/an, humm, résistance assez faible pas meilleure
que ceux auto-signés.
Les certificats signés par "cacert.org" ne sont pas acceptés par
les navigateurs (https).
D'où l'idée de "let's encrypt" déjà signalée, sponsorisé par
Mozilla, Cisco et d'autres... Enfin des certificats opensource !
Pour les certificats de mails, comme déjà indiqué, pour être
sûr qu'ils soient acceptés par tous les MUA, ils doivent être
signés par l'autorité de certification "cacert.org", gratuitement :
https://fr.wikipedia.org/wiki/CAcert.org
CAcert.org est une autorité de certification communautaire qui émet des
certificats à clés publiques gratuits. CAcert a plus de 260 000 utilisateurs
vérifiés, et a émis plus d'un million de certificats.
André
Eric Degenetais
Sep 15, 2015, 4:20:04 AM9/15/15
to
Pour les certificats de mails, comme déjà indiqué, pour être
sûr qu'ils soient acceptés par tous les MUA, ils doivent être
signés par l'autorité de certification "cacert.org", gratuitement :
https://fr.wikipedia.org/wiki/CAcert.org
CAcert.org est une autorité de certification communautaire qui émet des
certificats à clés publiques gratuits. CAcert a plus de 260 000 utilisateurs
vérifiés, et a émis plus d'un million de certificats.
OK, donc on en reste au même principe que les navigateurs: on n'accepte pas les auto-signés, et il faut se faire signer par une autorité reconnue. Que CAcert.org soit reconnue par les clients mail, mais pas par les navigateurs ne change rien au principe: concrètement un navigateur ou un client e-mail est fourni avec un truststore pré-rempli avec des autorités reconnues de confiance. Les utilisateurs font confiance à leur source de logiciel pour vous fournir des clients qui acceptent uniquement des autorités de certification dignes de confiance...
Que cacert.org signe gratuitement n'est pas le plus important. Ce qui compte c'est que ce soit une autorité qui est reconnue comme sérieuse. La solidité d'une certificat (AKA choix d'un bon algorithme + longeur de clef) est un problème important mais c'est un AUTRE problème.
Pas très différent d'acheter une porte: vous faites confiance au fabriquant pour ne pas vendre des copies de clefs aux autres derrière votre dos. Avoir une porte blindée de 20 cm ne protège en rien si tout le monde peut avoir une copie de la clef.
ju...@free.fr
Sep 15, 2015, 5:40:04 AM9/15/15
to
On Mon, Sep 14, 2015 at 04:02:55PM +0200, andre_...@numericable.fr wrote:
> Comment se fait-il que mon serveur de mails officiel
> accepte les certificats TLS et SSL qui n'émane pas
> d'une autorité reconnue, sauf que ce certificat
> a été accrédité par "cacert.org".
je n'ai pas compris cette phrase.
> Comment se fait-il que mon serveur de mails officiel
> accepte les certificats TLS et SSL qui n'émane pas
> d'une autorité reconnue, sauf que ce certificat
> a été accrédité par "cacert.org".
Tu dis que ton serveur accepte *les* certificat*s* sauf que le certif de ton serveur à été accrédité CACert ?!
> Et ce, quelquesoit le MUA : kmail, thunderbird, claws-mail,
> outlook...
tout cas pour thunderbird/firefox et outlook/windows.
andre_...@numericable.fr
Sep 15, 2015, 5:50:03 AM9/15/15
to
je suis loin d'être spécialiste,
"cacert.org", ne signe pas des certificats,
il vérifie des certificats à clés publiques.
Ceux ci sont acceptés par les MUA,
mais pas par les navigateurs pour les https.
On Tuesday 15 September 2015 11:24:18 ju...@free.fr wrote:
> > la résistance du certificat est liée à son prix :
> La résistance ?! :
Comme Papy,
quelle est la différence entre un certificat à 5€ et 3000€ / an ?
André
andre_...@numericable.fr
Sep 15, 2015, 6:00:04 AM9/15/15
to
les certificats simplement accrédités par CACert
sont acceptés par les MUA et pas par les navigateurs.
André
Sylvain L. Sauvage
Sep 15, 2015, 7:30:03 AM9/15/15
to
Le mardi 15 septembre 2015, 11:47:21 andre_...@numericable.fr
a écrit :
>[…]
« Fourchette-piège aimantée, permettant de manger les petits
pois proprement et avec distinction : 10 F.
Le même, mais plus cher : 12,90. »
— Pierre Dac & Francis Blanche
--
Sylvain Sauvage
a écrit :
>[…]
> On Tuesday 15 September 2015 11:24:18 ju...@free.fr wrote:
> > > la résistance du certificat est liée à son prix :
> > La résistance ?! :
> Comme Papy,
> quelle est la différence entre un certificat à 5€ et 3000€ /
> an ?
2995€ ?
> > > la résistance du certificat est liée à son prix :
> > La résistance ?! :
> Comme Papy,
> quelle est la différence entre un certificat à 5€ et 3000€ /
> an ?
« Fourchette-piège aimantée, permettant de manger les petits
pois proprement et avec distinction : 10 F.
Le même, mais plus cher : 12,90. »
— Pierre Dac & Francis Blanche
--
Sylvain Sauvage
Sébastien NOBILI
Sep 15, 2015, 8:50:03 AM9/15/15
to
Bonjour,
Le mardi 15 septembre 2015 à 11:53, andre_...@numericable.fr a écrit :
> C'est un constat que je ne peux expliquer,
> les certificats simplement accrédités par CACert
> sont acceptés par les MUA et pas par les navigateurs.
Les navigateurs peuvent accepter les certificats provenant de CACert, mais (du
moins pour ceux que j'utilise) n'ont pas le certificat racine de CACert dans
leur base d'autorités de confiance (pourquoi, je ne sais pas mais ça doit
pouvoir se trouver).
On peut très bien ajouter le certificat racine dans la base et alors, ils
accepteront sans problème les certificats émis par CACert.
http://www.cacert.org/index.php?id=3
Sébastien
Le mardi 15 septembre 2015 à 11:53, andre_...@numericable.fr a écrit :
> C'est un constat que je ne peux expliquer,
> les certificats simplement accrédités par CACert
> sont acceptés par les MUA et pas par les navigateurs.
moins pour ceux que j'utilise) n'ont pas le certificat racine de CACert dans
leur base d'autorités de confiance (pourquoi, je ne sais pas mais ça doit
pouvoir se trouver).
On peut très bien ajouter le certificat racine dans la base et alors, ils
accepteront sans problème les certificats émis par CACert.
http://www.cacert.org/index.php?id=3
Sébastien
andre_...@numericable.fr
Sep 15, 2015, 5:50:04 PM9/15/15
to
mais la technique me dépasse.
Si tu pouvais me donner un petit tuto... :-)
Bonne nuit.
André
Sébastien NOBILI
Sep 24, 2015, 5:20:03 AM9/24/15
to
Bonjour,
Désolé pour le délai dans la réponse…
Je vais essayer de « vulgariser ».
Si je te tends ma carte d'identité signée du préfet de mon lieu de résidence, tu
connais ce préfet (ou du moins sa fonction), tu lui fais donc confiance et tu
accordes donc du crédit à l'identité que je revendique. C'est ce que font les
navigateurs lorsqu'ils acceptent un certificat SSL (carte d'identité du serveur
Web) signé par une « autorité de confiance » (dans Iceweasel, la liste se trouve
dans « Préférences » => « Avancé » => « Certificats » => « Autorités »).
Si je te tends ma carte d'identité signée de mon voisin. Ne connaissant pas mon
voisin, tu ne lui fais pas confiance. Tu n'accordes donc aucun crédit à
l'identité que je revendique. C'est ce que font les navigateurs lorsqu'ils
rencontrent un certificat SSL (carte d'identité du serveur Web) signé par une
autorité inconnue.
À partir de là deux chemins possibles.
1. Tu regardes la carte d'identité de mon voisin et tu constates qu'elle est
signée du préfet de son lieu de résidence. Le préfet étant une « autorité de
confiance » et tu vas donc pouvoir considérer mon voisin comme étant lui-même
une autorité de confiance (on a pris un raccourci là, mais j'assume).
2. Tu regardes la carte d'identité de mon voisin et tu constates qu'il l'a
lui-même signée. Libre à toi de le considérer ou non comme une « autorité de
confiance », mais il va falloir te faire ta propre opinion sur lui (autour d'une
bière par exemple :-D).
CACert.org est dans le second cas il me semble. Rien d'autre que la confiance
que tu leur accordes ne te permet de les considérer comme étant « autorité de
confiance ».
Sébastien
Je vais essayer de « vulgariser ».
Si je te tends ma carte d'identité signée du préfet de mon lieu de résidence, tu
connais ce préfet (ou du moins sa fonction), tu lui fais donc confiance et tu
accordes donc du crédit à l'identité que je revendique. C'est ce que font les
navigateurs lorsqu'ils acceptent un certificat SSL (carte d'identité du serveur
Web) signé par une « autorité de confiance » (dans Iceweasel, la liste se trouve
dans « Préférences » => « Avancé » => « Certificats » => « Autorités »).
Si je te tends ma carte d'identité signée de mon voisin. Ne connaissant pas mon
voisin, tu ne lui fais pas confiance. Tu n'accordes donc aucun crédit à
l'identité que je revendique. C'est ce que font les navigateurs lorsqu'ils
rencontrent un certificat SSL (carte d'identité du serveur Web) signé par une
autorité inconnue.
À partir de là deux chemins possibles.
1. Tu regardes la carte d'identité de mon voisin et tu constates qu'elle est
signée du préfet de son lieu de résidence. Le préfet étant une « autorité de
confiance » et tu vas donc pouvoir considérer mon voisin comme étant lui-même
une autorité de confiance (on a pris un raccourci là, mais j'assume).
2. Tu regardes la carte d'identité de mon voisin et tu constates qu'il l'a
lui-même signée. Libre à toi de le considérer ou non comme une « autorité de
confiance », mais il va falloir te faire ta propre opinion sur lui (autour d'une
bière par exemple :-D).
CACert.org est dans le second cas il me semble. Rien d'autre que la confiance
que tu leur accordes ne te permet de les considérer comme étant « autorité de
confiance ».
Sébastien
0 new messages