0
0

Email

Ventas Soporte

Dirección

CABA - Azopardo 770

Piso 9 - Oficina 10

Lunes a viernes de 9 a 18 hs
Atendido por personas reales
Alerta TLS · SSA:2026-293-02 · ca-certificates-20261020

Explotación de ca-certificates en servidores Linux y PHP (SSA:2026-293-02 / ca-certificates-20261020): cómo funcionan los ataques con CAs raíz revocadas y cómo blindar OpenSSL, cURL, Mercado Pago y ARCA/AFIP

La publicación del boletín de seguridad SSA:2026-293-02 (ca-certificates-20261020) volvió a poner en evidencia uno de los puntos ciegos más peligrosos en servidores web: confiar en almacenes de certificados raíz desactualizados. En este análisis técnico te explicamos por qué un servidor Linux o PHP con un paquete ca-certificates viejo puede sufrir un ataque Man-in-the-Middle aun teniendo CURLOPT_SSL_VERIFYPEER = true, cómo sincronizar los 5 almacenes TLS del servidor, cómo erradicar el error cURL error 60 y cómo blindar tu Checkout para evitar cobros duplicados.

Actualizado: 21 de Octubre de 2026 Boletín: SSA:2026-293-02 · Mozilla NSS Root Store 20261020 Mitigado en toda la flota MESI

1 Cómo se explota un paquete "ca-certificates" desactualizado en un servidor Linux o PHP (Boletín SSA:2026-293-02)

Existe un mito muy extendido entre desarrolladores y administradores: pensar que actualizar el paquete ca-certificates solo sirve para "agregar certificados nuevos" cuando algo deja de conectar. En realidad, la función de seguridad más crítica de actualizaciones como ca-certificates-20261020 (SSA:2026-293-02) es purgar y revocar Autoridades Certificantes Raíz (Root CAs) que fueron comprometidas, vendidas o expulsadas por emisión fraudulenta.

El mecanismo de explotación: cuando CURLOPT_SSL_VERIFYPEER = true no te protege

Cuando tu aplicación en PHP (WordPress, WooCommerce, Laravel o un script propio), Python o Wget realiza una conexión HTTPS saliente hacia una API externa, OpenSSL verifica si el certificado presentado por el servidor remoto está firmado por alguna de las autoridades listadas en /etc/ssl/certs/ca-certificates.crt o en el archivo cacert.pem configurado en php.ini.

Si tu servidor conserva un paquete ca-certificates antiguo sin parchear, sigue otorgando confianza absoluta a decenas de raíces históricas revocadas por incidentes de seguridad y auditorías fallidas en el programa Mozilla CA:

Acción en ca-certificates-20261020 Certificados Raíz Afectados (Ejemplos reales en /usr/share/ca-certificates/mozilla/) Riesgo si tu servidor NO actualizó el paquete
Expulsión / Revocación de CAs desconfiadas o expiradas CA_WoSign_ECC_Root.crt, Certification_Authority_of_WoSign_G2.crt, CNNIC_ROOT.crt, Camerfirma_Chambers_of_Commerce_Root.crt, AddTrust_External_Root.crt, Baltimore_CyberTrust_Root.crt, Certinomis_-_Root_CA.crt, ComSign_CA.crt Explotación Man-in-the-Middle (MitM): Si un atacante intercepta el tráfico saliente (mediante desvío BGP, envenenamiento DNS o en redes cloud compartidas) y presenta un certificado firmado por una raíz o sub-CA revocada que sigue presente en tu ca-bundle.crt, OpenSSL devuelve Verify return code: 0 (ok) y entrega tus tokens y datos en texto plano al atacante.
Incorporación de nuevas raíces TLS 1.3 modernas Amazon_Root_CA_1..4.crt, Certainly_Root_R1.crt, Certainly_Root_E1.crt, Certum_EC-384_CA.crt, Atos_TrustedRoot_Root_CA_ECC_TLS_2021.crt, ANF_Secure_Server_Root_CA.crt Bloqueo de pagos y APIs (cURL error 60): Las conexiones legítimas hacia servicios sobre AWS, Cloudflare, pasarelas de pago como Mercado Pago, WebServices de ARCA / AFIP o APIs de IA fallan abruptamente con SSL certificate problem: unable to get local issuer certificate.
El doble peligro del "parche de foro": Cuando un servidor tiene sus ca-certificates viejos y empieza a tirar cURL error 60, muchos programadores agregan CURLOPT_SSL_VERIFYPEER => false en el código PHP para "salir del paso". Eso convierte un fallo de configuración en una vulnerabilidad total permanente donde cualquier certificado falso autofirmado puede robar las credenciales de cobro de tu empresa.

