Preguntas frecuentes sobre la migración de AC raíz de Google Maps Platform

Este documento incluye las siguientes secciones:

Para obtener una descripción general más detallada de la migración de AC raíz de Google que está en marcha, consulta ¿Qué sucede?

Terminología

A continuación, recopilamos una lista de los términos más importantes que necesitas conocer para este documento. Para obtener una descripción general más completa de la terminología relacionada, consulta las Preguntas frecuentes de Google Trust Services.

Certificado SSL/TLS
Un certificado vincula una clave criptográfica con una identidad.
Los certificados SSL/TLS se usan para autenticar y establecer conexiones seguras con los sitios web. Las entidades conocidas como autoridades certificadoras pueden emitir y firmar de forma criptográfica los certificados.
Los navegadores dependen de certificados que emiten autoridades certificadoras de confianza para saber si la información transmitida se envía al servidor correcto y si está encriptada mientras se encuentra en tránsito.
Capa de conexión segura (SSL)
La capa de conexión segura fue el protocolo más implementado para encriptar las comunicaciones de Internet. El protocolo SSL ya no se considera seguro y no debe usarse.
Seguridad de la capa de transporte (TLS)
La seguridad de la capa de transporte es la sucesora de SSL.
Autoridad certificadora (AC)
Una autoridad certificadora es como una oficina de pasaporte digital para dispositivos y personas. Emite documentos protegidos criptográficamente (certificados) para dar fe de que una entidad (p. ej., un sitio web) es quien dice ser.
Antes de emitir un certificado, las AC son responsables de verificar que los nombres del certificado estén vinculados a la persona o entidad que lo solicita.
El término "autoridad certificadora" puede referirse a organizaciones como Google Trust Services y a los sistemas que emiten certificados.
Almacén de certificados raíz
Un almacén de certificados raíz contiene un conjunto de autoridades certificadoras en las que confía un proveedor de software de aplicación. La mayoría de los navegadores web y sistemas operativos tienen sus propios almacenes de certificados raíz.
Para que se incluya en un almacén de certificados raíz, la autoridad certificadora debe cumplir con los requisitos estrictos que establece el proveedor de software de aplicación.
Por lo general, estos incluyen el cumplimiento de los estándares de la industria, como los requisitos de CA/Browser Forum.
Autoridad de certificación raíz
Un certificado emitido por esta autoridad es el más importante de una cadena de certificados.
Por lo general, los certificados de la AC raíz están autofirmados. Las claves privadas asociadas con ellos se almacenan en instalaciones de alta seguridad y se mantienen sin conexión para protegerlas de accesos no autorizados.
Autoridad certificadora intermedia
Un certificado emitido por esta autoridad se usa para firmar otros certificados en una cadena de certificados.
Las AC intermedias existen principalmente para habilitar la emisión de certificados en línea mientras se permite que el certificado de la AC raíz permanezca sin conexión.
Las AC intermedias también se conocen como AC subordinadas.
Autoridad emisora de certificados
Un certificado de esta autoridad se usa para firmar el certificado que se encuentra en la parte inferior de una cadena de certificados.
Por lo general, este certificado ubicado en la parte inferior se denomina certificado de suscriptor, certificado de entidad final o certificado de hoja. En este documento, también usaremos el término certificado de servidor.
Cadena de certificados
Los certificados están vinculados a su entidad emisora (firmados de manera criptográfica). Una cadena de certificados está compuesta por un certificado de hoja, todos sus certificados emisores y un certificado raíz.
Firma cruzada
Los clientes de proveedores de software de aplicación deben actualizar su almacén de certificados raíz para incluir nuevos certificados de la AC en los que puedan confiar sus productos. Lleva un tiempo para que los productos que contienen los nuevos certificados de la AC se usen ampliamente.
Para aumentar la compatibilidad con los clientes más antiguos, otra AC ya establecida puede "firmar de manera cruzada" los certificados de la AC. Esto crea de forma efectiva un segundo certificado de la AC para la misma identidad (nombre y par de claves).
Según las AC incluidas en su almacén de certificados raíz, los clientes crearán una cadena de certificados diferente hasta alcanzar una raíz en la que confíen.

Información general

¿Qué sucede?

Panorama general

En 2017, Google comenzó un proyecto de varios años para emitir y usar sus propios certificados raíz, las firmas criptográficas que son la base de la seguridad de Internet basada en TLS que usa HTTPS.

Después de la primera fase, la seguridad TLS de los servicios de Google Maps Platform fue garantizada por GS Root R2, una autoridad de certificación (AC) raíz muy conocida y confiable, que Google adquirió de GMO GlobalSign para facilitar la transición a nuestros propios certificados raíz autoemitidos por Google Trust Services (GTS).

Prácticamente todos los clientes de TLS (como navegadores web, smartphones y servidores de aplicaciones) confiaron en este certificado raíz y, por lo tanto, pudieron establecer una conexión segura con los servidores de Google Maps Platform durante la primera fase de la migración.

Sin embargo, deliberadamente, una AC puede no emitir certificados que sean válidos más allá de la fecha en que vence su propio certificado. Como la GS Root R2 vence el 15 de diciembre de 2021, Google migrará sus propios servicios a una nueva AC, GTS Root R1 Cross, con un certificado emitido por la AC raíz propia de Google GTS Root R1.

Si bien la gran mayoría de las bibliotecas cliente de TLS y los sistemas operativos modernos ya confían en las AC raíz de GTS, para garantizar también una transición fluida para la mayoría de los sistemas heredados, Google adquirió una firma cruzada de GMO GlobalSign utilizando GlobalSign Root CA - R1, una de las AC raíz más antiguas y confiables que están disponibles en la actualidad.

Por lo tanto, los clientes de Google Maps Platform de la mayoría de los clientes ya reconocerán alguna (o ambas) de estas AC raíz de confianza y no se verán afectados por la segunda fase de la migración.

Esto también se aplica a los clientes que tomaron medidas durante la primera fase de la migración en 2018, suponiendo que en ese momento siguieron nuestras instrucciones y que instalaron todos los certificados del paquete de AC raíz de confianza de Google.

