Expiration et renouvellement des certificats S/MIME : guide pour les équipes informatiques

Un certificat S/MIME associe une clé publique à une adresse e-mail et est signé par une autorité de certification (AC). Sa période de validité comporte une date de début et une date de fin fixes. Après la date de fin :

• Le chiffrement à destination de l’utilisateur échoue ou déclenche un avertissement. Les clients de messagerie refusent généralement de chiffrer avec un certificat expiré : les partenaires envoient alors du courrier non chiffré ou ne peuvent pas envoyer de message du tout.
• Les nouvelles signatures ne sont pas approuvées. Les destinataires voient un avertissement sur les messages signés avec un certificat expiré.
• Les signatures existantes peuvent encore être vérifiées. De nombreux clients vérifient si le certificat était valide au moment de la signature du message.
• Les messages chiffrés auparavant restent lisibles, à condition que la clé privée soit toujours disponible.

Autrement dit, l’expiration pose surtout problème pour le courrier à venir. Elle ne devient un problème grave pour le courrier passé que si la clé privée est perdue lors du renouvellement.

Depuis le 1er septembre 2023, les AC de confiance publique émettent les certificats S/MIME conformément aux S/MIME Baseline Requirements du CA/Browser Forum (lien externe), les exigences de base applicables à ces certificats. Ces règles normalisent la manière dont les AC valident le contrôle d’une boîte aux lettres et l’identité de son titulaire, définissent des profils de certificats et plafonnent la durée de validité. Pour les profils Strict et Multipurpose utilisés aujourd’hui, le maximum est de 825 jours, soit un peu plus de deux ans.

Ces exigences définissent également des types de validation. Un certificat validé par boîte aux lettres (mailbox-validated) confirme uniquement le contrôle de l’adresse e-mail, tandis que les certificats validés au niveau de l’organisation, du sponsor ou de l’individu (organization-, sponsor- et individual-validated) contiennent en outre des informations vérifiées sur l’organisation ou la personne. Choisissez le type qui correspond à la manière dont les destinataires s’appuieront sur vos signatures.

Les AC émettent souvent des certificats d’un ou deux ans, et le CA/Browser Forum a raccourci à plusieurs reprises la durée de validité maximale des certificats de serveur TLS. Il est judicieux de considérer le renouvellement S/MIME comme un processus courant et récurrent plutôt que comme un événement occasionnel.

Les certificats émis par une AC privée, par exemple une AC exploitée sur un service de PKI cloud, ne sont pas soumis à ces règles publiques, mais ils ne sont approuvés que par les systèmes sur lesquels la racine privée est installée. Notre page sur les autorités de certification externes et privées explique ce compromis.

Clés privées perdues

Si un appareil est remplacé, ou si un certificat est réémis avec une nouvelle paire de clés, et que l’ancienne clé privée n’est pas conservée, tous les messages chiffrés avec l’ancien certificat deviennent illisibles. Les organisations tenues de conserver leur courrier ont besoin d’un historique des clés : un stockage sécurisé des clés de chiffrement antérieures de chaque utilisateur.

Les partenaires détiennent encore l’ancien certificat

Les partenaires chiffrent avec le certificat dont ils disposent. Tant qu’ils n’ont pas reçu le nouveau, généralement par un message signé ou une recherche dans un annuaire, le courrier qu’ils vous envoient peut échouer ou arriver non chiffré.

Le renouvellement au rappel d’agenda

Les tableurs et les rappels ne permettent pas de gérer des centaines ou des milliers de boîtes aux lettres personnelles, de boîtes aux lettres partagées et de comptes de service, qui expirent chacun à une date différente.

Des appareils désynchronisés

Un certificat renouvelé sur un ordinateur portable mais pas sur un téléphone empêche l’utilisateur de lire le courrier chiffré sur l’appareil qui détient encore l’ancienne clé, voire aucune clé.

Certificats intermédiaires manquants

Les AC changent parfois les certificats intermédiaires à partir desquels elles émettent. Si la nouvelle chaîne n’est pas envoyée avec les messages signés ou publiée avec le certificat, certains destinataires ne peuvent pas valider la signature.

Les certificats ne concernent pas que les personnes. Les boîtes aux lettres partagées, comme les adresses dédiées aux factures ou au service juridique, et les systèmes qui envoient des notifications signées ont eux aussi besoin de certificats, et ce sont ceux que l’on oublie le plus souvent, car personne n’en est individuellement responsable.

Les changements de personnel nécessitent également un processus. Lorsqu’une personne quitte l’organisation, révoquez ou retirez son certificat de signature, mais gardez ses clés de chiffrement à la disposition du personnel autorisé si l’organisation doit encore lire le courrier qui lui a été envoyé. La révocation indique aux parties utilisatrices de cesser de faire confiance à un certificat avant sa date de fin, par exemple après une suspicion de compromission de la clé.

L’objectif est de supprimer les étapes manuelles de l’émission, de la distribution et du renouvellement :

• Intégrez-vous à l’AC. Demandez et renouvelez les certificats via l’interface de l’AC plutôt que manuellement. La RFC 8823 (lien externe) étend le protocole ACME aux certificats S/MIME des utilisateurs finaux, même si sa prise en charge varie selon les AC.
• Centralisez les clés. Générez et stockez les clés dans un service géré, afin que le renouvellement ne dépende pas des appareils individuels.
• Publiez automatiquement. Rendez les nouveaux certificats disponibles via un annuaire tel que LDAP, afin que les partenaires puissent les trouver.
• Signez le courrier sortant. Les messages signés contiennent le certificat de l’expéditeur, ce qui permet aux partenaires de mettre à jour leur copie.
• Surveillez les expirations. Suivez chaque certificat et déclenchez une alerte bien avant sa date de fin.

Un modèle de passerelle prend en charge une grande partie de ces tâches de manière centralisée. Nos pages sur la gestion du cycle de vie des certificats S/MIME et sur l’émission et le renouvellement des certificats S/MIME dans le cloud décrivent comment CloudPGP prend en charge ces processus, ainsi que les intégrations avec les autorités de certification avec lesquelles il fonctionne.

1. Inventoriez chaque certificat, y compris ceux des boîtes aux lettres partagées et des comptes de service, avec son AC, son profil et sa date d’expiration.
2. Définissez une politique de clés. Décidez si le renouvellement utilise une nouvelle paire de clés, et conservez les clés de chiffrement antérieures aussi longtemps que le courrier doit rester lisible.
3. Commencez tôt. Renouvelez bien avant l’expiration, afin que les partenaires reçoivent le nouveau certificat à temps.
4. Distribuez le nouveau certificat via votre annuaire et le courrier signé.
5. Vérifiez de bout en bout en échangeant des messages signés et chiffrés avec quelques partenaires importants.

Si votre organisation hésite encore entre les deux normes, notre comparaison PGP ou S/MIME pour la messagerie d’entreprise présente les différences entre leurs modèles de clés et de certificats.