Modifier la dur

Le
Yann COHEN
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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Belaïd
Le #26367034
--001a11c1d8d62c7c7e051fa3a138
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 c ertificat
CSR que l'autorité signera à nouveau.

Le 13 septembre 2015 12:33, Yann COHEN
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.






--
< Belaid >

--001a11c1d8d62c7c7e051fa3a138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>
il y a un an, j&#39;ai utiliser le script cert_manager.sh pour créer d es<br>
certificats de plsuieurs site internet (hôtes virtuels sur apache).<br >
<br>
Seulement, j&#39;ai zappé de modifier le paramètre default_days e t donc<br>
aujourd&#39;hui les certificats ont expirés...<br>
<br>
Ai-je un autre moyen que de les recréer pour modifier leur date<br>
d&#39;expiration ?<br>
<br>
Cordialement.<br>
<span class="HOEnZb"><font color="#888888"><br>
Yann.<br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div clas s="gmail_signature">&lt; Belaid &gt;</div>
</div>

--001a11c1d8d62c7c7e051fa3a138--
andre_debian
Le #26367074
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 certi ficat
CSR que l'autorité signera à nouveau.



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.

André

Le 13 septembre 2015 12:33, Yann COHEN > 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 ?
Eric Degenetais
Le #26367151
--001a1134d30aa38a88051fb55848
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

bonjour,
à ma connaissance, les clients e-mail ont la même exigence que le s
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 se rveur
mail doivent ajouter dans le truststore de leur client e-mail le certificat
de l'autorité qui a signé le certificat.

bonne journée

______________
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org


Le 13 septembre 2015 21:14,
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 autor ité)
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,
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é

> Le 13 septembre 2015 12:33, Yann COHEN > > 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 apach e).
> > 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 ?






--001a1134d30aa38a88051fb55848
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

&gt; Le certificat arrivé a expiration devient invalide pour l&#39;aut orité de<br>
&gt; certification (il entre dans la liste de révocation de cette auto rité) donc<br>
&gt; a mon avis le seul moyen est de générer une autre demande de de certificat<br>
&gt; CSR que l&#39;autorité signera à nouveau.<br>
<br>
</span>Il me semble que les certificats TLS, pour les serveurs de mail,<br>
n&#39;ont pas besoin de la signature d&#39;une autorité officielle (pa yante),<br>
à moins d&#39;avoir la bénédiction de <br>
Ce sont, pour l&#39;instant, les certificats de serveurs Web en https<br>
qui doivent être signés par une autorité officielle.<br>
<br>
André<br>
<span class="im HOEnZb"><br>
&gt; Le 13 septembre 2015 12:33, Yann COHEN &lt; &gt; &gt; certificats de plsuieurs site internet (hôtes virtuels sur a pache).<br>
&gt; &gt; Seulement, j&#39;ai zappé de modifier le paramètre defa ult_days et donc<br>
&gt; &gt; aujourd&#39;hui les certificats ont expirés...<br>
&gt; &gt; Ai-je un autre moyen que de les recréer pour modifier leur d ate<br>
&gt; &gt; d&#39;expiration ?<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>

--001a1134d30aa38a88051fb55848--
David Guyot
Le #26367153
--=-Yd/KXFfRjnfkJWuaRmCM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le dimanche 13 septembre 2015 à 21:14 +0200, 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, à m oins de le
refaire, car le modifier rendrait les signatures cryptographiques qu'il
contient invalide. Logique, quand on y pense : ça oblige à refair e 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

