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.
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.
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.
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.
Le 13 septembre 2015 12:33, Yann COHEN a écrit :
> 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 ?
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.
Le 13 septembre 2015 12:33, Yann COHEN <yann@ianco.org> a écrit :
> 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 ?
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.
Le 13 septembre 2015 12:33, Yann COHEN a écrit :
> 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 ?
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 a écrit :
> > 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 ?
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 <yann@ianco.org> a écrit :
> > 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 ?
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 a écrit :
> > 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 ?
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.
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.
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.
à 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
Le 13 septembre 2015 21:14, 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.
> André
à 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
Le 13 septembre 2015 21:14, <andre_debian@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.
> André
à 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
Le 13 septembre 2015 21:14, 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.
> André
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
Le dimanche 13 septembre 2015 Ã 21:14 +0200, andre_debian@numericabl 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
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
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
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
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
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é
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é
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é
En quoi des certificats officiels à 5€ / an seraient-ils plu s
crédibles que les certificats auto-signés ?
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é
En quoi des certificats officiels à 5⬠/ an seraient-ils plu s
crédibles que les certificats auto-signés ?
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é
En quoi des certificats officiels à 5€ / an seraient-ils plu s
crédibles que les certificats auto-signés ?
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é
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é.
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...)
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é.
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...)
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é.
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...)