Certificat non approuvé : trois causes autres que l’expiration

Votre application se chargeait très bien hier. Aujourd’hui, quelqu’un vous envoie la capture d’un avertissement du navigateur en pleine page, qui dit que la connexion n’est pas privée, et vous demande si votre site a été piraté. Vous ouvrez le certificat : il est valide jusqu’au printemps prochain. Il n’a donc pas expiré, et le navigateur dit quand même que le certificat n’est pas approuvé.

Le réflexe évident est de le renouveler, et pour cet écran c’est le mauvais. Chacune des trois causes ci-dessous touche un certificat qui est déjà dans ses dates. Un renouvellement vous donne donc une date d’expiration plus lointaine sur un certificat toujours refusé pour une autre raison.

Dans notre article sur l’expiration, le certificat est la licence en vitrine qui dit que cette boutique est bien celle de l’enseigne. Le navigateur d’un visiteur lit trois choses sur cette licence avant de laisser entrer qui que ce soit : la date, le nom de la boutique pour laquelle elle a été émise, et la signature de celui qui l’a émise. L’expiration, c’est la date. Cet article parle des deux autres.

Certificat non approuvé alors qu’il n’a pas expiré : pourquoi ?

Parce que le nom ou la signature a échoué, et que le navigateur dresse le même mur pour chacune de ses vérifications.

Un certificat n’est approuvé que s’il nomme exactement l’adresse qui figure dans la barre d’adresse du visiteur et s’il a été signé par une autorité à laquelle le navigateur fait déjà confiance, avec chaque certificat intermédiaire envoyé avec lui. Si l’un des deux échoue, Chrome affiche l’avertissement qui dit que la connexion n’est pas privée et Firefox celui qui annonce un risque probable de sécurité, exactement comme pour un certificat expiré.

Ce qui change, ce sont les petits caractères sous l’avertissement. Lisez-les avant de toucher à quoi que ce soit :

Chrome affiche le même code pour la deuxième et la troisième ligne, et c’est pour cela qu’il vaut la peine d’ouvrir le certificat lui-même.

Si une seule personne signale l’avertissement et que personne d’autre ne le voit, demandez-lui sur quel réseau elle était. Le code source de Chrome cite un réseau wifi qui renvoie ses utilisateurs vers une page de connexion comme l’une des causes de l’erreur de nom. Celle-là disparaît dès qu’elle se connecte au réseau.

Comment voir ce que dit le certificat ?

Ouvrez-le depuis l’avertissement et lisez deux champs : à qui il a été émis, et qui l’a émis.

Dans Chrome, cliquez sur la mention d’alerte à gauche de la barre d’adresse (Not secure dans un Chrome en anglais) et ouvrez le certificat depuis le panneau qui s’affiche. Dans Firefox, cliquez sur Advanced dans l’avertissement, puis sur le lien vers le certificat du site (ce sont leurs noms dans un Firefox en anglais). Les deux navigateurs nomment les mêmes champs différemment :

• Le champ qui dit à qui le certificat a été émis (Issued To dans un Chrome en anglais, Subject Name dans Firefox) donne le nom pour lequel il a été fait. La liste complète des noms qu’il couvre se trouve sous Subject Alternative Name, et c’est cette liste que le navigateur compare à l’adresse.
• Le champ qui dit qui l’a émis (Issued By dans Chrome, Issuer Name dans Firefox) donne l’autorité qui l’a signé.

Chacune des trois causes s’y lit différemment :

• Le certificat nomme une autre adresse. C’est la cause 1.
• Le titulaire et l’émetteur portent le même nom. Il s’est signé lui-même : c’est la cause 2.
• Il nomme votre adresse, l’émetteur est une autorité dont vous avez entendu parler, et le navigateur le refuse quand même. C’est la cause 3, la chaîne.

Cause 1 : le certificat est pour une autre adresse

Le certificat est authentique et dans ses dates, et il a été émis pour un autre nom. C’est la licence d’une autre boutique, accrochée dans votre vitrine.

Il se présente sous trois formes :