--=-Yd/KXFfRjnfkJWuaRmCM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJV9tS5AAoJEAPBMoJ4TVG5S4wP/A0Bt0MRiTTYMy+pgZwPkdA0
I3Q5eqHJDZxt3exee0H2IXn+Z1bh5x3F1qWvkEy5z+0f4utOufkMrH9DUkR5XZg8
UnfA1e5TlwA9Z000FxjsakX7rBopCJKf9eAVwk7UhwwVcbCe1+H2SbN5D+sTvYdR
hGIIM1l9Xdx+PmEHhCMOWD2ts1kpjhhpSoVVU3cSVdoAKb2SJ4t+mwmfbTxKQ3PK
C0CVG/w8g4TQHj4nsfLH5HE125IaKdquIUcLB3RTCuG7+5i27LrDgxE0dq65AN1n
GABGtQBhD/eKcU4zAbV6mhF8cLvlTSfAuEBGYsUyhrPITCt9wxjlxE9X6phM8ewe
F8zmHbVVlqCWzzgn/bYQ6lp7kQTwd0R24PRYAscSdkNvam5zPxUcd/f598Q9KuHO
HbY/oYiJa+SmgRpVd0/kCVA5VmBgQZ0O9lYtd9laNRtNXCZXm3F9V1aW6x7Vucki
0+P+LfRAVN2YfTHA3bfLoVGfGhKKRfqTnoIO73nZCW4prZUmRlvpaLcX2HeG4Oj5
El74pPR8LVdzTjzj+D7dGMc6sYTtHDGkGA0lv7JZiTYa4aj4BnecsmMTEcNyf08M
SqC6TAI7N819jUaxA3TENkkW+rAzJVzgu/0jpSnGusMA2kYSn6GwW1ncz4zOXrJe
viSt/PN6wyYgyZGy0FFf
=ubU0
-----END PGP SIGNATURE-----

--=-Yd/KXFfRjnfkJWuaRmCM--
andre_debian
Le #26367154
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 ser veur
mail doivent ajouter dans le truststore de leur client e-mail le certific at
de l'autorité qui a signé le certificat.
Éric Dégenètais



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é

Le 13 septembre 2015 21:14, > 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.
> André
Eric Degenetais
Le #26367159
--001a1134ada8e741c0051fb5aa80
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 reco nnue) 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
Henix


http://www.henix.com
http://www.squashtest.org


Le 14 septembre 2015 16:07, David Guyot <
a écrit :

Le dimanche 13 septembre 2015 à 21:14 +0200, e.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 (payant e),
> à 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 à refa ire 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 risq ue
de finir par être cassés, surtout s'ils utilisent des algorithm es 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




--001a1134ada8e741c0051fb5aa80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

a écrit :<br>
<span class=""><br>
&gt; Il me semble que les certificats TLS, pour les serveurs de mail,<br>
&gt; n&#39;ont pas besoin de la signature d&#39;une autorité officiell e (payante),<br>
&gt; à moins d&#39;avoir la bénédiction de &gt;<br>
&gt; Ce sont, pour l&#39;instant, les certificats de serveurs Web en https< br>
&gt; qui doivent être signés par une autorité officielle.<br >
&gt;<br>
<br>
</span>En fait, les clients mails acceptent souvent les certificats non sig nés,<br>
mais ils préfèrent quand même les certificats émanant d &#39;une autorité de<br>
certification reconnue.<br>
<br>
Sinon, non, on ne peut pas, pour autant que je sache, modifier quelque<br>
paramètre que ce soit dans un certificat déjà fait, à m oins de le<br>
refaire, car le modifier rendrait les signatures cryptographiques qu&#39;il <br>
contient invalide. Logique, quand on y pense : ça oblige à refair e le<br>
certificat, donc à repasser par l&#39;autorité de certification, à chaque<br>
modification de certificat. Sinon, ce serait trop facile de repousser<br>
indéfiniment la validité d&#39;un certificat déjà sign é ; de plus, ça<br>
empêche que des certificats restent trop longtemps en place, au risque <br>
de finir par être cassés, surtout s&#39;ils utilisent des algorit hmes de<br>
signature périmés depuis.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
David Guyot<br>
Administrateur système, réseau et télécom / Sysadmin<br >
Europe Camions Interactive / Stockway<br>
Moulin Collot<br>
F-88500 Ambacourt<br>
<a href="tel:03%2029%2030%2047%2085" value="+33329304785">03 29 30 47 8 5</a><br>
</font></span></blockquote></div><br></div>

--001a1134ada8e741c0051fb5aa80--
andre_debian
Le #26367177
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) d iminue
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



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
Le #26367182
--001a11c1d8d6e17435051fb72fb3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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é,
Le 14 sept. 2015 17:53,
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 l es
> 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 d e
> certificat, attendu que tout le monde peut vous envoyer un certificat
> autosigné ou signé par sa propre autorité...)
> Éric Dégenètais

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 plu s
crédibles que les certificats auto-signés ?

