Certificate Pinning: qué es, métodos de fijación de certificados y cómo implementarlo
Certificate Pinning es una técnica de seguridad mediante la cual una aplicación móvil verifica que el certificado del servidor coincide con una muestra predefinida, en lugar de confiar simplemente en cualquier certificado de la cadena CA. A diferencia de la verificación TLS habitual, que se basa en cientos de autoridades certificadoras, el pinning reduce la confianza a un único certificado específico o su clave pública. Según la OWASP Mobile Security Testing Guide (2024), la implementación de Certificate Pinning bloquea el 100% de los escenarios de ataque Man-in-the-Middle relacionados con la suplantación de certificados. OWASP MSTG, 2024
Puntos clave
- Certificate Pinning es una técnica de vinculación estricta de la aplicación a un certificado o clave pública específica del servidor.
- Public Key Pinning es el método más flexible y seguro, que no requiere actualización de la aplicación al cambiar el certificado.
- Diferencia con TLS — el TLS habitual confía en cualquier CA; el pinning añade un segundo nivel de verificación para un certificado específico.
- Riesgo de bloqueo — si el certificado se actualiza incorrectamente, la aplicación puede perder conexión con el servidor hasta que se publique una nueva versión.
- OkHttp y TrustKit son las bibliotecas más populares para implementar pinning en Android e iOS respectivamente.
¿Qué es Certificate Pinning?
Certificate Pinning es un mecanismo de seguridad mediante el cual la aplicación almacena (o “fija”) una muestra del certificado del servidor y compara el certificado recibido con esta muestra en cada conexión. Si el certificado no coincide, la conexión se interrumpe, incluso si está firmado oficialmente por una autoridad certificadora de confianza. Esto protege contra ataques en los que un atacante obtiene un certificado falso a través de una CA comprometida (como ocurrió con DigiNotar en 2011 o Comodo en 2011).
Cómo funciona la fijación de certificados
El proceso de pinning consta de tres etapas: extracción de la huella digital (fingerprint) del certificado o clave pública de una instancia de confianza; almacenamiento de esta huella en el código o recursos de la aplicación; comparación durante el handshake TLS. El desarrollador puede fijar la huella SHA-256 de todo el certificado o solo de la clave pública (Public Key Pinning). El segundo enfoque es preferible: al renovar el certificado, la clave pública a menudo sigue siendo la misma y la aplicación no pierde la conexión con el servidor. Según las recomendaciones de OWASP, el número mínimo de pines es 2: uno actual y otro de respaldo para la rotación de claves. Bibliotecas modernas como OkHttp y TrustKit automatizan el proceso de verificación de los pines especificados durante cada conexión TLS sin esfuerzo adicional del desarrollador. Es importante entender que el pinning no reemplaza la verificación TLS estándar, sino que la complementa: primero se realiza un handshake normal con validación de la cadena de certificados y luego una verificación adicional de pinning. Esta protección de dos niveles elimina las vulnerabilidades relacionadas con el compromiso de CA, incluidos los casos de emisión errónea de certificados y ataques a la infraestructura de las autoridades certificadoras.
Tipos de Certificate Pinning
Existen varios enfoques para implementar Certificate Pinning, cada uno con sus propias características de almacenamiento y verificación. La elección del método depende de la arquitectura de la aplicación, la frecuencia de actualización de los certificados y los requisitos de flexibilidad.
| Tipo de pinning | Qué se almacena | Flexibilidad | Ejemplo de uso |
|---|---|---|---|
| Certificate Pinning | Certificado X.509 completo | Baja | Certificado fijo por 1–2 años |
| Public Key Pinning | Clave pública (SPKI) | Media | Enfoque recomendado por OWASP |
| Hash Pinning | Huella SHA-256 | Media | Popular en OkHttp (certificatePinner) |
| CA Pinning | CA intermedia | Alta | Aplicaciones empresariales |
El método más equilibrado es Public Key Pinning, recomendado por OWASP y Google. En lugar de un certificado específico (que cambia cada 1–2 años), la aplicación almacena la huella SubjectPublicKeyInfo, una abstracción de la clave pública. Si el certificado se renueva con la misma clave (key reuse), el pin sigue siendo válido. Si la clave cambia, el desarrollador añade un pin de respaldo en la actualización de la aplicación con antelación. En proyectos móviles se utiliza una estrategia de pines mín/máx: mínimo 2 pines incluyendo el de respaldo y máximo 4 para evitar el aumento innecesario y el tiempo de verificación.
Estrategia de selección del tipo de pinning
La elección del tipo específico de pinning depende de la arquitectura y los requisitos de la aplicación. Para aplicaciones móviles públicas que trabajan con API REST a través de un solo dominio, lo óptimo es Public Key Pinning con dos pines mediante OkHttp o TrustKit. Para aplicaciones empresariales con su propia autoridad certificadora, es adecuado CA Pinning, que no requiere actualización al cambiar los certificados de cliente, ya que la confianza está vinculada a la CA, no al certificado final. Para sistemas IoT y embebidos, se recomienda Certificate Pinning con fijación del certificado completo: los dispositivos rara vez se actualizan, por lo que el control sobre toda la cadena de confianza es crítico. La monitorización de las fechas de caducidad de los pines es una práctica obligatoria: configure alertas 30, 14 y 7 días antes de que expire el certificado para publicar una actualización de la aplicación con nuevos pines antes de que el certificado actual sea inválido. Para automatizar la publicación de actualizaciones con nuevos pines, se recomienda usar Firebase Remote Config o una API de configuración personalizada que permita actualizar dinámicamente la lista de pines sin publicar una nueva versión en la tienda de aplicaciones.
Ventajas y desventajas de Certificate Pinning
Certificate Pinning aumenta significativamente la seguridad de las aplicaciones móviles, pero impone una carga operativa al equipo de desarrollo. Es importante sopesar los beneficios de seguridad frente a los riesgos de bloqueo de conexión debido a una implementación incorrecta.
La principal ventaja es la protección contra ataques Man-in-the-Middle, incluidos los casos de compromiso de CA. El pinning hace inútiles los certificados falsos emitidos por un atacante: aunque una CA haya firmado una falsificación, la aplicación la rechazará. Un beneficio adicional es la protección contra servidores proxy corporativos que sustituyen certificados para la inspección del tráfico. Según Google Security Blog (2023), las aplicaciones con pinning tienen un 86% menos de probabilidades de ser comprometidas mediante la interceptación de tráfico en comparación con las aplicaciones que usan solo la verificación TLS estándar.
La principal desventaja del pinning es el riesgo de autobloqueo: si el certificado del servidor cambia (renovación, cambio de proveedor, rotación de claves) antes de que se publique la actualización de la aplicación, los usuarios pierden el acceso al servidor. Desventajas adicionales: complejidad de depuración (cada cambio de configuración requiere actualizar los pines), aumento del tamaño del APK en 5–15 KB al usar TrustKit y la imposibilidad de revertir cambios rápidamente sin un nuevo lanzamiento. Para minimizar riesgos, se utilizan pines de respaldo, rotación automática cada 2–3 meses y un período de gracia durante el cual la aplicación acepta tanto el certificado antiguo como el nuevo. También es importante considerar que durante el desarrollo con pinning activado, no se pueden usar herramientas proxy (Burp Suite, Charles) para depurar solicitudes de red; para compilaciones de desarrollo, el pinning debe desactivarse mediante el flag BuildConfig.DEBUG, y las pruebas de QA deben realizarse con la firma de lanzamiento con la protección activada. Algunos equipos usan un dominio de staging con un certificado de pinning separado para el entorno de desarrollo, manteniendo así la protección incluso durante el desarrollo.
Implementación de Certificate Pinning en Android
Veamos un ejemplo de implementación de Certificate Pinning en Android usando OkHttp, la biblioteca estándar para solicitudes de red. OkHttp proporciona un CertificatePinner integrado que acepta hashes SHA-256 de claves públicas.
kotlin
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()En el código anterior, añadimos dos pines para el dominio api.example.com: el principal (certificado actual) y un pin de respaldo (para rotación). OkHttp verifica automáticamente que el certificado del servidor coincida con una de las huellas SHA-256 especificadas. Para obtener la huella SHA-256 del certificado, use el comando: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Es importante almacenar las huellas no en texto plano en el código, sino cifradas u ofuscadas: el análisis estático de MobSF encuentra fácilmente cadenas SHA-256 sin procesar en archivos DEX. Se recomienda almacenar los pines en recursos res/raw, cifrados mediante AES, y descifrarlos al iniciar la aplicación a través de código nativo (NDK/JNI).
Implementación en iOS mediante TrustKit
En iOS, la herramienta principal para Certificate Pinning es la biblioteca de código abierto TrustKit. A diferencia de OkHttp, TrustKit se configura declarativamente a través de Info.plist, lo que permite cambiar los pines sin recompilar la aplicación. La configuración incluye un diccionario con dominios y una matriz de huellas SHA-256 de claves públicas. TrustKit intercepta automáticamente las solicitudes NSURLSession y verifica los certificados antes de que comience la transmisión de datos. Una característica crítica de TrustKit es el soporte de informes de validación de pines: la biblioteca puede enviar informes a un endpoint especificado cuando se produce una discrepancia de pin, lo que permite responder rápidamente a anomalías en los certificados. Apple también proporciona un mecanismo nativo NSPinnedDomains en Info.plist a partir de iOS 14, pero TrustKit sigue siendo la opción preferida debido a su configuración más flexible, soporte de informes y la capacidad de intercambiar pines en caliente sin actualizaciones del SO. Es importante señalar que TrustKit se integra con URLSession a través del delegado didReceiveChallenge, devolviendo .performDefaultHandling tras una verificación exitosa del pin y .cancelAuthenticationChallenge en caso de discrepancia. Para monitorear los informes de validación de pines, se recomienda configurar un endpoint separado que analice la frecuencia de errores: si el número de informes aumenta bruscamente, esto puede indicar un ataque MitM o la próxima expiración del certificado que requiere una actualización inmediata de los pines.
Preguntas frecuentes
¿Qué es Certificate Pinning en términos simples?
Certificate Pinning es como guardar la huella dactilar de un amigo en tu teléfono: recuerdas cómo es el certificado “correcto” del servidor y no confías en nadie más, incluso si alguien te muestra una identificación de una autoridad “oficial”.
¿En qué se diferencia Certificate Pinning del HTTPS habitual?
El HTTPS habitual confía en cualquier certificado firmado por cualquier CA entre cientos de autoridades. Certificate Pinning añade una verificación adicional: el certificado no solo debe ser válido, sino específicamente el que usted ha fijado en el código de la aplicación.
¿Cómo actualizar un certificado al usar Pinning?
Se recomienda almacenar 2–3 pines: el actual y un pin de respaldo para el nuevo certificado. 1–2 meses antes del cambio de certificado, publique una nueva versión de la aplicación con el pin del futuro certificado añadido. Después del cambio, el pin antiguo se elimina en el siguiente lanzamiento.
¿Se puede usar Certificate Pinning con CA gratuitas?
Sí, se puede. El pinning funciona con cualquier certificado, incluidos los de Let’s Encrypt. Es importante recordar que los certificados gratuitos tienen un período de validez corto (3 meses), por lo que la estrategia de pines de respaldo y la rotación automática se vuelven obligatorias.
¿Cómo probar Certificate Pinning en una aplicación?
Use Burp Suite o mitmproxy para probar el pinning. Si la aplicación con pinning está configurada correctamente, la herramienta proxy no podrá interceptar el tráfico: la conexión se interrumpirá en la etapa de handshake. Para pruebas de integración, use MockWebServer de OkHttp.
Resumen
- Certificate Pinning es una técnica de fijación de certificados que protege contra ataques Man-in-the-Middle y suplantación de CA.
- Public Key Pinning es el método recomendado por OWASP basado en la huella de la clave pública, no en el certificado completo.
- OkHttp CertificatePinner en Android y TrustKit en iOS son las principales herramientas para implementar pinning en proyectos móviles.
- Estrategia de 2+ pines evita el bloqueo de la aplicación al cambiar el certificado del servidor.
- SHA-256 pinning requiere el comando openssl para generar la huella de la clave pública del servidor.
- Período de gracia — el uso de un pin de respaldo con fechas de validez superpuestas reduce el riesgo de pérdida de conexión a cero.
- Recomendación: implemente pinning mediante clave pública para todos los dominios de producción con un pin de respaldo y configure la monitorización de caídas de conexión.
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también