• Votre domaine pointe vers un hébergeur qui n’a pas encore de certificat pour lui. L’hébergeur répond avec le certificat qu’il a, émis à un nom qui lui appartient. La documentation de Lovable le dit clairement : tant que le certificat n’est pas prêt, le navigateur affiche un avertissement de sécurité à la place de votre site.
• Le certificat couvre une écriture de votre adresse et le visiteur a tapé l’autre. www.yourapp.com et yourapp.com sont deux noms pour un certificat, et chacun doit figurer sur sa liste.
• Une partie de votre DNS pointe encore vers un endroit que vous avez quitté. Un ancien hébergeur, ou la page de parking que votre bureau d’enregistrement affichait avant que vous connectiez quoi que ce soit, répond sur ce nom avec un certificat à lui.

Chez Lovable et Vercel, vous n’achetez pas et n’installez pas ce certificat vous-même. L’hébergeur en émet un pour chaque nom que vous ajoutez dans ses réglages de domaine, une fois que votre DNS fait pointer ce nom vers lui. La documentation de Lovable ajoute qu’un certificat acheté auprès de votre bureau d’enregistrement n’est pas du tout utilisé par son hébergement. Ajoutez les deux écritures, faites pointer les deux vers l’hébergeur, et attendez que chacune apparaisse comme active.

Cause 2 : le certificat s’est signé lui-même

Personne ne se porte garant de ce certificat, à part le serveur qui le présente. C’est une licence que le commerçant a imprimée chez lui.

Tous les navigateurs en refusent un sur un site public, et c’est voulu. Un commentaire du code source de Chrome en donne la raison en une ligne : un certificat auto-signé n’offre aucune protection contre un attaquant placé entre votre visiteur et votre application.

On le rencontre sur des serveurs que quelqu’un a montés à la main : un serveur loué, un outil auto-hébergé, un réglage de test qui est passé en production avec l’application. Un builder émet de vrais certificats pour les domaines que vous lui ajoutez. Un certificat auto-signé sur une application hébergée par un builder veut donc dire que quelque chose d’autre que le builder répond sur votre adresse. Vérifiez où pointe votre DNS avant de changer quoi que ce soit d’autre.

La solution est un certificat émis par une vraie autorité. Let’s Encrypt en émet gratuitement, et c’est l’autorité qu’utilise Vercel quand il émet le vôtre.

Cause 3 : un maillon de la chaîne n’a jamais été envoyé

Le certificat est pour votre adresse et a été signé par une vraie autorité, mais le serveur l’a envoyé sans le certificat intermédiaire, si bien que le navigateur ne peut le relier à personne en qui il a confiance. La licence a été signée par une succursale, et la lettre du siège qui se porte garant de cette succursale manque dans la vitrine.

Mozilla qualifie un certificat intermédiaire manquant de l’un des problèmes de configuration de serveur les plus courants. Firefox télécharge désormais à l’avance une copie de chaque certificat intermédiaire de confiance, pour que ses utilisateurs ne rencontrent plus l’erreur.

C’est ce qui rend cette cause difficile à voir : tout peut sembler normal sur votre ordinateur et échouer chez quelqu’un d’autre. Un navigateur qui a sa propre copie du maillon manquant comble le trou. Un logiciel qui n’utilise que ce qu’envoie votre serveur n’a rien pour le combler. Notre scanner est ce genre de logiciel, et c’est pourquoi il peut signaler un certificat comme non approuvé alors que votre propre navigateur affiche un cadenas.

Chez un builder, la chaîne est gérée pour vous. Elle manque sur les serveurs configurés à la main, et la solution y est de servir le certificat suivi du certificat intermédiaire, dans un seul fichier. Si vous utilisez certbot de Let’s Encrypt, ce fichier est fullchain.pem, et l’erreur consiste à pointer votre serveur vers cert.pem à la place. Pour vérifier de l’extérieur, le test de serveur gratuit de SSL Labs signale un certificat intermédiaire manquant comme un problème de chaîne.

Le cas du domaine personnalisé, dans l’ordre

Quand vous connectez votre propre domaine à un builder, les visiteurs voient cet avertissement tant que l’hébergeur n’a pas de certificat pour votre nom, et l’avertissement dit vrai. Il s’arrête tout seul une fois le certificat émis.