André







--001a11c1d8d6e17435051fb72fb3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir="ltr">Bonjour,<br>
Expérience il y&#39;a tout juste 1h chez un client, le MUA Mail de Mac OS X a râlé sur un certificat auto-signé,   </p>
&gt; Il faut quand même savoir que si c&#39;est OK pour le test, accep ter les<br>
&gt; certificats auto-signés (ou signés par une autorité non reconnue) diminue<br>
&gt; fortement la sécurité (la connections est chiffrée, mai s par contre pour la<br>
&gt; protection contre le man-in-the-middle c&#39;est comme s&#39;il n&#39; y avait pas de<br>
&gt; certificat, attendu que tout le monde peut vous envoyer un certificat< br>
&gt; autosigné ou signé par sa propre autorité...)<br>
&gt; Éric Dégenètais<br>
<br>
Déjà la première affirmation change... :-)<br>
<br>
Les MUA n&#39;indiquent aucun message de warning.<br>
<br>
Dans peu de temps on pourra créer ses propres certificats en ligne,<br >
même pour https, et les faire signer * gratuitement * par un<br>
consortium : acceptés par les navigateurs sans couiner.<br>
<br>
En quoi des certificats officiels à 5€ / an seraient-ils plus< br>
crédibles que les certificats auto-signés ?<br>
<br>
André<br>
<br>
<br>
<br>
</blockquote></div>

--001a11c1d8d6e17435051fb72fb3--
Eric Degenetais
Le #26367188
--047d7b86df82966579051fb77207
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 u n peu
naïvement pris mon cas pour une généralité...

En quoi des certificats officiels à 5€ / an seraient-ils plu s
crédibles que les certificats auto-signés ?




Attention, ne pas confondre certificat signé bénévolement pa r une autorité
qui ne fait pas payer et certificats auto-signés ou signés par un e 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élivre r
n'importe quel certificat à n'importe qui) qui permet à l'utilisa teur final
d'être confiant sur le fait qu'il se connecte bien sur le serveur qu'i l
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 confianc e
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 certifica t est
bidon ou non (je certifie moi-même que je suis authentique...)


______________
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org


Le 14 septembre 2015 17:52,
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 l es
> 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 d e
> certificat, attendu que tout le monde peut vous envoyer un certificat
> autosigné ou signé par sa propre autorité...)
> Éric Dégenètais

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 plu s
crédibles que les certificats auto-signés ?

André







--047d7b86df82966579051fb77207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

&gt; Il faut quand même savoir que si c&#39;est OK pour le test, accep ter les<br>
&gt; certificats auto-signés (ou signés par une autorité non reconnue) diminue<br>
&gt; fortement la sécurité (la connections est chiffrée, mai s par contre pour la<br>
&gt; protection contre le man-in-the-middle c&#39;est comme s&#39;il n&#39; y avait pas de<br>
&gt; certificat, attendu que tout le monde peut vous envoyer un certificat< br>
&gt; autosigné ou signé par sa propre autorité...)<br>
</span>&gt; Éric Dégenètais<br>
<br>
Déjà la première affirmation change... :-)<br>
<br>
Les MUA n&#39;indiquent aucun message de warning.<br>
<br>
Dans peu de temps on pourra créer ses propres certificats en ligne,<br >
même pour https, et les faire signer * gratuitement * par un<br>
consortium : acceptés par les navigateurs sans couiner.<br>
<br>
En quoi des certificats officiels à 5€ / an seraient-ils plus< br>
crédibles que les certificats auto-signés ?<br>
<br>
André<br>
<br>
<br>
<br>
</blockquote></div><br></div>

--047d7b86df82966579051fb77207--
andre_debian
Le #26367194
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é.



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 a utorité
qui ne fait pas payer et certificats auto-signés ou signés par une au torité
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,
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 utilisa teurs
vérifiés, et a émis plus d'un million de certificats.

André
Publicité
Poster une réponse
Anonyme