2 La trampa de los "5 Trust Stores divididos": por qué actualizar solo el paquete del sistema no alcanza

En una auditoría profunda de servidores Linux (Slackware, Debian, Ubuntu, RHEL/AlmaLinux) que ejecutan múltiples versiones de PHP y demonios en Python, descubrimos un error operativo muy frecuente: el administrador actualiza el paquete ca-certificates del sistema operativo, pero PHP, cURL o Python siguen leyendo archivos .pem estáticos antiguos guardados en otras carpetas.

Para que un servidor quede 100% blindado tras instalar ca-certificates-20261020, es obligatorio auditar y unificar los 5 almacenes de confianza:

Comandos de sincronización de los 5 Trust Stores aplicados en MESI Bash / Linux Sysadmin
# 1. Regenerar el bundle maestro del sistema (/etc/ssl/certs/ca-certificates.crt)
/usr/sbin/update-ca-certificates --fresh

# 2. Unificar el bundle de libcurl (/usr/share/curl/ca-bundle.crt)
ln -sf /etc/ssl/certs/ca-certificates.crt /usr/share/curl/ca-bundle.crt

# 3. Unificar OpenSSL 1.1 / 3.x compilado a medida (/opt/openssl11/ssl/cert.pem)
ln -sf /etc/ssl/certs/ca-certificates.crt /opt/openssl11/ssl/cert.pem

# 4. Verificar que PHP 8.4.27 / 8.2.35 apunten al bundle actualizado en php.ini:
# curl.cainfo = "/etc/ssl/certs/ca-certificates.crt"
# openssl.cafile = "/etc/ssl/certs/ca-certificates.crt"
/usr/local/php-8.4/bin/php -r 'print_r(openssl_get_cert_locations());'

# 5. Sincronizar el almacén de Python (certifi) usado por scripts y bots de IA:
python3 -c "import certifi; print(certifi.where())"
¿También viste la vulnerabilidad crítica de PHP de hoy? Hoy mismo se publicaron PHP 8.4.27 y 8.2.35 corrigiendo los fallos críticos CVE-2026-109618 y CVE-2026-109619 de corrupción de estado en PHP-FPM. Leé nuestro análisis técnico y el parche para mysqlnd acá: Vulnerabilidad Crítica en PHP (CVE-2026-109618 y CVE-2026-109619): Análisis de PHP 8.4.27 y Blindaje de Sesiones.

3 Cómo blindar tus cobros con Mercado Pago y ARCA/AFIP en PHP 8.4 (Verificación TLS estricta + Fin de los Pagos Duplicados)

Una vez que tu servidor cuenta con ca-certificates-20261020 y PHP 8.4.27 activos, tus integraciones con Mercado Pago API v2 y con los WebServices SOAP de ARCA / AFIP (wsaa y wsfev1) deben cumplir dos reglas de oro:

  1. Verificación TLS estricta activa (CURLOPT_SSL_VERIFYPEER => true y CURLOPT_SSL_VERIFYHOST => 2).
  2. Idempotencia de cobro y separación de pantallas de confirmación: en auditorías de tiendas online argentinas detectamos que muchos clientes pagan dos veces sin querer porque al volver de Mercado Pago (back_urls.success) el sitio los envía a la misma pantalla genérica order_complete.php que muestra el CBU bancario para transferir, haciéndoles creer que el pago con tarjeta falló.
Patrón seguro en PHP 8.4.27: TLS estricto + X-Idempotency-Key + Guardián anti-F5 PHP 8.4.27
<?php
// 1. Llamada cURL a Mercado Pago con validación SSL estricta (ca-certificates-20261020)
function crearPreferenciaMpBlindada(array $orden, string $token): array {
    // Clave determinística para que Mercado Pago nunca cobre dos veces ante un reintento HTTP
    $idempotencyKey = hash('sha256', 'MP_ORDEN_' . $orden['id'] . '_' . $orden['total']);

    $payload = [
        'items' => [[
            'id'          => (string) $orden['codigo'],
            'title'       => $orden['concepto'],
            'quantity'    => 1,
            'currency_id' => 'ARS',
            'unit_price'  => (float) $orden['total'],
        ]],
        'external_reference' => (string) $orden['id'],
        // Redirigir a una pantalla exclusiva de pago aprobado (sin mostrar CBU de transferencia)
        'back_urls' => [
            'success' => 'https://tudominio.com.ar/shop/order_complete_mp.php',
            'pending' => 'https://tudominio.com.ar/shop/order_complete_mp.php',
            'failure' => 'https://tudominio.com.ar/shop/checkout.php?error=mp',
        ],
        'auto_return' => 'approved',
    ];

    $ch = curl_init('https://api.mercadopago.com/checkout/preferences');
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_POST           => true,
        CURLOPT_POSTFIELDS     => json_encode($payload, JSON_UNESCAPED_UNICODE),
        CURLOPT_HTTPHEADER     => [
            'Content-Type: application/json',
            'Authorization: Bearer ' . $token,
            'X-Idempotency-Key: ' . $idempotencyKey,
        ],
        CURLOPT_SSL_VERIFYPEER => true,
        CURLOPT_SSL_VERIFYHOST => 2,
        CURLOPT_TIMEOUT        => 10,
    ]);

    $res  = curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    $err  = curl_error($ch);
    curl_close($ch);

    if ($res === false || $code >= 400) {
        throw new RuntimeException("Error TLS/API Mercado Pago ($code): $err");
    }
    return json_decode($res, true);
}