Debes verificar tus sistemas si se aplica alguna de las siguientes condiciones:

  • Tus servicios ejecutan plataformas no estándares o heredadas, o mantienes tu propio almacén de certificados raíz.
  • No tomaste medidas entre 2017 y 2018, durante la primera fase de la migración de la AC raíz de Google, o bien no instalaste el conjunto completo de certificados del paquete de AC raíz de confianza de Google.

Si alguno de estos puntos se aplica, es posible que tus clientes necesitan actualizar sus certificados raíz a los recomendados para poder garantizar el uso ininterrumpido de Google Maps Platform durante esta etapa de la migración.

Consulta la siguiente información para obtener más detalles técnicos. Para obtener instrucciones generales, consulta la sección Cómo verificar si mi almacén de certificados raíz necesita una actualización.

También te recomendamos que sigas manteniendo tus almacenes de certificados raíz sincronizados con las AC raíz seleccionadas anteriormente para conservar la validez de tus servicios frente a futuros cambios de las AC. Sin embargo, estos cambios se anunciarán con anticipación. Consulta las secciones ¿Cómo obtengo actualizaciones sobre esta fase de la migración? y ¿Cómo puedo recibir avisos anticipados de migraciones futuras? para obtener instrucciones al respecto.

Resumen técnico

Tal como se anunció el 15 de marzo de 2021 en el Blog de seguridad de Google, GS Root R2, la AC raíz que Google Maps Platform utiliza desde 2018, vencerá el 15 de diciembre de 2021. Por lo tanto, durante este año, Google migrará a una AC recientemente emitida: GTS Root R1 Cross. Esto significa que nuestros servicios cambiarán gradualmente a certificados de entidad final de TLS emitidos por esta nueva AC.

Casi todos los clientes y sistemas TLS modernos ya están preconfigurados con el certificado GTS Root R1 o deberían recibirlo por medio de las actualizaciones de software normales. Además, GlobalSign Root AC - R1 debería estar disponible incluso en sistemas heredados más antiguos.

Sin embargo, debes verificar tus sistemas si se aplican al menos los dos puntos siguientes:

  • tus servicios ejecutan plataformas no estándar o heredadas, o mantienes tu propio almacén de certificados raíz
  • No tomaste medidas entre 2017 y 2018, durante la primera fase de la migración de la AC raíz de Google, o bien no instalaste el conjunto completo de certificados del paquete de AC raíz de confianza de Google.

La sección Cómo verificar si mi almacén de certificados raíz necesita una actualización proporciona orientación general para probar si tu sistema se verá afectado.

Consulta la pregunta ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google? para obtener más información.

¿Cómo obtengo actualizaciones sobre esta fase de la migración?

Destaca con una estrella el problema público 186840968 para recibir las actualizaciones correspondientes. Estas preguntas frecuentes también se actualizan a lo largo del proceso de migración, siempre que encontremos temas que puedan ser de interés general.

¿Cómo puedo recibir avisos anticipados de migraciones futuras?

Te recomendamos seguir el Blog de seguridad de Google. También nos esforzaremos por actualizar la documentación específica del producto lo antes posible, después del anuncio público en el blog.

También suscríbete a las notificaciones de Google Maps Platform, ya que publicamos actualizaciones en el foro con frecuencia sobre los cambios que probablemente afecten a una mayor cantidad de clientes.

Utilizamos varios servicios de Google. ¿La migración de AC raíz los afectará a todos?

Sí, la migración de AC raíz se producirá en todos los servicios y las APIs de Google, pero el cronograma puede variar según el servicio. Sin embargo, una vez que hayas verificado que los almacenes de certificados raíz que usan tus aplicaciones cliente de Google Maps Platform contienen todas las AC que se indican en el paquete de AC raíz de confianza de Google, tus servicios no deberían verse afectados por la migración en curso. Además, el hecho de mantenerlos sincronizados también te protegerá contra futuros cambios de AC raíz.

Consulta las preguntas ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google? y ¿Qué tipos de aplicaciones corren el riesgo de fallar? para obtener más información.

La sección Cómo verificar si mi almacén de certificados raíz necesita una actualización a continuación también proporciona instrucciones generales para probar el sistema.

Cómo verificar si mi almacén de certificados raíz necesita una actualización

Prueba el entorno de tu aplicación con los extremos de prueba que se enumeran a continuación:

  • Si puedes establecer una conexión TLS con el extremo de prueba de GTS Root R1 Cross, el vencimiento de GS Root R2 no debería afectar tu aplicación.
  • Si puedes establecer una conexión TLS con el extremo de prueba GTS Root R1, es probable que tu aplicación incluso esté protegida contra el vencimiento de GTS Root R1 Cross y GlobalSign Root CA - R1 en 2028.

Por lo general, tu sistema será compatible con este cambio de AC raíz en los siguientes casos:

  • Tu servicio se ejecuta en un sistema operativo dominante que recibe mantenimiento, y conservas tanto el sistema operativo como las bibliotecas que usa tu servicio con parches y no mantienes tu propio almacén de certificados raíz. O bien:
  • Seguiste nuestras recomendaciones anteriores e instalaste todas las AC raíz del paquete de AC raíz de confianza de Google.

Los clientes potencialmente afectados deben instalar de inmediato los certificados del paquete de AC raíz de confianza de Google para evitar futuras interrupciones del servicio.

Consulta la pregunta ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google? para obtener más información.

¿Existe alguna herramienta simple que pueda usar para verificar nuestro almacén de certificados raíz?

Puedes encontrar dos herramientas de línea de comandos, curl y openssl, que te resultarán útiles para tus investigaciones. Ambas están disponibles en la mayoría de las plataformas y ofrecen muchas opciones para probar tu configuración.

Para ver instrucciones sobre cómo obtener curl, consulta la sección Cómo obtener curl a continuación.

Los comandos de openssl que se muestran a continuación corresponden a la versión 1.1.1 o posterior. Las versiones anteriores a la 1.1.1 no son compatibles. Si usas una versión anterior, actualiza o modifica estos comandos según sea necesario para tu versión. Para ver instrucciones sobre cómo obtener openssl, consulta la sección Cómo obtener OpenSSL a continuación.

