Preguntas frecuentes sobre la migración de CA 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 CA 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 emitidos por autoridades certificadoras de confianza para saber si la información transmitida se envía al servidor correcto y si está encriptada mientras va 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 (CA)
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 CA 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 certificadora raíz
Un certificado emitido por esta autoridad es el más importante de una cadena de certificados.
Por lo general, los certificados de CA 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 CA intermedias existen principalmente para habilitar la emisión de certificados en línea mientras se permite que el certificado de CA raíz permanezca sin conexión.
Las CA intermedias también se conocen como CA 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 CA en los que puedan confiar sus productos. Lleva un tiempo que los productos que contienen los nuevos certificados de CA se usen ampliamente.
Para aumentar la compatibilidad con los clientes más antiguos, otra CA ya establecida puede “firmar de manera cruzada” los certificados de CA. Esto crea de forma efectiva un segundo certificado de CA para la misma identidad (nombre y par de claves).
Según las CA incluidas en su almacén de certificados raíz, los clientes crearán una cadena de certificados diferente hasta 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 estuvo garantizada por GS Root R2, una autoridad certificadora (CA) raíz muy conocida y de gran confianza, 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, por diseño, una CA 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 CA, GTS Root R1 Cross, con un certificado emitido por la CA raíz propia de Google GTS Root R1.

Si bien la gran mayoría de los sistemas operativos actualizados y las bibliotecas cliente de TLS ya confían en las CA raíz de GTS, para garantizar una transición fluida desde la mayoría de los sistemas heredados, Google adquirió una firma cruzada de GMO GlobalSign utilizando GlobalSign Root CA - R1, una de las CA 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 de estas CA raíz (o ambas) 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 de 2018, suponiendo que en ese momento siguieron nuestras instrucciones y que instalaron todos los certificados de Paquete de CA raíz de confianza de Google.

Debes verificar tus sistemas si se aplican las siguientes condiciones:

  • 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 CA raíz de Google, o no instalaste el conjunto completo de certificados del paquete de CA raíz de confianza de Google

Si se aplica lo anterior, es posible que tus clientes deban actualizarse con los certificados raíz recomendados para poder garantizar el uso ininterrumpido de Google Maps Platform durante esta fase 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 mantener los almacenes de certificados raíz sincronizados con el paquete de CA raíz seleccionado anteriormente para que tus servicios puedan sobrellevar sin problemas cualquier cambio de CA raíz en el futuro. 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

Como se anunció el 15 de marzo de 2021 en el Blog de seguridad de Google, GS Root R2, la CA raíz que usa Google Maps Platform desde principios de 2018 vencerá el 15 de diciembre de 2021. Por lo tanto, durante este año, Google migrará a una CA recientemente emitida: GTS Root R1 Cross. Esto significa que nuestros servicios realizarán una transición gradual a los certificados de hoja de TLS emitidos por esta CA nueva.

Casi todos los clientes y sistemas TLS actualizados ya están preconfigurados con el certificado GTS Root R1 o deberían recibirlo mediante las actualizaciones de software normales. Además, GlobalSign Root CA - R1 incluso debería estar disponible 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 CA raíz de Google, o no instalaste el conjunto completo de certificados del paquete de CA 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 CA 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 CA raíz los afectará a todos?

Sí, la migración de CA raíz se producirá en todos los servicios y las API 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 CA que se enumeran en el paquete de CA 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 CA raíz.

Consulta las preguntas ¿Por qué debería mantener mi almacén de certificados raíz sincronizado con el paquete de CA 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, no deberías verte afectado por el vencimiento de GS Root R2.
  • Si puedes establecer una conexión TLS con el extremo de prueba GRS 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 CA raíz en los siguientes casos:

  • tu servicio se ejecuta en un sistema operativo popular, y mantienes tanto el sistema operativo como las bibliotecas que usa el servicio con parches y no mantienes tu propio almacén de certificados raíz o
  • seguiste nuestras recomendaciones anteriores e instalaste todas las CA raíz del paquete de CA raíz de confianza de Google

Los clientes potencialmente afectados deben instalar de inmediato los certificados del paquete de CA 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 CA 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.

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.r1demo.pki.goog/; \
openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.r1xdemo.pki.goog/; \
openssl s_client -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

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

Descarga el paquete de CA 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.r1demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
<span class="no-select">$ </span>curl -vvI --cacert roots.pem https://good.r1xdemo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

¿Cómo y cuándo continuará la migración de la CA 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 vigente en el futuro si mantienes tus certificados raíz sincronizados con la lista seleccionada de CA raíz del paquete de CA 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 CA 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 CA 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 CA raíz más antiguas y 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 aplicaciones para dispositivos móviles ¿corren el riesgo de fallar? a fin de 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 CA raíz de confianza de Google?, te recomendamos que importes todos los certificados del paquete de CA raíz de confianza de Google en 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 CA raíz de confianza de Google?

