à 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
______________
Le 13 septembre 2015 21:14, <andre_debian@numericable.fr> a écrit :
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,
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 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 ?