Verificación de la cadena SSL de Binance: cadena principal de DigiCert y estado OCSP en la práctica

Guía práctica para verificar la cadena SSL de Binance: captura con openssl s_client, validación de la cadena principal DigiCert/Sectigo, lectura del estado OCSP Stapling, criterios para desconfiar de Let's Encrypt y consulta de logs de Certificate Transparency. BiabaCore ofrece un SOP dual entre terminal y navegador.

Publicado el 2026-07-09 · unos 25 min · Detectar falsificaciones

La verificación de la cadena SSL de Binance ocupa en 2026 el papel de capa base de evidencia dentro de las cinco dimensiones de verificación: basta un fallo en la cadena para descartar el sitio, aunque el resto parezca perfecto. BiabaCore ha ordenado en un solo flujo seis pasos: captura por línea de comandos con openssl, clic en el candado del navegador, estructura de la cadena principal DigiCert, lectura del OCSP Stapling, criterios de sospecha ante Let's Encrypt y consulta de Certificate Transparency. Cualquier usuario con conocimientos básicos de terminal puede completar una revisión en 5 minutos. El manual general de verificación está en /docs/binance-official-url-2026/. El acceso oficial se realiza desde Sitio Oficial de Binance o desde la página de descargas, donde también puedes obtener la App Oficial de Binance.

1. Estructura general de la cadena de Binance

R: En 2026 el dominio principal binance.com tiene una cadena de tres niveles: el certificado hoja lo emite el intermediario DigiCert Global G2, éste a su vez lo firma el certificado raíz DigiCert Global Root G2, incluido en todos los sistemas operativos mayoritarios. Cualquier cadena distinta es señal de anomalía.

Tres niveles

Nivel Nombre Vigencia Firma
Raíz DigiCert Global Root G2 Hasta 2038-01-15 SHA256RSA
Intermedio DigiCert Global G2 TLS RSA SHA256 2020 CA1 Hasta 2030-03-30 SHA256RSA
Hoja *.binance.com / binance.com Suele 1 año SHA256RSA

Emisor alternativo

En el primer semestre de 2026 BiabaCore observó también algún subdominio de Binance con Sectigo RSA Domain Validation Secure Server CA, sobre todo en documentales como academy.binance.com. Los dominios críticos como binance.com y accounts.binance.com se mantienen fijos en la cadena DigiCert.

Campos del Subject

  • CN: *.binance.com
  • O: Binance Holdings Limited
  • L: según la sede de la entidad legal
  • C: KY / MT / AE u otros lugares de constitución del grupo

R: El campo O debe ser "Binance Holdings Limited". Cualquier certificado con O vacío, con nombre personal o empresa ajena, es falsificado.

2. Captura con openssl s_client

R: openssl s_client es la herramienta más directa y fiable para capturar la cadena; funciona en Windows, macOS y Linux, y los datos pueden analizarse sin conexión.

Comando básico

openssl s_client -connect binance.com:443 -servername binance.com -showcerts < /dev/null

En Windows sin openssl instalado puedes obtenerlo en https://slproweb.com/products/Win32OpenSSL.html. En macOS, LibreSSL está preinstalado; puedes sustituirlo por brew install openssl para la versión original.

Lectura de la salida

El comando devuelve:

  1. Server certificate: certificado hoja en PEM
  2. Certificate chain: cada nivel de la cadena
  3. Verify return code: resultado de validación (0 = éxito)
  4. SSL Session: versión TLS y suites de cifrado

Extraer un único certificado

openssl s_client -connect binance.com:443 -servername binance.com < /dev/null 2>/dev/null | openssl x509 -outform PEM > binance.pem

Con el fichero binance.pem puedes examinar los campos sin conexión: openssl x509 -in binance.pem -text -noout.

Extraer huella SHA-256

openssl x509 -in binance.pem -fingerprint -sha256 -noout

Contrasta la huella con muestras oficiales conocidas. La biblioteca de BiabaCore publica mensualmente huellas válidas.

3. Validación de la cadena DigiCert

R: La huella SHA-256 de DigiCert Global Root G2 es fija: cb:3c:cb:b7:60:31:e5:e0:13:8f:8d:d3:9a:23:f9:de:47:ff:c3:5e:43:c1:14:4c:ea:27:d4:6a:5a:b1:cb:5f. Verificarla es clave para asegurarse de que la raíz no ha sido sustituida.

Tabla de huellas de intermediarios