También encontrarás otras herramientas útiles en la sección ¿Dónde puedo obtener las herramientas que necesito?, a continuación.

Para obtener instrucciones de prueba concretas, consulta la sección Cómo verificar si mi almacén de certificados raíz necesita una actualización.

Cómo probar tu almacén de certificados raíz predeterminado

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Cómo verificar el paquete de AC raíz de confianza de Google

Descarga el paquete de AC raíz de confianza de Google y, luego, sigue estos pasos:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

¿Cómo y cuándo continuará la migración de la AC raíz de Google?

  1. La primera fase (que se migró a GS Root R2), anunciada en enero de 2017, comenzó a finales de 2017 y concluyó en la primera mitad de 2018.
  2. La segunda fase (migración a GTS Root R1 Cross) se anunció en marzo de 2021 y se lanzará en los próximos meses, antes del vencimiento de la GS Root R2 el 15 de diciembre de 2021.

Los programas de fases de migración posteriores se anunciarán con anticipación suficiente a que se venzan los certificados.

No obstante, podrás hacer que tus apps estén completamente preparadas para seguir vigentes en el futuro si mantienes tus certificados raíz sincronizados con la lista seleccionada de AC raíz del paquete de AC raíz de confianza de Google.

Consulta también la pregunta ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google? para obtener más información.

Plan de lanzamiento general para cada servicio de Google

  1. El lanzamiento en etapas comienza en un solo centro de datos.
  2. Se implementa gradualmente en más centros de datos hasta lograr una cobertura global.
  3. Si se detectan problemas graves en cualquier etapa, las pruebas pueden revertirse de forma temporal mientras se abordan los problemas.
  4. Según los resultados obtenidos con las iteraciones anteriores, se incluyen más servicios de Google en el lanzamiento hasta que, gradualmente, todos los servicios de Google se hayan migrado a los certificados nuevos.

¿Quiénes se verán afectados, cuándo y dónde?

Cada vez más desarrolladores de Google Maps Platform comenzarán a recibir los certificados nuevos a medida que se migren más centros de datos. Los cambios serán localizados en alguna medida, ya que las solicitudes de los clientes tienden a reenviarse a los servidores de centros de datos geográficamente cercanos.

No podemos saber con certeza por anticipado quiénes se verán afectados, cuándo y dónde. Por eso, recomendamos que todos nuestros clientes verifiquen sus sistemas y hagan que estén preparados para seguir vigentes en el futuro, mucho antes de que lleguen las fases siguientes de la migración a la AC raíz de Google.

Consulta la sección Cómo verificar si mi almacén de certificados raíz necesita una actualización para obtener orientación adicional.

¿A qué debe prestarse atención?

Los clientes que no estén configurados con el certificado raíz necesario no podrán verificar su conexión TLS a Google Maps Platform. Cuando esto sucede, los clientes suelen emitir una advertencia que indica un error en la validación del certificado.

Según la configuración de TLS, es posible que los clientes continúen generando una solicitud a Google Maps Platform, o bien rechacen continuar con la solicitud.

¿Cuáles son los requisitos mínimos para que un cliente de TLS se comunique con Google Maps Platform?

Los certificados de Google Maps Platform emplean nombres de asunto alternativos (SAN) de DNS, por lo que el manejo de certificados de un cliente debe ser compatible con los SAN que pueden incluir en el nombre un comodín simple como etiqueta del extremo izquierdo, por ejemplo, *.googleapis.com.

Para conocer otros requisitos, consulta la sección ¿Cuáles son los requisitos recomendados para que un cliente de TLS se comunique con Google? en las Preguntas frecuentes de GTS.

¿Qué tipos de aplicaciones corren el riesgo de fallar?

La aplicación usa el almacén de certificados raíz del sistema sin restricciones impuestas por el desarrollador

Aplicaciones para servicios web de Google Maps Platform

Si usas un SO común, p. ej., Ubuntu, Red Hat, Windows 10 o Server 2019, OS X) que aún se mantiene y recibe actualizaciones regulares, tu almacén de certificados raíz predeterminado ya debería incluir el certificado GTS Root R1.

Si usas una versión de SO heredada que ya no recibe actualizaciones, puede o no que tengas el certificado GS Root R1. Sin embargo, es probable que tu almacén de certificados raíz contenga GlobalSign Root CA - R1, una de las AC raíz más antiguas y ampliamente confiables.

En las aplicaciones para dispositivos móviles que llaman a los servicios web de Google Maps Platform directamente desde el dispositivo del usuario final, se aplican las pautas mencionadas en la pregunta Las aplicaciones para dispositivos móviles ¿corren el riesgo de fallar?

Aplicaciones del cliente de Google Maps Platform

Las aplicaciones de la API de Maps JavaScript generalmente dependen de los certificados raíz del navegador web en el que se ejecuta la aplicación. Consulta la sección Las aplicaciones de JavaScript ¿corren el riesgo de fallar? para obtener más información.

En las aplicaciones nativas para dispositivos móviles que usan el SDK de Maps para Android, el SDK de Maps para iOS, el SDK de Places para Android o el SDK de Places para iOS, se aplican las mismas reglas que para las apps que llaman a los servicios web de Google Maps Platform.

Consulta la pregunta ¿Las apps para dispositivos móviles corren el riesgo de fallar? para obtener más información.

La app usa su propio paquete de certificados o utiliza funciones de seguridad avanzadas, como la fijación de certificados

Deberás asegurarte de actualizar el paquete de certificados por tu cuenta. Como se explicó en la pregunta ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google?, te recomendamos que importes todos los certificados del paquete de AC raíz de confianza de Google a tu propio almacén de certificados raíz.

Si fijas certificados o claves públicas para los dominios de Google a los que se conecta tu aplicación, debes agregar los certificados y las claves públicas a la lista de entidades de confianza de tu aplicación.

Para obtener más información sobre la fijación de certificados o claves públicas, consulta los recursos externos que se mencionan en la pregunta ¿Necesitas más información?

¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de AC raíz de confianza de Google?

La lista seleccionada que se incluye en el paquete de AC raíz de confianza de Google abarca todas las AC que los servicios de Google podrían utilizar en el futuro inmediato.