L’ordre, chez Lovable :

1. Ajoutez le domaine dans Lovable. Il configure yourapp.com et www.yourapp.com et les liste séparément.
2. Changez les enregistrements DNS chez votre bureau d’enregistrement pour les valeurs que Lovable vous donne. Selon Lovable, la plupart des changements sont actifs en quelques heures, et la propagation peut prendre jusqu’à 72 heures.
3. Lovable vérifie le domaine et émet le certificat. Vercel fonctionne de la même façon : il prouve automatiquement à Let’s Encrypt que le nom est à vous, tant que le domaine pointe vers Vercel.
4. Ouvrez le site quand le domaine apparaît comme Live. C’est le conseil de Lovable lui-même.

Si l’avertissement est toujours là après 72 heures, Lovable vous demande de contacter son support. Deux réglages valent la peine d’être vérifiés avant d’écrire :

• Cherchez un enregistrement CAA. C’est une entrée DNS qui indique quelles autorités peuvent émettre des certificats pour votre domaine. Une entrée qui oublie l’autorité de votre hébergeur bloque le certificat, et un sous-domaine hérite des enregistrements CAA du domaine parent quand il n’en a pas à lui. L’article sur l’expiration croise le même enregistrement comme raison d’un renouvellement qui échoue. Ici, il empêche le tout premier certificat d’être émis.
• Cherchez un proxy devant. Si votre DNS est chez Cloudflare avec le nuage orange activé sur les enregistrements que votre hébergeur vous a donnés, c’est Cloudflare qui répond à la place de votre hébergeur. Lovable dit qu’il ne peut alors ni vérifier le domaine ni émettre de certificat pour lui, et Lovable comme Vercel disent de passer ces enregistrements en DNS only.

Ce que nous avons trouvé sur 30 879 applications

Huit avaient un certificat qu’aucun navigateur n’approuverait, et chacune était sur un domaine que son propriétaire avait connecté.

En août 2026, notre scan a lu le certificat de 30 879 applications en ligne : 29 927 sur le sous-domaine propre d’un builder et 952 sur un domaine à elles. Les huit certificats non approuvés étaient tous parmi les 952, un peu moins d’un sur cent. Aucune des applications sur le sous-domaine d’un builder n’en avait, ce qui colle avec tout ce qui précède. Sur l’adresse propre du builder, c’est le builder qui possède le nom et le certificat.

Notre constat enregistre que le certificat a échoué, sans dire laquelle des trois causes c’était, donc nous ne pouvons pas vous dire comment les huit se répartissent. Les certificats expirés ou proches de l’expiration du même scan sont comptés dans l’article sur l’expiration.

Pour vérifier votre propre application, notre scan gratuit lit le certificat que votre serveur envoie, depuis l’extérieur, et nomme ce constat quand il le voit. Cela prend environ 20 secondes et ne demande aucun compte.

Le repérer la prochaine fois que quelque chose change

Un certificat passe d’approuvé à refusé quand quelque chose change autour de lui : un nouveau domaine, un déménagement DNS, un proxy activé. La vérification qui compte est celle qui tourne après le changement.

Scannez votre application gratuitement pour voir ce que reçoit aujourd’hui le navigateur d’un visiteur.

• Lit le certificat que votre serveur envoie, depuis l’extérieur, avec huit autres vérifications.
• Nomme le constat quand le certificat n’est pas approuvé, et quand il a expiré ou est sur le point de le faire.
• Environ 20 secondes, et aucun compte.

Reeve Monitor pour l’apprendre peu après le changement.

• Vérifie votre application toutes les 60 secondes, et un certificat auquel il ne peut pas faire confiance compte comme une panne de votre application. Vous êtes donc prévenu comme pour n’importe quelle panne.
• Relance les neuf vérifications toutes les heures et vous envoie un e-mail quand votre note baisse.
• Couvre jusqu’à trois applications.

Ce qu’il faut faire maintenant

Quand l’avertissement a disparu et que l’application ne se charge toujours pas, la question suivante est de savoir si c’est votre application ou la plateforme en dessous, et Supabase est-il en panne, ou est-ce votre application montre comment faire la différence.