// 2. Guardián de idempotencia en order_complete.php para que recargar con F5 no duplique el pedido:
$orderId = $_SESSION['order_id'] ?? '';
if ($orderId !== '' && empty($_SESSION['orders_processed'][$orderId]) && !empty($_SESSION['cart'])) {
    $_SESSION['orders_processed'][$orderId] = true;
    registrarPedidoEnMySQL($orderId, $_SESSION['cart']);
    enviarEmailConfirmacion($orderId);
    $_SESSION['cart'] = []; // Vaciamos el carrito conservando los datos del recibo en pantalla
}

4 Prompt Maestro: Usá la IA para auditar los almacenes SSL (ca-certificates) y el Checkout de tu servidor

Copiá este prompt técnico y ejecutalo en Claude, ChatGPT, Gemini, Cursor o con MIA para detectar en segundos si tu servidor o tu código tiene vulnerabilidades TLS o riesgo de cobros duplicados:

Prompt de Auditoría TLS (SSA:2026-293-02 / ca-certificates) y Pasarela de Pagos
"Actuá como un Especialista Senior en Seguridad Linux, Criptografía TLS y Pasarelas de Pago en PHP 8.4. Necesito auditar mi servidor y mi aplicación frente al boletín SSA:2026-293-02 (ca-certificates-20261020) y blindar mi integración con Mercado Pago y ARCA/AFIP.

Por favor ayudame con estos 4 puntos:
1. Generá un script de diagnóstico en Bash y PHP que verifique la fecha y huella de los certificados en /etc/ssl/certs/ca-certificates.crt, /usr/share/curl/ca-bundle.crt, openssl_get_cert_locations() en PHP y certifi.where() en Python, alertando si aún existen CAs revocadas (como WoSign, CNNIC, AddTrust o Camerfirma).
2. Revisá mi código PHP adjunto y eliminá cualquier uso inseguro de CURLOPT_SSL_VERIFYPEER => false o verify_peer => false en SoapClient, reemplazándolo por validación TLS 1.2/1.3 estricta contra el bundle del sistema.
3. Agregá el encabezado X-Idempotency-Key en las peticiones a la API de Mercado Pago y separá la URL back_urls.success de la pantalla de transferencia bancaria.
4. Implementá el guardián de sesión $_SESSION['orders_processed'][$orderId] y bloqueo JS de doble clic en el botón de compra."
Blindado con ca-certificates-20261020 (SSA:2026-293-02) y PHP 8.4.27

Protegé tus conexiones HTTPS, tus cobros y tu facturación en MESI Hosting

Olvidate de lidiar con almacenes SSL desactualizados o errores cURL 60. En MESI mantenemos toda la cadena de confianza TLS y el motor PHP 8.4.27 / 8.2.35 actualizados al día con soporte humano directo en Argentina.

Tiendas Online & Facturación ARCA

Hosting Profesional / Empresarial

$10.900 ARS/mes + IVA

Plan Profesional 20 GB NVMe + 50 casillas (o Plan Empresarial 60 GB + IP dedicada por $28.790/mes)

  • ca-certificates-20261020 en cURL y OpenSSL
  • 100% compatible con Mercado Pago y ARCA/AFIP
  • PHP 8.4.27 / 8.2.35 parcheados contra CVE-2026
  • Certificado SSL Gratis + Backups en .snapshots
Ver todos los planes de Web Hosting →
Ideal E-Commerce y Sistemas Críticos

Cloud Server VPS 4

$43.230 ARS/mes + IVA

2 núcleos CPU · 4 GB RAM · 40 GB SSD Enterprise (o VPS 2 desde $22.000/mes)

  • IP dedicada propia y recursos exclusivos
  • Trust Stores TLS sincronizados y auditados
  • Migración bonificada sin pérdida de pedidos
  • Soporte técnico 24/7 en español