Por lo tanto, si deseas que tu sistema esté completamente preparado para seguir vigente en el futuro, te recomendamos que verifiques que tu almacén de certificados raíz contenga todos los certificados del paquete y que adquieras el hábito de mantenerlos sincronizados.

Esto es muy importante si tus servicios se ejecutan en una versión del sistema operativo no mantenida, por otros motivos no puedes mantener el sistema operativo y las bibliotecas con los parches necesarios o mantienes tu propio almacén de certificados raíz.

Consulta la pregunta ¿Cómo puedo recibir avisos anticipados de migraciones futuras? para averiguar cómo obtener actualizaciones sobre las migraciones de AC raíz futuras. Sincronizar rutinariamente el almacén de certificados raíz con la lista seleccionada protegerá los servicios contra futuras interrupciones debido a cambios de AC y mantendrá los servicios en ejecución después de que se venzan tanto GTS Root R1 Cross como GlobalSign Root CA - R1.

Además, consulta la pregunta Estoy creando un producto que se conecta con los servicios de Google. ¿En qué certificados de la AC debo confiar? en las Preguntas frecuentes de GTS para obtener más recomendaciones.

¿Por qué no debo instalar ningún certificado de la AC intermedio o de hoja?

Si lo haces, correrás el riesgo de que tu aplicación falle cuando inscribamos un nuevo certificado o cambiemos las AC intermedias. Cualquiera de estas situaciones puede ocurrir en cualquier momento y sin aviso previo, y se aplica de manera equitativa a los certificados de servidor individuales, como los que entrega maps.googleapis.com, así como a cualquier otra de nuestras AC intermedias, por ejemplo, GTS Root R1 Cross.

Para proteger tus servicios contra esto, solo debes instalar los certificados raíz del paquete de AC raíz de confianza de Google y confiar en el certificado raíz únicamente para verificar la confiabilidad de toda la cadena de certificados anclada a él.

Toda implementación actualizada de la biblioteca de TLS debería poder verificar automáticamente esas cadenas de confianza, siempre y cuando la autoridad de certificación raíz sea confiable.

Las aplicaciones de JavaScript ¿corren el riesgo de fallar?

Los certificados raíz de GTS ya están bien incorporados en la mayoría de los navegadores actualizados y estos confían en él, y la firma cruzada de GMO GlobalSign debería garantizar una migración sin problemas incluso para la mayoría de los usuarios finales que usan navegadores heredados. Esto incluye todos los navegadores oficialmente compatibles con la API de Maps JavaScript.

Cada navegador actualizado debería permitir que los usuarios finales verifiquen y editen los certificados en los que este confía. Aunque la ubicación exacta difiere en cada navegador, la lista de certificados se suele encontrar en algún lugar dentro de Configuración.

Las aplicaciones para dispositivos móviles ¿corren el riesgo de fallar?

También se espera que los dispositivos Android y Apple iOS que todavía reciben actualizaciones regulares de su fabricante sigan funcionando sin problemas en el futuro. Los teléfonos Android más antiguos incluyen, al menos, el certificado GlobalSign Root CA - R1, aunque la lista de certificados confiables puede variar en función del fabricante del teléfono celular, el modelo del dispositivo y la versión de Android.

Sin embargo, es posible que la compatibilidad con las AC raíz de GTS, incluida GTS Root R1, siga siendo limitada en las versiones de Android anteriores a la versión 10.

En el caso de los dispositivos iOS, Apple mantiene una lista de las AC raíz de confianza para cada versión reciente de iOS en sus páginas de asistencia. Sin embargo, todas las versiones 5 y posteriores de iOS admiten la certificación GlobalSign Root CA - R1.

Las AC raíz de GTS, incluida GTS Root R1, son compatibles desde la versión 12.1.3 de iOS.

Consulta la sección ¿Cómo puedo verificar los certificados raíz de confianza en mi teléfono celular? para obtener más detalles.

¿Cuándo mi navegador o sistema operativo incluirán los certificados raíz de Google Trust Services?

En los últimos años, Google trabajó exhaustivamente con todas las principales empresas externas que mantienen los paquetes de certificados raíz más utilizados y confiables. Esto incluye, por ejemplo, a los fabricantes de sistemas operativos, como Apple y Microsoft, pero también a los equipos propios de Google dedicados a Android y ChromeOS; a los desarrolladores de navegadores, como Mozilla, Apple y Microsoft, pero también al equipo de Chrome dentro de Google, y a los fabricantes de hardware, como teléfonos, decodificadores, TVs, impresoras y consolas de juegos, entre otros.

Por lo tanto, es muy probable que cualquier sistema mantenido ya admita las nuevas AC raíz de GTS de Google, incluida GTS Root R1, y hasta los sistemas heredados tienen una alta probabilidad de admitir GlobalSign Root CA - R1, que se usará durante los próximos años para firmar de forma cruzada los certificados que emita Google.

No obstante, dado que los cronogramas de inclusión de certificados de terceros están fuera del control de Google, la mejor sugerencia general que podemos ofrecer es que te asegures de aplicar con regularidad las actualizaciones del sistema que haya disponibles.

Es posible que algunos terceros hayan documentado sus propios cronogramas de inclusión de certificados, como es el caso del Programa de Certificados de la AC de Mozilla.

Solución de problemas

¿Dónde puedo obtener las herramientas que necesito?

Cómo obtener curl

Si la distribución de tu SO no incluye la herramienta curl, puedes descargarla de https://curl.haxx.se/. Puedes descargar el código fuente y compilar la herramienta tú mismo o descargar un objeto binario ya compilado si hay uno disponible para tu plataforma.

Cómo obtener OpenSSL

Si la distribución de tu SO no incluye la herramienta openssl, puedes descargar el código fuente de https://www.openssl.org/ y compilarla. En https://www.openssl.org/community/binaries.html, puedes encontrar una lista de objetos binarios compilados por terceros. Sin embargo, el equipo de OpenSSL no respalda ni recomienda específicamente ninguna de estas compilaciones.

Cómo obtener Wireshark, Tshark o Tcpdump

