Si tu dominio personalizado muestra un aviso de "No es seguro" después de haber apuntado tu DNS a la plataforma, lo más probable es que tus registros DNS estén bien, pero el handshake entre tu host y la autoridad de certificación se haya atascado. Muchas agencias dan por hecho que es un fallo de la plataforma, pero casi siempre es una condición de carrera en la configuración: tu dominio apunta técnicamente al sitio correcto, pero los ajustes de envío del host de Mydrop siguen buscando una asignación de destino anterior.
Te entendemos. Tienes un cliente esperando, un portal de marca a punto de lanzarse y, de repente, la URL lanza un error de seguridad. Es justo el tipo de cuello de botella que convierte un lanzamiento de campaña tranquilo en un pulso técnico de alto riesgo con el departamento de IT. No estás solo en esto: lo hemos visto en cientos de despliegues de marca. Casi nunca es la plataforma en sí, sino un registro "fantasma" o una asignación que se ha quedado colgada y hay que limpiar antes de que el SSL gestionado pueda finalizar.
Qué cambió antes de que se movieran los números
La mayoría de los retrasos en el aprovisionamiento del SSL empiezan con un cambio pequeño e inofensivo en tu panel de control de DNS. Puede que hayas actualizado un registro CNAME para que apunte al host de Mydrop, pero si queda un registro A obsoleto, o si tus ajustes de TTL (Time to Live) son altos, la caché global del DNS seguirá sirviendo las instrucciones de enrutamiento antiguas durante horas.
El verdadero problema empieza cuando intentas forzar la solución. Muchos equipos se ponen a pulsar el botón "Actualizar SSL" una y otra vez, pensando que así despiertan el sistema. En realidad, lo que sueles hacer es interrumpir una tarea automática en segundo plano que ya iba por la mitad del proceso de aprovisionamiento.
Para cortar el ciclo de mensajes de error, haz esta auditoría rápida del estado actual de tu DNS. Esta lista de comprobación identifica los huecos más habituales entre un dominio "configurado" y uno "aprovisionado".
Lista de comprobación de salud DNS/SSL de 5 puntos
- Comprobación de propagación: ¿Están tus registros
CNAMEtotalmente propagados por los servidores de nombres globales? (Usa una herramienta como DNSChecker para verificarlo).- Limpieza de registros: ¿Has eliminado todos los registros
Aantiguos que apuntan el dominio a tu servidor anterior?- Bloqueo de asignación: ¿Está el dominio asignado ahora mismo a otra superficie activa en Mydrop?
- Conflicto de host: ¿Está el dominio reclamado por otro espacio de trabajo o por un host público reservado?
- Ventana de aprovisionamiento: ¿Has dejado al menos 15 minutos para que la tarea automática programada detecte el nuevo estado del DNS antes de intervenir a mano?
Si tu estado de DNS está verificado pero tu sslState sigue marcando un error, lo más probable es que tengas un conflicto de asignación de destino. Pasa cuando la plataforma intenta aprovisionar un certificado para un dominio que, a la vez, está apuntando a una superficie link-in-bio y a una superficie brand-portal.
Resuelve el conflicto desasignando el dominio por completo en tus Ajustes de dominio, confirma otra vez el estado "DNS verificado" y vuelve a asignarlo al destino concreto que necesitas. Piénsalo como un reinicio a fondo de la capa de envío del host: limpia la caché de enrutamiento y deja que el ciclo de vida del SSL gestionado empiece de cero.
La mayoría de los equipos no tienen un fallo técnico, sino una deuda de coordinación: la configuración del dominio y el enrutamiento de la plataforma simplemente van desincronizados. Cuando verifiques el registro, deja que el sistema haga el handshake. La paciencia es tu mejor herramienta de diagnóstico.
Los patrones de fallo que debes revisar primero
Cuando tu dominio se queda atascado en estado "No es seguro", el problema casi siempre se reduce a una condición de carrera entre tu registro DNS y nuestro servicio de aprovisionamiento. Vemos a las agencias tropezar con esto todo el tiempo. Actualizas el DNS, pulsas el botón en tu panel y esperas un handshake instantáneo. Pero el DNS es un animal caprichoso: a menudo se propaga a medias, así que algunos servidores ven tu nuevo CNAME mientras otros siguen mirando tu infraestructura antigua o un vacío absoluto.
El culpable más habitual es un registro obsoleto que se queda ahí, invisible. Puede que hayas actualizado tu CNAME para portal.clientbrand.com, pero se te haya olvidado borrar un registro A antiguo que apunta a un servidor heredado. Eso crea un escenario de cerebro dividido. Cuando nuestro servicio de SSL gestionado intenta verificar la propiedad, a veces da con el servidor antiguo en lugar de con nuestra capa de enrutamiento, y el aprovisionamiento se agota por tiempo.
Error habitual: fiarte del botón de recargar del navegador. Tu navegador guarda en caché las respuestas DNS con mucha agresividad. Vacía la caché o, mejor aún, usa una comprobación del lado del servidor antes de dar por hecho que el registro está realmente activo a nivel global.
Otro bloqueo frecuente es un conflicto de asignación de destino. Si ese dominio estaba antes apuntando a otro espacio de trabajo o estaba reservado como host a nivel de sistema, la lógica de enrutamiento interna bloqueará el proceso de SSL como medida de seguridad. No te dejará asociar un certificado a un host que tu espacio de trabajo actual no ha reclamado del todo. Acabas en un estado "pendiente" que nunca se despeja porque el servicio de envío de fondo viene a decir: "todavía no reconozco esto como tuyo".
La prueba que separa la señal del ruido
Deja de adivinar si la plataforma "va lenta" y ponte a auditar la señal real. Precisamente por esto creamos nuestra herramienta interna de comprobación de DNS: para que sea la única fuente de verdad. Si devuelve un estado "pendiente" o "conflicto", por mucho que pulses "Actualizar SSL" el resultado no va a cambiar.
Usa esta lista de comprobación de salud DNS/SSL de 5 puntos para hacer una auditoría rápida antes de abrir un ticket de soporte o avisar a tu equipo de desarrollo.
| Paso | Punto a auditar | Acción si falla |
|---|---|---|
| 1 | CNAME propagado |
Usa dig o nslookup para confirmar que el registro apunta a nuestro host, no a tu servidor anterior. |
| 2 | Sin registros A en conflicto |
Elimina cualquier registro A del mismo subdominio. Son la causa número uno de los tiempos de espera agotados en el handshake. |
| 3 | Disponibilidad del host | Asegúrate de que el host no está ya asignado a otro espacio de trabajo en tus ajustes. |
| 4 | Señal del estado del SSL | Revisa en el panel los códigos sslError concretos; DNS_PENDING significa esperar, AUTH_FAILURE significa corregir registros. |
| 5 | Sincronización de la tarea programada | Espera al menos 15 minutos. Nuestros procesos en segundo plano consultan el estado del dominio; los refrescos manuales a veces reinician ese contador. |
La regla de oro del SSL: si la comprobación de DNS falla, el aprovisionamiento del SSL está, en la práctica, en pausa. La plataforma no intentará obtener un certificado para un dominio del que no puede demostrar con certeza que es tuyo. Trata la comprobación de DNS como el portero. En cuanto se ponga en verde, el ciclo de vida del SSL gestionado arranca solo. Si ves un error DNS_PENDING, casi seguro que es un retraso de propagación: levántate, coge ese café y deja que la red se ponga al día. Si ves un AUTH_FAILURE, tienes un fantasma de configuración que cazar en la consola de tu proveedor de DNS.
Qué arreglar esta semana
Si ahora mismo tienes delante un estado de SSL fallido, deja de darle al botón y empieza por tus registros DNS. La solución más habitual es sorprendentemente simple: asegúrate de que tus registros CNAME o A no chocan con un host fantasma. Muchas veces, un registro A antiguo que apunta a un servidor heredado o a una redirección de nivel raíz sigue activo en tu proveedor de DNS, y eso hace que nuestro servicio de aprovisionamiento se estrelle contra un muro.
Despeja el camino auditando tus ajustes de DNS. Si usas Mydrop para gestionar tu dominio personalizado, confirma que el CNAME apunta exactamente al destino público de dominio personalizado que aparece en los ajustes de tu espacio de trabajo. Si apunta a cualquier otro sitio, nuestro ciclo de vida del SSL gestionado no puede verificar la propiedad y el aprovisionamiento se quedará atascado sin fin.
Lista de recuperación de DNS y SSL en 5 pasos
- Busca registros duplicados: borra cualquier registro
AoAAAAen conflicto que pueda competir con tuCNAMEpor el mismo host. - Verifica la alineación del destino: confirma que tu
CNAMEapunta al destino público exacto que se indica en los ajustes de tu dominio. - Espera la propagación: dale tiempo a internet para ponerse al día. Los cambios de DNS pueden tardar unos minutos o, en casos raros con resolvers globales testarudos, hasta una hora.
- Limpia los conflictos de host: asegúrate de que ningún otro espacio de trabajo ni portal inactivo esté reclamando ese mismo host.
- Refresco manual: cuando tengas claro que los registros están limpios, lanza un refresco manual en tus Ajustes de dominio de Mydrop.
Si has limpiado tus registros y sigue fallando, comprueba si el host es un host público reservado o si ya está asignado a otro espacio de trabajo. Es un problema frecuente en equipos grandes, donde un departamento puede haber "tomado prestado" un dominio para una landing page hace seis meses y haberse olvidado de liberarlo.
Cuándo dejar de diagnosticar y cambiar el flujo de trabajo
Si te ves resolviendo problemas de certificados SSL más de una vez al mes, tienes un problema de coordinación, no técnico. Los mejores equipos no esperan al aviso de "No es seguro" para darse cuenta de que su dominio está mal configurado. Crean una cultura de "verificar primero" que trata el aprovisionamiento del dominio como una fase distinta y controlada del ciclo de vida del proyecto.
Muchas agencias cometen el error de pasarle una URL de marca al cliente antes de que el DNS esté del todo propagado y el SSL activo. Eso crea un cuello de botella de alto riesgo cuando el cliente visita el enlace y ve un aviso del navegador justo en el momento del lanzamiento. Mejor cambia tu hábito interno: trata "Dominio listo" como una casilla obligatoria antes de incluir cualquier página link-in-bio o portal de cliente en una presentación de campaña.
Regla del operador: nunca incluyas un dominio personalizado en una comunicación al cliente ni en un calendario de lanzamiento hasta que la comprobación de DNS de Mydrop devuelva una señal de estado "Verificado" confirmada.
Si adelantas la verificación en tu flujo de trabajo, te quitas el estrés de última hora de ir persiguiendo actualizaciones de DNS. Convierte el aprovisionamiento del SSL en un proceso rutinario y automático en segundo plano. Cuando estandarizas la regla de "verificar primero", dejas de ser el técnico de urgencias de tus propias superficies de marketing y te conviertes en el equipo que lanza a tiempo, siempre.
Conclusión
Los fallos de SSL en un entorno multiinquilino como Mydrop casi nunca se deben a que la plataforma falle. Son el rastro de un registro DNS que no encaja del todo con el envío de host esperado, o de una condición de carrera en la configuración en la que un dominio tira en dos direcciones a la vez. Cuando entiendes que el SSL es solo el handshake final de una larga cadena de verificación DNS, el "estado de error" deja de ser un misterio. Audita tus registros, limpia los fantasmas y aplica una política de verificar primero para cada nuevo portal de marca. Tu equipo, y tus clientes, agradecerán la experiencia impecable de un sitio seguro, con tu marca y listo para funcionar en el momento en que aterrizan en la página.
Reseña en Google
Reseña en Trustpilot
Product Hunt comment
