Si ton domaine perso affiche un avertissement « Non sécurisé » après avoir pointé ton DNS vers la plateforme, tes enregistrements DNS sont sûrement bons, mais le handshake entre ton hébergeur et l'autorité de certification est bloqué. La plupart des agences pensent à un bug de la plateforme. En vrai, c'est presque toujours une course de config : ton domaine pointe techniquement au bon endroit, mais les réglages de dispatch de l'hôte Mydrop cherchent encore une ancienne affectation.
On te comprend. Un client attend, un portail de marque doit être lancé, et voilà que l'URL balance une erreur de sécurité. Le genre de goulot qui transforme un déploiement de campagne tout fluide en bras de fer technique avec l'IT. Tu n'es pas seul : on a vu ça sur des centaines de déploiements de marque. C'est rarement la plateforme elle-même, plutôt un enregistrement « fantôme » ou une affectation qui traîne et qu'il faut nettoyer avant que le SSL géré puisse se finaliser.
Ce qui a changé avant que les chiffres bougent
La plupart des retards de provisionnement SSL démarrent par un petit changement tout innocent dans ton panneau DNS. Tu as peut-être mis à jour un enregistrement CNAME pour pointer vers l'hôte Mydrop, mais si un vieil enregistrement A traîne encore, ou si ton TTL (Time To Live) est élevé, le cache DNS mondial continue de servir les anciennes instructions de routage pendant des heures.
Le vrai problème commence quand tu veux forcer le destin. Beaucoup d'équipes martèlent le bouton « Rafraîchir SSL », persuadées de réveiller le système. En fait, tu interromps souvent une tâche automatique en arrière-plan qui était déjà à mi-chemin du provisionnement.
Pour arrêter la boucle des messages d'erreur, fais cet audit express de ton état DNS actuel. Cette checklist repère les écarts les plus fréquents entre un domaine « configuré » et un domaine « provisionné ».
Checklist DNS/SSL en 5 points
- Vérif de propagation : tes enregistrements
CNAMEsont-ils bien propagés sur les nameservers mondiaux ? (Un outil comme DNSChecker fait le job).- Propreté des enregistrements : as-tu purgé tous les anciens
Aqui pointent le domaine vers ton vieux serveur ?- Verrou d'affectation : le domaine est-il actuellement affecté à une autre surface active dans Mydrop ?
- Conflit d'hôte : le domaine est-il déjà revendiqué par un autre workspace ou un hôte public réservé ?
- Fenêtre de provisionnement : as-tu laissé au moins 15 minutes à la tâche automatique pour détecter le nouveau statut DNS avant d'intervenir à la main ?
Si ton statut DNS est vérifié mais que ton sslState signale encore une erreur, tu es probablement face à un conflit d'affectation de cible. Ça arrive quand la plateforme tente de provisionner un certificat pour un domaine pointé en même temps vers une surface lien en bio et une surface portail de marque.
Règle le conflit en désaffectant complètement le domaine dans tes Réglages de domaine, confirme à nouveau le statut « DNS vérifié », puis réaffecte-le à la cible précise dont tu as besoin. Vois ça comme un reset complet de la couche de dispatch de l'hôte : ça vide le cache de routage et le cycle de vie du SSL géré repart de zéro.
La plupart des équipes n'ont pas de panne technique : elles ont une dette de coordination, où la config du domaine et le routage de la plateforme sont simplement désynchronisés. Une fois l'enregistrement vérifié, laisse le système gérer le handshake. La patience, c'est ton meilleur outil de diagnostic.
Les schémas d'échec à vérifier en premier
Quand ton domaine reste bloqué en « Non sécurisé », le souci se résume presque toujours à une course entre ton enregistrement DNS et notre service de provisionnement. On voit ça coincer les agences en permanence. Tu mets à jour le DNS, tu cliques dans ton dashboard, et tu attends un handshake instantané. Sauf que le DNS est une bête capricieuse : il se propage souvent à moitié, certains serveurs voient ton nouveau CNAME pendant que d'autres regardent encore ton ancienne infra, ou le vide.
Le coupable le plus courant, c'est un enregistrement fantôme qui traîne, invisible. Tu as peut-être mis à jour ton CNAME pour portal.clientbrand.com, mais oublié de supprimer un vieux A qui pointait vers un serveur legacy. Résultat : un scénario de cerveau coupé en deux. Quand notre service SSL géré tente de vérifier la propriété, il tombe parfois sur le vieux serveur au lieu de notre couche de routage, et le provisionnement expire.
L'erreur classique : compter sur le bouton refresh de ton navigateur. Ton navigateur cache les réponses DNS de façon agressive. Vide ton cache ou, mieux, fais une vérif côté serveur avant de croire que l'enregistrement est vraiment live partout.
Autre blocage fréquent : une affectation de cible en conflit. Si ce domaine était avant pointé vers un autre workspace ou réservé comme hôte système, la logique de routage interne bloque le processus SSL par sécurité. Elle refuse d'attacher un certificat à un hôte que ton workspace actuel ne revendique pas entièrement. Tu te retrouves dans un état « en attente » qui ne se débloque jamais, parce que le service de dispatch se dit en substance : « Ça, c'est pas encore à toi. »
La preuve qui sépare le signal du bruit
Arrête de deviner si la plateforme est « juste lente » et mets-toi à auditer le vrai signal. On a construit notre outil interne de vérif DNS pour servir de source de vérité unique, exactement pour ça. S'il renvoie un statut « en attente » ou « conflit », tu peux cliquer sur « Rafraîchir SSL » autant que tu veux, ça ne changera rien.
Utilise cette checklist DNS/SSL en 5 points pour faire un audit rapide avant d'ouvrir un ticket support ou de pinguer ton équipe dev.
| Étape | Point d'audit | Action si échec |
|---|---|---|
| 1 | CNAME propagé |
Utilise dig ou nslookup pour confirmer que l'enregistrement pointe vers notre hôte, pas vers ton vieux serveur. |
| 2 | Aucun A en conflit |
Supprime tout enregistrement A sur le même sous-domaine. C'est la cause n°1 des handshakes qui expirent. |
| 3 | Dispo de l'hôte | Vérifie que l'hôte n'est pas déjà affecté à un autre workspace dans tes réglages. |
| 4 | Signal d'état SSL | Regarde dans le dashboard les codes sslError précis : DNS_PENDING veut dire attends, AUTH_FAILURE veut dire corrige les enregistrements. |
| 5 | Synchro cron | Attends au moins 15 minutes. Nos workers en arrière-plan pulsent le statut du domaine ; les refresh manuels peuvent parfois remettre ce minuteur à zéro. |
La règle d'or du SSL : si la vérif DNS échoue, le provisionnement SSL est de fait en pause. La plateforme ne tentera pas de récupérer un certificat pour un domaine dont elle ne peut pas prouver qu'il t'appartient. Traite la vérif DNS comme le portier. Dès qu'elle passe au vert, le cycle de vie du SSL géré se déclenche tout seul. Tu vois une erreur DNS_PENDING ? C'est presque à coup sûr un délai de propagation : va chercher un café et laisse le réseau rattraper son retard. Tu vois une AUTH_FAILURE ? Tu as un fantôme de config à traquer dans la console de ton fournisseur DNS.
Ce qu'il faut régler cette semaine
Si tu fixes là, maintenant, un statut SSL en échec, arrête de réessayer le bouton et commence par tes enregistrements DNS. Le correctif le plus courant est étonnamment simple : assure-toi que tes CNAME ou A n'entrent pas en conflit avec un hôte fantôme. Souvent, un vieux A pointant vers un serveur legacy ou une redirection à la racine est encore actif chez ton fournisseur DNS, et notre service de provisionnement se prend un mur.
Dégage le chemin en auditant tes réglages DNS. Si tu utilises Mydrop pour gérer ton domaine perso, vérifie que le CNAME pointe exactement vers la cible de domaine perso publique fournie dans les réglages de ton workspace. S'il pointe ailleurs, notre cycle de vie SSL géré ne peut pas vérifier la propriété, et le provisionnement cale indéfiniment.
Checklist de récupération DNS et SSL en 5 étapes
- Cherche les doublons : supprime tout
AouAAAAen conflit qui pourrait concurrencer tonCNAMEsur le même hôte. - Vérifie l'alignement de la cible : confirme que ton
CNAMEpointe vers la cible publique exacte indiquée dans tes réglages de domaine. - Attends la propagation : laisse le temps à internet de suivre. Les changements DNS prennent quelques minutes ou, plus rarement avec des résolveurs mondiaux têtus, jusqu'à une heure.
- Nettoie les conflits d'hôte : assure-toi qu'aucun autre workspace ni portail inactif ne revendique ce même hôte.
- Refresh manuel : une fois sûr que les enregistrements sont propres, lance un refresh manuel dans tes Réglages de domaine Mydrop.
Si tu as nettoyé tes enregistrements et que ça plante encore, vérifie si l'hôte est un hôte public réservé ou déjà affecté à un autre workspace. C'est un grand classique dans les grosses équipes : un service a « emprunté » un domaine pour une landing page il y a six mois et a oublié de le libérer.
Quand arrêter de diagnostiquer et changer le workflow
Si tu te retrouves à dépanner des certificats SSL plus d'une fois par mois, tu as un problème de coordination, pas un problème technique. Les meilleures équipes n'attendent pas l'avertissement « Non sécurisé » pour réaliser que leur domaine est mal configuré. Elles installent une culture du « vérifier d'abord » qui traite le provisionnement du domaine comme une phase à part, verrouillée, du cycle de vie du projet.
La plupart des agences font l'erreur de filer une URL de marque à un client avant que le DNS soit bien propagé et le SSL actif. Ça crée un goulot à fort enjeu quand le client visite le lien et tombe sur un avertissement du navigateur pile au lancement. Change plutôt ton réflexe interne : fais de « Domaine prêt » une case obligatoire avant d'intégrer la moindre page lien en bio ou portail client dans un deck de campagne.
Règle d'opérateur : n'inclus jamais un domaine perso dans une com client ou un planning de lancement tant que la vérif DNS Mydrop n'a pas renvoyé un statut « Vérifié » confirmé.
En avançant la vérification plus tôt dans ton workflow, tu supprimes le stress de dernière minute à courir après les mises à jour DNS. Le provisionnement SSL passe d'un bras de fer technique à un processus de fond routinier et automatique. Quand tu standardises la règle du « vérifier d'abord », tu arrêtes d'être le dépanneur IT de tes propres surfaces marketing. Tu deviens l'équipe qui lance à l'heure, à chaque fois.
Conclusion
Les échecs SSL dans un environnement multi-tenant comme Mydrop ne viennent presque jamais d'une plateforme qui lâche. Ce sont les traces d'un enregistrement DNS qui ne colle pas tout à fait au dispatch d'hôte attendu, ou d'une course de config où un domaine est tiré dans deux directions. Une fois que tu as compris que le SSL n'est que le dernier handshake d'une longue chaîne de vérification DNS, l'« état d'erreur » n'a plus rien de mystérieux. Audite tes enregistrements, chasse les fantômes et applique une politique du « vérifier d'abord » pour chaque nouveau portail de marque. Ton équipe, et tes clients, apprécieront l'expérience fluide d'un site sécurisé, à ta marque, et prêt à bosser dès qu'ils posent les yeux dessus.
Avis Google
Avis Trustpilot
Product Hunt comment