La lista seleccionada de CA raíz del paquete de CA raíz de confianza de Google incluye todas las CA 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 enfáticamente verificar 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 CA raíz futuras. Mantener de forma rutinaria el almacenamiento de certificados raíz en sincronización con la lista seleccionada protegerá los servicios contra futuras interrupciones del servicio debido a cambios de CA 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 CA debo confiar? en las Preguntas frecuentes de GTS para obtener más recomendaciones.

¿Por qué no debo instalar ningún certificado de CA 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 CA intermedias. Cualquiera de estas situaciones puede ocurrir en cualquier momento y sin previo aviso, y se aplica de manera equitativa a los certificados de servidor individuales, como los que entrega maps.googleapis.com, así como cualquier otra de nuestras CA intermedias, por ejemplo, Cross Root R1 Cross.

Para proteger tus servicios contra esto, solo debes instalar los certificados raíz del paquete de CA 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 certificadora 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 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 reciben actualizaciones regulares de su fabricante sigan funcionando sin problemas en el futuro. La mayoría de los modelos de teléfonos Android más antiguos incluyen, como mínimo, el certificado GlobalSign Root CA - R1, aunque la lista de certificados de confianza puede variar según el fabricante del teléfono celular, el modelo del dispositivo y la versión de Android.

Sin embargo, es posible que la compatibilidad con las CA 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 CA 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 GlobalSign Root CA - R1.

Las CA 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 el Sistema operativo Chrome; a los programadores de navegadores, como Mozilla, Apple, Microsoft, pero también al equipo de Chrome dentro de Google, y a los fabricantes de hardware, como teléfonos, decodificadores, TV, impresoras y consolas de juegos, entre otros.

Por lo tanto, es muy probable que cualquier sistema mantenido en la actualidad ya sea compatible con las nuevas CA raíz de GTS de Google, incluida GTS Root R1 y, también que, incluso, los sistemas heredados admitan GlobalSign Root CA - R1, la cual se usará para firmar de forma cruzada los certificados emitidos por Google durante los próximos años.

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 CA 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. Puedes encontrar una lista de objetos binarios compilados por terceros en https://www.openssl.org/community/binaries.html. 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, tshark y tcpdump para su herramienta de línea de comandos, las versiones ya compiladas de las dos primeras para otros SO se pueden encontrar 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 los certificados raíz, a menos que tu aplicación se compile mediante 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 CA 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.r1demo.pki.goog/; \
    openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.r1xdemo.pki.goog/; \
    openssl s_client -connect good.r1xdemo.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, utilizando una longitud de instantánea lo suficientemente grande para capturar 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 la bandera -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 la bandera -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 mediante la bandera --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.r1xdemo.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.r1xdemo.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 mediante 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 ininterrumpidos 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 CA agregadas por el usuario, instaladas mediante 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 CA raíz de confianza para las versiones 5 y posteriores de iOS. Eso 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 del 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, mediante 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 Mozilla NSS

Es posible que las aplicaciones que usanMozilla NSS también usen de forma predeterminada una base de datos de certificados de todo el sistema, la cual se suele encontrar en /etc/pki/nssdb o un almacén predeterminado específico del usuario en ${HOME}/.pki/nssdb. Para actualizar el NSS, consulta la documentación de la herramienta certutil a fin de ver cómo agregar certificados nuevos. Asimismo, puedes consultar la documentación oficial del SO.

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:

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, se suele encontrar en /etc/pki/java/cacerts o /usr/share/ca-certificates-java. Consulta la siguiente documentación de Stack Overflow y Oracle para obtener ayuda sobre cómo actualizar tu almacén de certificados de Java con la herramienta de línea de comandos de Oracle keytool:

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 lenguaje natural, 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 de lenguaje natural. 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 los certificados de codificación. 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 solo aceptan la importación de archivos PEM que contienen un único certificado. 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 emitir el siguiente comando para exportar tu certificado de Java Key Store correspondiente a un alias determinado al formato PEM:

keytool -exportcert -rfc -keystore certs.jks -storepass password -alias server &gt; server.pem

Solo reemplaza las variables -keystore, -storepass y -alias anteriores por los valores correctos que correspondan a tu entorno.

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

Consulta la documentación de la herramienta certutil de Mozilla NSS, así como el debate en el sitio de la comunidad Red Hat sobre lo que se debe hacer para exportar el certificado de cert8.db como un archivo .pem.

Cómo imprimir certificados PEM en un formato de lenguaje natural

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 en lenguaje natural sobre la autoridad certificadora relacionada (ejemplo del paquete de CA 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é CA pertenece el certificado. También se garantiza que la string del certificado entre los tokens -----BEGIN CERTIFICATE----- y -----END CERTIFICATE----- sea única para cada CA.

Sin embargo, aunque no cuentes con las herramientas anteriores, ya que cada certificado del paquete de CA raíz de confianza de Google está bien etiquetado, puedes hacer coincidir de manera confiable las CA raíz del paquete con las de tu almacén de certificados raíz mediante Issuer o comparando strings del certificado 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 CA 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.

A fin de 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 el siguiente material sobre OWASP (Open Web Application Security Project), un proyecto abierto de seguridad de aplicaciones web: 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). 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 resultarte ú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, y 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 en Android.

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