Si bien la mayoría de las distribuciones de Linux ofrecen wireshark, su herramienta de línea de comandos tshark y tcpdump, puedes encontrar versiones ya compiladas de los dos primeros para otros SO en https://www.wireshark.org.

Puedes encontrar el código fuente de Tcpdump y LibPCAP en https://www.tcpdump.org.

Puedes encontrar documentación sobre estas herramientas útiles en la Guía del usuario de Wireshark, la página del manual de Tshark y la página del manual de Tcpdump, respectivamente.

Cómo obtener Java Keytool

La herramienta de línea de comandos keytool debería estar incluida en todas las versiones del Java Development Kit (JDK) o Java Runtime Environment (JRE). Instálalas para obtener keytool.. Sin embargo, es poco probable que keytool sea necesario para verificar certificados raíz, a menos que tu aplicación se compile con Java.

¿Qué hacer si se interrumpe la producción?

Lo más importante que debes hacer es instalar los certificados raíz necesarios del paquete de AC raíz de confianza de Google en el almacén de certificados raíz que utiliza tu aplicación.

  1. Trabaja junto con los administradores de tu sistema para actualizar tu almacén de certificados raíz local.
  2. Consulta estas preguntas frecuentes para ver los puntos aplicables a tu sistema.
  3. Si necesitas más ayuda específica sobre la plataforma o el sistema, comunícate con los canales de asistencia técnica que ofrece el proveedor de tu sistema.
  4. Si deseas obtener asistencia general, comunícate con nuestro equipo de asistencia, tal como se describe en la sección Cómo comunicarte con el equipo de asistencia de Google Maps Platform. Nota: En el caso de los problemas específicos de la plataforma, se proporciona orientación solo en función de las posibilidades disponibles.
  5. Destaca con una estrella el problema público 186840968 para recibir más actualizaciones relacionadas con el proceso de migración.

Cómo comunicarte con el equipo de asistencia de Google Maps Platform

Pasos iniciales para la solución de problemas

Consulta la sección Cómo verificar si mi almacén de certificados raíz necesita una actualización para ver instrucciones sobre la solución de problemas generales.

La sección Cómo administrar tus certificados de confianza también puede proporcionar información valiosa si necesitas importar o exportar certificados raíz.

Si el problema no se resuelve, y decides comunicarte con el equipo de asistencia de Google Maps Platform, prepárate para proporcionar también la siguiente información:

  1. ¿Dónde se encuentran tus servidores afectados?
  2. ¿A qué direcciones IP de Google llama tu servicio?
  3. ¿Qué API se ven afectadas por este problema?
  4. ¿Cuándo comenzó exactamente el problema?

  5. Resultados de los siguientes comandos:

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Si deseas ver instrucciones sobre cómo obtener las herramientas necesarias, consulta la pregunta ¿Dónde puedo obtener las herramientas que necesito?

Cómo crear un caso de asistencia

Sigue las instrucciones para crear un caso de asistencia en Asistencia y recursos de Google Maps Platform.

Cuando crees un caso de asistencia, además de los datos que se mencionan en la sección Pasos iniciales para la solución de problemas, también proporciona la siguiente información:

  • ¿Cuáles son tus direcciones IP públicas?
  • ¿Cuál es la dirección IP pública de tu servidor DNS?
  • Si es posible, una captura de los paquetes tcpdump o Wireshark de la negociación TLS fallida con https://maps.googleapis.com/ en formato PCAP que emplee una longitud de instantánea lo suficientemente grande para captar todo el paquete sin truncarlo (p. ej., con -s0 en versiones anteriores de tcpdump).
  • Si es posible, los extractos de los registros de tu servicio en los que se vea el motivo exacto de la falla de conexión TLS, preferentemente con la información completa de la cadena de certificados del servidor

Si deseas ver instrucciones sobre cómo obtener las herramientas necesarias, consulta la pregunta ¿Dónde puedo obtener las herramientas que necesito?

Cómo publicar comentarios en el problema público 186840968

Cuando publiques un comentario en el problema público 186840968, incluye la información que se menciona en la sección Pasos iniciales para la solución de problemas.

¿Cómo puedo determinar la dirección pública de mi DNS?

En Linux, puedes ejecutar el siguiente comando:

dig -t txt o-o.myaddr.l.google.com

En Windows, puedes usar nslookup en modo interactivo:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Cómo interpretar el resultado de curl

Ejecutar curl con las marcas -vvI proporciona información muy útil. A continuación, se brindan algunas instrucciones para interpretar el resultado:

  • Las líneas que comienzan con "*" muestran el resultado de la negociación TLS, así como información sobre la finalización de la conexión.
  • Las líneas que comienzan con ">" muestran la solicitud HTTP saliente enviada por curl.
  • Las líneas que comienzan con "<" muestran la respuesta HTTP que se recibe desde el servidor.
  • Si el protocolo era HTTPS, la presencia de líneas con “>” o “<” implica un protocolo de enlace TLS exitoso.

Biblioteca de TLS y paquete de certificados raíz utilizados

Ejecutar curl con las marcas -vvI también imprime el almacén de certificados raíz utilizado, pero el resultado exacto puede variar según el sistema, tal como se muestra aquí.

El resultado de una máquina con Red Hat Linux que tiene curl vinculado a NSS puede contener las siguientes líneas:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

El resultado de una máquina con Ubuntu o Debian Linux puede contener las siguientes líneas:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

Si se trata de una máquina con Ubuntu o Debian Linux que utiliza el archivo PEM de certificados raíz de Google, el resultado obtenido usando la marca --cacert puede contener las siguientes líneas:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

Usuario-agente

Las solicitudes salientes contienen el encabezado User-Agent que puede proporcionar información útil sobre curl y tu sistema.

Ejemplo de una máquina con Red Hat Linux:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Error en el protocolo de enlace TLS

Las líneas como las que se ven en esta muestra de código indican que la conexión se interrumpió en medio del protocolo de enlace TLS. Esto se debe a un certificado de servidor que no es de confianza. La ausencia de un resultado de depuración que comience con > o < también es un indicador fuerte de un intento de conexión fallido:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