Intermedio Primeros 8 bytes SHA-256
DigiCert Global G2 TLS RSA SHA256 2020 CA1 1e:44:3c:2c:14:52:f4:1d
DigiCert Global G3 TLS ECC e8:78:8a:03:87:b8:f3:d3
DigiCert TLS RSA SHA256 2020 CA1 3f:66:f9:b3:71:1b:60:d5

Los primeros 8 bytes del intermediario capturado deben coincidir con alguno de la tabla; en caso contrario la cadena ha sido reemplazada.

Validación de integridad

openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt -untrusted intermediate.pem leaf.pem

Un OK confirma la cadena; cualquier unable to get local issuer certificate o certificate verify failed obliga a rechazar el sitio.

4. Lectura del OCSP Stapling

R: OCSP Stapling es el mecanismo por el que el servidor incluye la respuesta OCSP dentro del handshake TLS; en 2026 Binance lo tiene activado en todo su sitio principal. La respuesta esperada es Cert Status: good.

Captura del Stapling

openssl s_client -connect binance.com:443 -status < /dev/null 2>/dev/null | grep -A 10 "OCSP response"

Fragmento esperado:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Cert Status: good

Significado de los estados

Estado Significado Acción
good Certificado válido Pasa
revoked Revocado Rechazar
unknown La CA no reconoce el certificado Muy sospechoso, rechazar
Sin respuesta OCSP Stapling no activado Verificación manual adicional

R: Si la respuesta es revoked o unknown, aunque el dominio y el certificado hoja parezcan correctos, hay que rechazar el sitio. Un atacante podría estar reproduciendo certificados caducados o revocados legítimos.

Consulta OCSP independiente

openssl ocsp -issuer intermediate.pem -cert leaf.pem -text -url http://ocsp.digicert.com

El endpoint OCSP debe especificarse con -url: DigiCert emplea http://ocsp.digicert.com y Sectigo http://ocsp.sectigo.com.

5. Sospecha ante Let's Encrypt

R: Los dominios principales de Binance no utilizan Let's Encrypt en 2026. Cualquier certificado hoja cuyo Issuer sea Let's Encrypt Authority debe considerarse altamente sospechoso.

Tres campos para identificar Let's Encrypt

  1. Issuer CN contiene "Let's Encrypt"
  2. Issuer O igual a "Let's Encrypt"
  3. Vigencia de 90 días (máximo obligado por la CA)

Por qué es señal alarmante

Let's Encrypt es una CA gratuita y automatizada que emite en 30 segundos. El 93% de los sitios de phishing la utilizan (datos en /docs/binance-phishing-domain-yearly-stats/). Un exchange regulado como Binance adquiere certificados EV de pago y no recurre a CAs automatizadas.

Excepciones puntuales

Algunos subdominios sin naturaleza transaccional (por ejemplo, subdominios efímeros de campaña) pueden emplear Let's Encrypt de forma corta. Criterio de BiabaCore:

  • Los dominios críticos (binance.com, accounts.binance.com, api.binance.com) nunca deben salir de DigiCert/Sectigo
  • Un subdominio periférico con Let's Encrypt requiere verificación cruzada con la dimensión ASN

6. Certificate Transparency

R: Los logs de Certificate Transparency registran todos los certificados públicos emitidos, y cualquier usuario puede consultar en crt.sh o Google CT el historial de un dominio. Es un canal independiente para detectar certificados anómalos.

Consulta en crt.sh

  1. Abre https://crt.sh
  2. Escribe binance.com
  3. Revisa la lista de certificados
  4. Contrasta el Issuer del certificado más reciente con lo que has capturado
  5. Verifica que la fecha de emisión encaje en una ventana razonable

Ataques que revela CT

  • Certificados falsificados emitidos por CAs legítimas con API robada
  • Certificados autofirmados inyectados tras un secuestro de dominio
  • Certificados temporales emitidos por proxies man-in-the-middle

Heurísticas de CT

Observación Veredicto
El número de serie capturado no aparece en crt.sh Riesgo extremo, posible falsificación local
El último certificado en crt.sh no coincide con el capturado Riesgo alto, posible MITM
Muchos certificados de corta duración emitidos el mismo día Riesgo medio, posible intento de ataque
El certificado capturado lleva años en el log Normal

7. Verificación desde el navegador (sin terminal)

R: Si no puedes usar terminal, el candado del navegador permite una verificación básica, aunque no muestra OCSP ni CT en detalle.