Integración de Pagos y AFIP con IA

MIA · Desarrollo con IA

$43.230 ARS/mes + IVA

Auditamos y blindamos tu pasarela de cobros

  • Integramos Mercado Pago y ARCA/AFIP con TLS estricto
  • Blindaje de Checkout contra pagos duplicados
  • Incluye servidor Cloud y supervisión técnica
  • Ideal para tiendas a medida, sistemas y ERPs
Conocer cómo funciona MIA →
¿Querés verificar si tu servidor está afectado por SSA:2026-293-02 o solucionar un error SSL en tu tienda? Consultar con un Especialista por WhatsApp

Preguntas frecuentes sobre la explotación de ca-certificates (SSA:2026-293-02), cURL SSL y Mercado Pago

¿Cómo se explota un paquete ca-certificates desactualizado en un servidor Linux o PHP (Alerta SSA:2026-293-02)?

Cuando un servidor no aplica actualizaciones como ca-certificates-20261020 (boletín SSA:2026-293-02), su archivo /etc/ssl/certs/ca-certificates.crt sigue confiando en Autoridades Certificantes Raíz (Root CAs) que fueron expulsadas y revocadas por Mozilla NSS debido a compromisos de claves privadas o emisión fraudulenta de certificados (como WoSign, CNNIC, StartCom, Camerfirma o AddTrust). Un atacante capaz de interceptar el enrutamiento (BGP hijacking, DNS spoofing o proxy en red) puede presentar un certificado firmado por una de esas raíces revocadas y OpenSSL, cURL o PHP lo aceptarán como 100% válido incluso con CURLOPT_SSL_VERIFYPEER activado.

¿Por qué actualizar solo el paquete ca-certificates del sistema operativo suele dejar vulnerables a PHP, cURL o Python?

Porque en la mayoría de los servidores Linux conviven hasta 5 almacenes de confianza (Trust Stores) independientes: /etc/ssl/certs/ca-certificates.crt del sistema, /usr/share/curl/ca-bundle.crt de libcurl, /opt/openssl11/ssl/cert.pem en compilaciones de OpenSSL 1.1, el archivo cacert.pem definido en curl.cainfo / openssl.cafile de cada php.ini, y el bundle de python-certifi. Si no se sincronizan y enlazan todos hacia el bundle actualizado ca-certificates-20261020, PHP o Python siguen leyendo archivos PEM estáticos antiguos.

¿Por qué aparece el error "cURL error 60: SSL certificate problem: unable to get local issuer certificate" al conectar con Mercado Pago, AWS o ARCA/AFIP?

Es la otra cara del mismo problema: además de revocar CAs comprometidas, ca-certificates-20261020 incorpora las nuevas raíces modernas (como Amazon_Root_CA_1 a 4, Certainly_Root_R1/E1, Certum_EC-384_CA o Atos_TrustedRoot_2021). Si tu servidor tiene un bundle antiguo, carece de estas raíces y rechaza las conexiones HTTPS legítimas hacia APIs modernas.

¿Por qué es un peligro crítico poner CURLOPT_SSL_VERIFYPEER en false para esquivar un error de certificado?

Desactivar CURLOPT_SSL_VERIFYPEER apaga toda verificación criptográfica del certificado remoto, permitiendo que cualquier certificado autofirmado falso suplante a la API de Mercado Pago o a los WebServices de ARCA/AFIP y robe tus tokens de acceso o claves privadas.

¿Cómo evito además que un cliente pague dos veces en mi Checkout de Mercado Pago y transferencia bancaria?

Debés combinar tres medidas en tu código PHP: enviar siempre el encabezado X-Idempotency-Key en la petición cURL a Mercado Pago, apuntar back_urls.success a una pantalla exclusiva de pago aprobado (que no muestre el CBU bancario de transferencia) y registrar un guardián de idempotencia en sesión ($_SESSION['orders_processed'][$orderId] = true) para que recargar con F5 nunca duplique el pedido en MySQL.

¿La infraestructura de MESI Hosting ya tiene aplicado el parche ca-certificates-20261020 (SSA:2026-293-02)?

Sí. Todos los servidores de MESI Hosting cuentan con ca-certificates-20261020 desplegado y sincronizado en los 5 almacenes de confianza (OpenSSL, cURL, PHP 8.4.27, PHP 8.2.35, PHP 7.4 y Python certifi), garantizando máxima seguridad contra ataques Man-in-the-Middle y compatibilidad total con APIs externas.

¿Dudas? Chateá con nosotros