Protocolo de enlace TLS exitoso

La presencia de líneas similares a las que se ven en esta muestra de código indica un protocolo de enlace TLS exitoso. Debería mostrarse el paquete de algoritmos de cifrado utilizado para la conexión encriptada, así como los detalles del certificado de servidor aceptado. Además, la presencia de líneas que comiencen con > o < indica que el tráfico HTTP de carga útil se transmitió correctamente a través de la conexión TLS encriptada:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

Cómo imprimir los certificados de servidor recibidos en un formato de lenguaje natural

Suponiendo que el resultado tiene formato PEM, p. ej., el resultado de openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, puedes hacer lo siguiente para imprimir el certificado obtenido:

  • Copia todo el certificado codificado en Base64, incluidos el encabezado y el pie de página:

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • Luego, escribe lo siguiente:

    openssl x509 -inform pem -noout -text
````

  • A continuación, pega el contenido de tu búfer de copia en la terminal.

  • Presiona la tecla Intro.

Para ver ejemplos de entrada y salida, consulta la sección Cómo imprimir certificados PEM en un formato de lenguaje natural.

¿Cómo son los certificados de Google firmados de forma cruzada en OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

Cómo administrar tus certificados de confianza

¿Cómo puedo verificar los certificados raíz de confianza en mi teléfono celular?

Certificados de confianza de Android

Tal como se mencionó en la pregunta Las aplicaciones para dispositivos móviles ¿corren el riesgo de fallar?, desde la versión 4.0, Android permite que los usuarios de teléfonos celulares verifiquen la lista de certificados de confianza en Configuración. En esta tabla, se muestra la ruta de acceso exacta del menú Configuración:

Versión de Android Ruta de acceso al menú
1.x, 2.x, 3.x N/A
4.x, 5.x, 6.x, 7.x Configuración > Seguridad > Credenciales de confianza
8.x, 9 Configuración > Seguridad y ubicación > Encriptación y credenciales > Credenciales de confianza
10 y posteriores Configuración > Seguridad > Avanzado > Encriptación y credenciales > Credenciales de confianza

En la siguiente tabla, se muestra la disponibilidad probable de los certificados raíz más importantes por versión de Android, según la verificación manual usando imágenes de sistema para dispositivos virtuales de Android (AVD) actualmente disponibles. Cuando las imágenes del sistema ya no están disponibles, se recurre al historial de versiones del repositorio ca-certificates de Git perteneciente a AOSP:

Versión de Android GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (válido hasta el 15 de diciembre de 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10 y posteriores

Por lo general, no se puede actualizar el almacén de certificados raíz del sistema Android sin una actualización de firmware o permisos de administrador en el dispositivo. Sin embargo, en la mayoría de las versiones de Android que todavía se usan ampliamente, es probable que el conjunto actual de certificados raíz de confianza proporcione servicios sin interrupciones durante varios años, más allá de la vida útil de la mayoría de los dispositivos existentes.

A partir de la versión 7.0, Android ofrece a los desarrolladores de aplicaciones un método seguro para agregar certificados que solo son de confianza para su aplicación. Para ello, empaqueta los certificados con la aplicación y crea una configuración de seguridad de red personalizada, tal como se describe en el documento de capacitación Configuración de seguridad de la red de las prácticas recomendadas de Android sobre seguridad y privacidad.

Sin embargo, dado que los desarrolladores de aplicaciones de terceros no podrán influir sobre la configuración de seguridad de la red del tráfico que se origina desde el APK de Servicios de Google Play, es probable que estas iniciativas solo proporcionen una solución alternativa parcial.

En los dispositivos heredados más antiguos, la única opción disponible consiste en confiar en las AC agregadas por el usuario, instaladas a través de una política de grupo empresarial aplicada al dispositivo del usuario final o por los propios usuarios finales.

iOS Trust Store

Si bien Apple no muestra directamente su conjunto predeterminado de certificados raíz de confianza al usuario del teléfono celular, la empresa tiene vínculos a los conjuntos de AC raíz de confianza para las versiones 5 y posteriores de iOS. Esto se puede ver en los artículos de asistencia de Apple:

Sin embargo, todo certificado adicional que se instale en el dispositivo iOS debería aparecer en Configuración > General > Perfil. Si no se instalan certificados adicionales, es posible que el elemento de menú Perfil no se muestre.

En esta tabla, se muestra la disponibilidad de los certificados raíz más importantes por versión de iOS, según las fuentes antes mencionadas:

Versión de iOS GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (válido hasta el 15 de diciembre de 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3 y posteriores

¿Dónde se encuentra el almacén de certificados raíz de mi sistema y cómo puedo actualizarlo?

La ubicación del almacén de certificados raíz predeterminado varía según el sistema operativo y la biblioteca SSL/TLS utilizada. Sin embargo, en la mayoría de las distribuciones de Linux, los certificados raíz predeterminados se pueden encontrar en una de las siguientes rutas de acceso:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, versiones anteriores de RHEL y CentOS
  • /etc/pki/ca-trust/source/anchors y /usr/share/pki/ca-trust-source: Fedora, versiones RHEL y CentOS más recientes
  • /var/lib/ca-certificates: OpenSUSE

Las siguientes son otras rutas de acceso posibles a los certificados:

  • /etc/ssl/certs: Debian, Ubuntu
  • /etc/pki/tls/certs: RHEL, CentOS

Algunos de los certificados de estos directorios probablemente sean vínculos simbólicos a archivos que están en otros directorios.

Almacén de certificados raíz de OpenSSL

Para las aplicaciones que usan OpenSSL, puedes verificar la ubicación configurada de sus componentes instalados, incluido el almacén de certificados predeterminado, usando el siguiente comando:

openssl version -d

El comando imprime OPENSSLDIR, que corresponde al directorio de nivel superior dentro del cual se pueden encontrar la biblioteca y sus configuraciones:

OPENSSLDIR: "/usr/lib/ssl"

El almacén de certificados raíz se encuentra en el subdirectorio certs.

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

Si OpenSSL se basa en el almacén de certificados raíz predeterminado del sistema, como en el ejemplo anterior, consulta la sección ¿Dónde se encuentra el almacén de certificados raíz de mi sistema y cómo puedo actualizarlo? para garantizar que el paquete de certificados raíz del sistema esté actualizado.

Para ver instrucciones sobre cómo obtener openssl, consulta la sección Cómo obtener OpenSSL.

Almacén de certificados raíz de Java

Las aplicaciones de Java pueden usar su propio almacén de certificados raíz, que en los sistemas Linux, por lo general, se encuentra en /etc/pki/java/cacerts o /usr/share/ca-certificates-java, y se puede administrar con la herramienta de línea de comandos de Java keytool.

Para importar un certificado individual a tu almacén de certificados de Java, ejecuta el siguiente comando:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

Simplemente reemplaza cert.pem por el archivo de certificado correspondiente a cada certificado raíz recomendado, alias por un alias de certificado único pero significativo y certs.jks por el archivo de base de datos de certificados que utilices en tu entorno.

Para obtener más información, consulta los siguientes artículos de Oracle y Stack Overflow:

Almacén de certificados raíz de Mozilla NSS

Es posible que las aplicaciones que usan Mozilla NSS también empleen de forma predeterminada una base de datos de certificados de todo el sistema, ubicada normalmente en /etc/pki/nssdb, o un almacén predeterminado específico del usuario, configurado en ${HOME}/.pki/nssdb.

Para actualizar la base de datos NSS, usa la herramienta certutil.

Para importar un archivo de certificado individual a tu base de datos NSS, ejecuta el siguiente comando:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

Simplemente reemplaza cert.pem por el archivo de certificado correspondiente a cada certificado raíz recomendado; cert-name por un sobrenombre de certificado que te resulte significativo, y certdir por la ruta de acceso a la base de datos de certificados que utilices en tu entorno.

Para obtener más información, consulta el manual oficial de NSS Tools certutil y la documentación de tu sistema operativo.

Almacén de certificados raíz de Microsoft .NET

A los desarrolladores de Windows .NET, les resultarán útiles al menos los siguientes artículos de Microsoft para actualizar su almacén de certificados raíz:

Formatos de archivo de los certificados

¿Qué es un archivo PEM?

Privacy-Enhanced Mail (PEM) es un formato de archivo de texto estándar utilizado de facto para almacenar y enviar certificados criptográficos, claves, etc., que se formalizó como estándar en RFC 7468.

Si bien el formato del archivo en sí está en un formato legible por humanos, no sucede lo mismo con la información de datos del certificado binario, que está codificada en Base64. Sin embargo, la especificación PEM permite emitir un texto explicativo antes o después del cuerpo del certificado codificado. Muchas herramientas usan esta función para proporcionar también un resumen claro de los datos más relevantes de un certificado.

Hay herramientas, como openssl, que también se pueden usar para decodificar todo el certificado en formato legible por humanos. Consulta la sección Cómo imprimir certificados PEM en un formato de lenguaje natural para obtener más información.

¿Qué es un archivo ".crt"?

Las herramientas que permiten exportar certificados en formato PEM comúnmente usan la extensión de archivo ".crt" para indicar que el archivo emplea codificación del texto.

¿Qué es un archivo DER?

Las Reglas de codificación distinguidas (DER) constituyen un formato binario estandarizado para la codificación de certificados. Los certificados en archivos PEM son generalmente certificados DER codificados en Base64.

¿Qué es un archivo ".cer"?

Un archivo exportado con un sufijo ".cer" puede contener un certificado con codificación PEM, pero es más habitual que contenga un objeto binario, generalmente con codificación DER. Por convención, los archivos ".cer" suelen contener un solo certificado.

Mi sistema no importa todos los certificados de roots.pem

Algunos sistemas, p. ej., Java keytool, solo puede importar un único certificado desde un archivo PEM, incluso si contiene varios. Consulta la pregunta ¿Cómo puedo extraer certificados individuales de roots.pem? para ver cómo se puede dividir el archivo.

¿Cómo puedo extraer certificados individuales de roots.pem?

Puedes dividir roots.pem en los certificados que lo componen con la siguiente secuencia de comandos bash simple:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Esto debería crear una cantidad de archivos PEM individuales similares a los que se muestran a continuación:

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

Los archivos PEM individuales, como 02265526.pem, se pueden importar por separado o se los puede convertir a un formato de archivo que acepte tu almacén de certificados.

Cómo convertir archivos entre el formato PEM y uno compatible con mi sistema

Puedes usar la herramienta de línea de comandos openssl de OpenSSL para convertir archivos entre todos los formatos de archivo de certificados comúnmente utilizados. A continuación, se brindan las instrucciones para convertir un archivo PEM a los formatos de archivo de certificados más utilizados.

Para obtener una lista completa de las opciones disponibles, consulta la documentación oficial de OpenSSL Command Line Utilities (Utilidades de la línea de comandos de OpenSSL).

Para ver instrucciones sobre cómo obtener openssl, consulta la sección Cómo obtener OpenSSL.

¿Cómo convierto un archivo PEM a DER?

Con openssl, puedes ejecutar el siguiente comando para convertir un archivo de PEM a DER:

openssl x509 -in roots.pem -outform der -out roots.der
¿Cómo convierto un archivo PEM a PKCS #7?

Con openssl, puedes emitir el siguiente comando para convertir un archivo de PEM a PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
¿Cómo convierto un archivo PEM a PKCS #12 (PFX)?

Con openssl, puedes ejecutar el siguiente comando para convertir un archivo de PEM a PKCS #12:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

Cuando creas un archivo PKCS #12, debes proporcionar una contraseña de archivo. Asegúrate de guardarla en un lugar seguro si no importas de inmediato el archivo PKCS #12 a tu sistema.

Cómo listar, imprimir y exportar certificados desde el almacén de certificados raíz

¿Cómo exporto un certificado de Java Key Store como un archivo PEM?

Con keytool, puedes ejecutar el siguiente comando para enumerar todos los certificados de tu almacén de certificados, junto con el alias que puedes usar para exportar cada uno:

keytool -v -list -keystore certs.jks

Solo reemplaza certs.jks por el archivo de base de datos de certificados que utilices en tu entorno. Con este comando, también se mostrará el alias de cada certificado, que necesitarás si deseas exportarlo.

Para exportar un certificado individual en formato PEM, ejecuta el siguiente comando:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

Solo reemplaza certs.jks por el archivo de base de datos de certificados que utilices en tu entorno y proporciona un alias y un alias.pem correspondientes al certificado que deseas exportar.

Para obtener más información, consulta el manual de Java Platform, Standard Edition Tools Reference: keytool (Referencia de herramientas de Java Platform Standard Edition: keytool).

¿Cómo exporto un certificado desde el almacén de certificados raíz NSS como un archivo PEM?

Con certutil, puedes ejecutar el siguiente comando para enumerar todos los certificados de tu almacén de certificados, junto con el sobrenombre que puedes usar para exportar cada uno:

certutil -L -d certdir

Solo reemplaza certdir por la ruta de la base de datos de certificados que utilices en tu entorno. Este comando también mostrará el sobrenombre de cada certificado, que necesitarás si deseas exportarlo.

Para exportar un certificado individual en formato PEM, ejecuta el siguiente comando:

certutil -L -n cert-name -a -d certdir > cert.pem

Solo reemplaza certdir por la ruta de acceso de la base de datos de certificados que utilices en tu entorno y proporciona un cert-name y un cert.pem correspondientes al certificado que deseas exportar.

Para obtener más información, consulta el manual oficial de NSS Tools certutil y la documentación de tu sistema operativo.

Cómo imprimir certificados PEM en un formato legible por humanos

En los ejemplos siguientes, suponemos que tienes el archivo GTS_Root_R1.pem con el siguiente contenido:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
Cómo imprimir archivos de certificados con OpenSSL

Ejecutar el comando

openssl x509 -in GTS_Root_R1.pem -text

debería generar un resultado similar al siguiente:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

Para ver instrucciones sobre cómo obtener openssl, consulta la sección Cómo obtener OpenSSL.

Cómo imprimir certificados utilizando Java Keytool

Ejecutar el siguiente comando

keytool -printcert -file GTS_Root_R1.pem

debería generar un resultado similar al siguiente:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Para ver instrucciones sobre cómo obtener keytool, consulta la sección Cómo obtener Java Keytool.

¿Cómo puedo ver qué certificados están instalados en mi almacén de certificados raíz?

Esto varía según el sistema operativo y la biblioteca SSL/TLS utilizada. Sin embargo, las herramientas que permiten exportar certificados desde el almacén de certificados raíz, así como importarlos en él, suelen proporcionar una opción para mostrar una lista de los certificados instalados.

Además, si exportaste correctamente los certificados raíz de confianza a archivos PEM, o tu almacén de certificados raíz ya contiene este tipo de archivos, puedes intentar abrirlos en cualquier editor de texto, ya que se trata de archivos con texto sin formato.

El archivo PEM se puede etiquetar correctamente. Esto permite obtener información legible por humanos sobre la autoridad certificadora relacionada (ejemplo del paquete de AC raíz de confianza de Google):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

El archivo también puede contener solo la parte del certificado. En estos casos, el nombre del archivo, como GTS_Root_R1.pem, puede describir a qué AC pertenece el certificado. También se garantiza que la cadena del certificado entre los tokens -----BEGIN CERTIFICATE----- y -----END CERTIFICATE----- sea única para cada AC.

Sin embargo, aunque no cuentes con las herramientas anteriores, dado que todos los certificados del paquete de AC raíz de confianza de Google están bien etiquetados, puedes asociar de manera confiable las AC raíz del paquete con las de tu almacén de certificados raíz con Issuer, o comparando las cadenas de certificados del archivo PEM.

Los navegadores web pueden usar sus propios almacenes de certificados raíz o basarse en el predeterminado que proporciona el sistema operativo. No obstante, todos los navegadores actualizados deberían permitirte administrar o, al menos, ver el conjunto de AC raíz en las que confían. Consulta la pregunta Las aplicaciones de JavaScript ¿corren el riesgo de fallar? para obtener más información.

Para obtener instrucciones específicas para teléfonos celulares, consulta la pregunta separada ¿Cómo puedo verificar los certificados raíz de confianza en mi teléfono celular?

Apéndice

¿Necesitas más información?

Siempre consulta más que nada la documentación de tu sistema operativo y de los lenguajes de programación y las bibliotecas externas que utilice tu aplicación.

Cualquier otra fuente de información, incluidas estas preguntas frecuentes, puede estar desactualizada o ser incorrecta, y no debe interpretarse como autorizada. Sin embargo, es posible que encuentres información útil en muchas de las comunidades de preguntas y respuestas de Stack Exchange y en sitios como AdamW on Linux and more y confirm Blog, entre otros.

Consulta también las Preguntas frecuentes de Google Trust Services.

Para obtener más detalles sobre temas avanzados, como la fijación de certificados, te puede resultar útil consultar las guías Certificate and Public Key Pinning (Fijación de certificados y de claves públicas) y Pinning Cheat Sheet (Hoja de referencia sobre la fijación de certificados) de Open Web Application Security Project (OWASP). Para obtener instrucciones específicas sobre Android, consulta el documento oficial de capacitación Seguridad con HTTPS y SSL de las prácticas recomendadas de Android sobre seguridad y privacidad. Para obtener información sobre la fijación de certificados en comparación con la fijación de claves públicas en Android, puede que te resulte útil la entrada de blog de Matthew Dolan: Android Security: SSL Pinning (Seguridad de Android: fijación de SSL).

El documento de capacitación Configuración de seguridad de la red de las prácticas recomendadas de Android sobre seguridad y privacidad, así como la entrada de blog de JeroenHD, Android 7 Nougat and certificate authorities (Android 7 Nougat y las autoridades certificadoras), proporcionan más información sobre cómo administrar certificados de confianza adicionales en Android.

Para obtener una lista completa de las AC raíz de confianza para el AOSP, consulta el repositorio ca-certificates de Git. Para conocer las versiones basadas en bifurcaciones no oficiales de Android, p. ej., LineageOS, consulta los repositorios correspondientes proporcionados por el proveedor del SO.