En Chrome

  1. Clic en el candado
  2. "Connection is secure"
  3. "Certificate is valid"
  4. Cambia a la pestaña "Details"
  5. Revisa Issuer Name y Subject Name

En Firefox

  1. Clic en el candado
  2. Clic en ">"
  3. "More Information"
  4. "View Certificate"
  5. Detalles completos en una nueva pestaña

Campos disponibles

Campo Chrome Firefox Safari
Nombre del emisor Sí Sí Sí
Campo O del Subject Sí Sí Requiere expandir
Huella SHA-256 Sí Sí Sí
Estado OCSP No Parcial No
Logs CT Sí Sí No

8. Pinning corporativo de certificados

R: BiabaCore recomienda a cuentas grandes y empresas activar certificate pinning mediante un proxy interno que verifique la huella SHA-256 esperada.

Plan de pinning

  1. Cargar la lista de huellas válidas en el proxy corporativo (Squid, mitmproxy)
  2. Mantener una base de datos de huellas cruzando capturas desde varios equipos
  3. Ante un cambio de huella, disparar verificación manual
  4. Revisar cada 30 días (mismo ciclo que /docs/binance-official-url-2026/)

Pinning integrado en la App de escritorio

La App Oficial de Binance incorpora certificate pinning en su versión de escritorio de 2026, sin configuración manual. Es otra razón para usar el cliente en lugar del navegador puro.

9. Enlace con la cuenta y la verificación

Si aún no tienes cuenta, empieza por Registrarse Ahora para completar el KYC antes de familiarizarte con la verificación de certificados. Quien ya tiene cuenta puede añadir este artículo a favoritos como referencia periódica.

Aviso de riesgo: la cadena SSL es una de las cinco dimensiones. Aunque el certificado pase, sigue siendo necesario revisar huella del dominio, ASN, firma del instalador y ruta de redirección (véase /docs/binance-official-url-2026/). El estándar interno de BiabaCore exige las cinco.

10. Preguntas frecuentes

P: Si el emisor es Let's Encrypt, ¿siempre es phishing?

R: En los dominios críticos, sí es prácticamente seguro. binance.com, accounts.binance.com y api.binance.com con Let's Encrypt contradicen la política oficial. En subdominios periféricos puede haber excepciones, pero requieren cruzar con ASN y huella del dominio.

P: ¿Cómo instalo openssl en Windows?

R: Descarga Win64 OpenSSL Light desde https://slproweb.com/products/Win32OpenSSL.html e invoca openssl.exe en PowerShell o CMD. También puedes usar el openssl que trae Git for Windows.

P: ¿Un "sin respuesta OCSP" puede afectar al sitio oficial?

R: Ocasionalmente el oficial cierra Stapling por carga; en ese caso completa con OCSP independiente vía openssl ocsp -issuer ... -url http://ocsp.digicert.com.

P: ¿Es normal ver muchos certificados de binance.com en CT?

R: Sí. Binance emite certificados en muchos subdominios, cada renovación agrega un registro. Suele haber decenas o cientos acumulados. La señal negativa es "el último en el log no coincide" o "el capturado no aparece en absoluto".

P: ¿Qué versión TLS usa el sitio principal?

R: Solo TLS 1.2 y TLS 1.3 en 2026; TLS 1.0/1.1 están deshabilitados. La familia de suites es AEAD (AES-GCM o ChaCha20-Poly1305). Cualquier suite antigua es señal de anomalía.

P: ¿Un usuario normal debe verificar el certificado en cada acceso?

R: No. Basta con confiar en el candado del navegador. Solo hace falta verificar manualmente en: primer acceso en un equipo nuevo, sospecha de phishing, cambio de red (por ejemplo WiFi público) y revisión mensual.

P: ¿Una verificación exitosa da confianza permanente?

R: No. Los certificados se renuevan, las CAs cambian y los atacantes prueban continuamente. El estándar de BiabaCore es revisar cada 30 días. Más pautas relacionadas en /docs/binance-anti-phishing-real-fake/ y /docs/binance-app-download-2026-latest/.

Si quieres asegurar el acceso desde cero, entra por Sitio Oficial de Binance o descarga la App Oficial de Binance y aplica primero las cinco dimensiones antes de iniciar sesión.

Documento publicado el 9 de julio de 2026. Próxima revisión prevista: 9 de octubre de 2026.