Este artículo se basa en los errores y aciertos reales que experimenté al preparar el lanzamiento de una app de escritorio para Windows. Originalmente publiqué partes de esta historia en una comunidad de desarrolladores coreana y luego la reorganicé aquí. Los precios y políticas pueden cambiar en cualquier momento, así que verifica todo en las páginas oficiales antes de pagar.
0. Cómo empezó todo
Soy un exconsultor que no sabía nada de programación: ni siquiera podía imprimir Hello World!, solo usaba Ctrl+C / Ctrl+V en Excel. Tras ser despedido, empecé a experimentar con “vibe coding” asistido por IA y decidí que mi primer proyecto sería una ambiciosa app de escritorio.
Cuando finalmente quise compartirla con amigos para que la probaran en MacBooks y PCs con Windows, todos se toparon con el mismo problema: no se podía instalar. Ahí descubrí que las apps instalables necesitan firma de código y notarización, para demostrar que el archivo no fue alterado entre el desarrollador y el usuario final.
El proceso y el coste resultaron mucho más complicados de lo esperado.
1. Lo que realmente me costó la firma y notarización
El lado Mac resultó sorprendentemente fluido.
- El registro de Apple Developer cuesta
unos 85 €al año ($99 USD). - Tras el registro, el flujo de empaquetado → firma → notarización fue más ágil de lo esperado.
- La instalación y las actualizaciones automáticas con
electron-updaterfuncionaron de forma fiable desde el primer día.
En mi caso, al conectar Codex tras el registro, toda la cadena —empaquetado, firma, envío al servidor de Apple, notarización— se ejecutó casi como un único pipeline. El instalador funcionó sin problemas en el MacBook de un amigo: sin aviso de “Desarrollador desconocido” y con actualizaciones automáticas operativas de inmediato.
Pero Windows era una historia completamente distinta.
- Los certificados de firma de código OV son caros de entrada.
- A través de un revendedor local, el precio se infla aún más.
- Algunos proveedores te obligan a comprar una llave USB física (como YubiKey).
- Tener que conectar hardware cada vez que firmas complica la automatización CI/CD.
2. Por qué la firma de código Windows OV es tan dura para desarrolladores independientes
Para evitar los avisos de SmartScreen y los bloqueos de instalación en Windows, necesitas un certificado de confianza, lo que implica pasar una verificación empresarial, seas autónomo o empresa. Cuando investigué, existían niveles como IV / OV / EV, y OV era el mínimo realista para distribución.
El problema era el modelo de revendedores. Solicitan certificados de CAs como SSL.com o DigiCert en tu nombre, pero su margen era desorbitado. El certificado ya era caro, la automatización difícil, y encima cobraban por la llave física.
Para alguien como yo, que depende completamente de un agente de IA para programar, que me dijeran que debía conectar una llave USB y firmar manualmente cada build era inaceptable.
Así que primero pregunté en la comunidad.
La respuesta general fue “sí, así funciona”, pero yo me negué a aceptarlo.
3. La alternativa que encontré en Reddit: compra directa en SSL.com + Cloud eSigner
La pista decisiva vino de comunidades de desarrolladores anglófonos. La IA solía dar respuestas demasiado genéricas, pero en Reddit, gente con experiencia real distribuyendo apps Windows compartió alternativas mucho más prácticas.
Al principio, Azure Trusted Signing de Microsoft también parecía prometedor: buen precio y buena automatización. Pero en el momento de mi consulta, solo estaba disponible para desarrolladores individuales en Canadá y EE.UU., así que no era una opción para mí.
Al final me decanté por la combinación SSL.com compra directa + Cloud eSigner.
Los precios que encontré en ese momento:
- Con la configuración tradicional de llave USB, el coste total rondaba los
500 $. - Pero la combinación certificado OV 128 USD + Cloud eSigner 20 USD/mes parecía un plan más reciente y flexible.
- Era la opción más barata y mejor preparada para la automatización.
Resumen práctico
La opción más económica que realmente seguí
En vez de un presupuesto de revendedor, calculé basándome en la ruta de compra directa de firma de código Windows OV. La mayor ventaja: no esperar a que llegue una llave USB física.
Tres razones por las que este enfoque destacó:
- Se eliminó completamente el margen del revendedor.
- Sin esperar semanas por una llave USB física.
- Abrió la puerta a automatizar el proceso de firma con Codex.
4. El verdadero obstáculo durante la emisión del certificado SSL.com
Cloud eSigner en sí mismo es un servicio atractivo. La cuota mensual puede parecer un gasto innecesario, pero elimina la necesidad de llaves físicas y se integra perfectamente con la automatización.
Lo realmente difícil fue el proceso de emisión:
- Documentos de registro empresarial
- Verificación de identidad personal
- Prueba de que soy una persona real
- Prueba de que mi empresa existe
Tras superar todo eso, SSL añadió un requisito más: proporcionar un número D-U-N-S para verificar mi dirección, teléfono y correo electrónico.
No pude evitar pensar: si esto era obligatorio, ¿por qué no lo mencionaron desde el principio?
5. La solución: solicitar D-U-N-S a través de Apple Developer
Obtener un D-U-N-S de forma independiente puede implicar costes y trámites adicionales. Volví a quedarme atascado y empecé a preguntarme si mi “compra directa económica” terminaría costando más que la ruta del revendedor.
Pero Reddit volvió a salvarme. Alguien compartió este consejo:
Si ya estás registrado como Apple Developer, Apple puede conectarte con D&B para solicitar un número D-U-N-S con fines de verificación empresarial.
El documento oficial que consulté:
Esto es importante porque los desarrolladores que ya están comercializando apps en el ecosistema de Apple pueden reutilizar la misma información empresarial. En mi caso, conseguí un número D-U-N-S a nombre de "K-garoo Works" relativamente rápido por esta vía.
Sin exagerar, esto me salvó de gastar aún más dinero mientras intentaba encontrar la ruta más barata para el certificado Windows.
6. Obtener el D-U-N-S no fue el final
Gracias a Apple, recibí mi número D-U-N-S bastante rápido. Pero tampoco fue el último paso.
Al enviar el número a SSL, dijeron que no podían verificarlo. Revisé sitios de consulta pública y descubrí que las empresas fuera de EE.UU. a menudo no estaban correctamente registradas: los enlaces parecían activos, pero la verificación real fallaba.
La situación era así:
- Visible en mi cuenta de Apple ✓
- Visible en el panel de la entidad emisora D&B ✓
- Pero los enlaces públicos para verificación de terceros estaban caídos o inestables ✗
Si el número existe pero no se puede verificar públicamente, ¿qué sentido tiene tenerlo?
7. Encontré la ruta de verificación final y obtuve el certificado
Más tarde descubrí que desde finales de diciembre del año anterior, una discrepancia entre las políticas europeas de intercambio de datos y las operaciones estadounidenses había dejado muchos enlaces de consulta públicos de D&B bloqueados, incluso aparentando estar activos.
Pasé tres días comunicándome con el soporte de SSL, probando cada vía, hasta que —junto con un agente de soporte— encontramos una ruta de verificación que aún funcionaba. Ciertos caminos de verificación empresarial relacionados con el comercio todavía admitían consultas basadas en D-U-N-S, y ese fue el último hilo del que tiré.
Tras tres días de comunicación con el soporte de SSL, finalmente recibí el certificado y pude configurar Cloud eSigner. Con la ayuda de Codex.
¿Para quién es más útil este enfoque?
Esta guía es especialmente relevante si:
- Ya tienes membresía de Apple Developer y la distribución Mac está más o menos resuelta
- Eres un desarrollador independiente o un equipo pequeño que necesita distribuir un instalador Windows
- Consideras que las tarifas de los revendedores son excesivas y quieres solicitarlo directamente
- Quieres automatizar la firma como parte de tu pipeline CI/CD
Por otro lado, si tu estructura empresarial es compleja o los requisitos de verificación por país cambian frecuentemente, puede ser más rápido comunicarte directamente con el soporte oficial desde el principio.
Conclusión clave
Si tuviera que resumir todo este proceso en una frase:
Lo más difícil de la firma de código Windows OV no fue decidir dónde comprar el certificado, sino cómo superar la verificación empresarial y D-U-N-S de la forma más barata y eficiente posible.
La secuencia que realmente seguí fue:
- Resolver primero el lado Mac con Apple Developer.
- Para Windows, no ir directamente al revendedor, sino explorar opciones de compra directa.
- Evaluar la combinación SSL.com compra directa + Cloud eSigner.
- Usar la ruta de Apple Developer para solicitar D-U-N-S.
- Si es necesario, recurrir a la vía de soporte de D&B para la verificación final.
Enlaces de referencia rápida
Página oficial
SSL.com / Cloud eSignerContexto comunitario
Hilo de discusión en ClienDocumentación oficial
Guía D-U-N-S de Apple DeveloperCanal de soporte
Página de soporte D&BPreguntas frecuentes
¿Es obligatorio comprar el certificado de firma de código Windows OV a un revendedor local?
Según mi experiencia personal, no necesariamente. Pero dado que las políticas de verificación y emisión pueden cambiar, lo más seguro es consultar la página oficial justo antes de pagar.
¿Puedo obtener D-U-N-S gratis si tengo cuenta de Apple Developer?
La ruta que utilicé fue solicitar como miembro existente de Apple Developer la verificación empresarial para la comercialización de apps. Esto no se aplica automáticamente en todos los casos; consulta las guías de Apple y de D&B antes de proceder.