Certificats émis
Les certificats qui existent pour votre domaine, lus dans les journaux de transparence, et ce qui alerte quand un émetteur inattendu en signe un.
Mis à jour le 11 septembre 2026
Sur cette page
- Ce que PostShip vérifie
- Le premier passage apprend
- Pourquoi la révocation n'est qu'un avertissement
- Ce que le détail montre
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- Pourquoi « emetteur_inattendu » alors que j'ai simplement changé d'hébergeur ?
- Pourquoi un certificat pour un sous-domaine que je ne reconnais pas ?
- Pourquoi le contrôle est-il « reporté » depuis plusieurs déploiements ?
Depuis 2018, tout certificat public est inscrit dans des journaux publics — la Certificate Transparency. C'est fait pour ça : qu'un propriétaire puisse voir si quelqu'un a obtenu un certificat pour son domaine. Un DNS détourné, un hébergeur qui en émet un sans prévenir, un ancien prestataire qui garde la main. Le contrôle SSL voit le certificat que votre site sert ; celui-ci voit ceux qui existent. Pour l'expiration du certificat servi, voir Sitemap et SSL.
Ce que PostShip vérifie
À chaque déploiement, PostShip interroge l'annuaire de Cert Spotter (SSLMate) pour votre domaine — l'hôte du projet sans www., sous-domaines compris — et lit chaque émission : l'émetteur, les noms couverts, les dates, le statut de révocation. Aucune requête vers votre site : c'est l'annuaire qu'on lit, et cette requête compte comme une seule dans le budget du passage.
Le verdict compare ce qui vient d'être émis à ce qu'on connaissait :
| Code | Niveau | Ce qui est lu |
|---|---|---|
emetteur_inattendu | Manque (le contrôle échoue) | Un certificat émis ces sept derniers jours par un émetteur que le passage précédent ne connaissait pas. |
nouveaux_certificats | Avertissement | Un certificat a été émis ces sept derniers jours, par un émetteur déjà connu. |
wildcard_emis | Avertissement | Un certificat *.votre-domaine vient d'être émis. |
certificat_revoque | Avertissement | Un certificat encore valide pour votre domaine a été révoqué. |
« Inattendu » veut dire exactement cela, ni plus ni moins : un domaine qui passe de Let's Encrypt à Google Trust Services a peut-être changé d'hébergeur — et c'est le genre de chose qu'on veut savoir le jour même, pas au renouvellement suivant.
Le premier passage apprend
Au premier passage, il n'y a rien à comparer : tout émetteur serait inattendu. PostShip mémorise la liste des émetteurs et le note dans le détail du contrôle (premier passage), pour qu'un pass qui ne prouve rien ne soit pas lu comme une garantie. Ensuite, la base de comparaison est un passage vieux d'au moins un jour, pas le passage immédiatement précédent : ainsi un émetteur nouveau est signalé pendant vingt-quatre heures par tous les passages, puis devient la norme.
Pourquoi la révocation n'est qu'un avertissement
Après une rotation de clé, l'ancien certificat est révoqué et reste dans les journaux jusqu'à son expiration — parfois trois mois. Un échec permanent pour une hygiène correcte serait la fausse alerte type. Un certificat révoqué et expiré n'est plus compté du tout.
Ce que le détail montre
La liste des émetteurs connus, les dix émissions les plus récentes (émetteur, noms couverts, date), et les avertissements. Jamais le certificat lui-même.
Régler
Rien à configurer : la cible est créée par PostShip pour chaque projet, hors quota d'URLs. Projet → Santé → Contrôles du site → Certificats pour lire le verdict et les émissions récentes. Le contrôle se désactive depuis la même carte. Il tourne au déploiement, comme les autres contrôles du site.
La page Santé montre aussi, dans la frise « Ce qui a changé », chaque renouvellement du certificat servi — quand sa date de fin change d'une vérification SSL à l'autre. Voir Domaine et DNS.
Ce qui déclenche une alerte
Un fail, donc emetteur_inattendu, après les confirmations de vos règles, avec la phrase : « Un certificat vient d'être émis pour votre domaine par un émetteur jamais vu jusqu'ici — si ce n'est pas vous, vérifiez votre DNS. »
Ce qui ne sonne pas : les trois avertissements ; le premier passage ; une limite ou une panne de l'annuaire (429, 5xx, injoignable) — le contrôle est alors « reporté au prochain passage », pas en erreur, parce qu'un 429 chez SSLMate n'est pas une panne de votre site et ne doit produire ni alerte, ni incident, ni badge rouge.
Un échec compte dans le Ship Score, catégorie « hygiène du site ».
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Émetteurs et émissions récentes à l'écran | Oui | Oui | Oui |
| Alerte sur un émetteur inattendu | Non | Oui | Oui |
Voir les plans.
Dépannage
Pourquoi « emetteur_inattendu » alors que j'ai simplement changé d'hébergeur ?
C'est le comportement attendu : un nouvel hébergeur émet avec son propre fournisseur (Let's Encrypt chez l'un, Google Trust Services ou ZeroSSL chez l'autre). L'alerte dure le temps que le nouvel émetteur devienne connu — un jour. Si vous n'avez rien changé, vérifiez vos enregistrements DNS avant tout.
Pourquoi un certificat pour un sous-domaine que je ne reconnais pas ?
L'annuaire est interrogé sous-domaines compris. Un prestataire (email, support, statut) émet souvent pour xxx.votre-domaine. Si aucun prestataire ne correspond, quelqu'un contrôle un CNAME de votre zone : c'est précisément ce que ce contrôle existe pour voir.
Pourquoi le contrôle est-il « reporté » depuis plusieurs déploiements ?
L'annuaire limite les appels sans clé à une centaine par heure. Un projet qui déploie très souvent peut le saturer ; le contrôle repassera au déploiement suivant sans rien inventer entre-temps.