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

Información general

Solución de problemas

Cómo administrar tus certificados de confianza

Apéndice

Información general

¿Qué sucede?

Panorama general

Google está trabajando en un plan de varios años para emitir y utilizar sus propios certificados raíz, las firmas criptográficas que constituyen la base de los protocolos TLS/SSL de seguridad en Internet utilizados por HTTPS.

Actualmente, la seguridad TLS de Google Maps Platform está garantizada por un certificado raíz emitido por GeoTrust Global CA, una autoridad certificadora (CA) reconocida y muy confiable, que pertenece a Symantec. Prácticamente todos los clientes TLS (como los navegadores web, los smartphones y los servidores de aplicaciones) conocen este certificado raíz y, por lo tanto, pueden usarlo para garantizar una conexión segura con los servidores de Google Maps Platform.

A principios de 2020, Google planea migrar todos los servicios de Google Maps Platform a un certificado raíz emitido por la autoridad certificadora propia de Google, Google Trust Services (GTS).

Como paso provisional, a principios de 2018, Google Maps Platform migró a otro certificado raíz muy confiable emitido por GlobalSign (GS). Google compró el uso de este certificado raíz (y la CA que GlobalSign utilizaba para emitirlo) a fin de facilitar la transición del certificado.

La gran mayoría de los clientes de TLS ya reconocen el certificado raíz de GlobalSign, por lo que su uso de Google Maps Platform no se verá afectado por este cambio inicial.

Sin embargo, hay algunos casos de uso especiales, como los dispositivos incorporados o los usuarios que trabajan con sistemas operativos o navegadores heredados demasiado obsoletos, en los que es posible que algunos clientes no cuenten con el certificado raíz de GlobalSign. Estos clientes deberán actualizar su certificado para asegurar sus conexiones con Google Maps Platform. Google no puede identificar a estos clientes, por lo que los propietarios de las aplicaciones deben realizar la verificación necesaria en sus propias aplicaciones. Google Trust Services proporciona extremos de prueba HTTPS en el sitio de GTS para ayudar con esta tarea. Consulta la información que se brinda a continuación para obtener más detalles técnicos.

Es probable que esto mismo suceda con la mayoría de los sistemas cuando comience la migración a certificados raíz de GTS. No obstante, seguir las recomendaciones que se brindan en este documento debería garantizar, en líneas generales, una migración sin problemas, incluso en los casos especiales.

Resumen técnico

Tal como se anunció en el portal de asistencia al cliente del plan Premium de Google Maps Platform el 16 de marzo de 2017, y antes en el Blog de seguridad de Google, Google creó su propia CA raíz, GTS.. Junto con otros servicios de Google, Google Maps Platform hará una transición gradual a los certificados TLS firmados por las CA raíz de GTS.

Como paso provisional, Google compró una CA ya existente, de gran confianza: GS Root R2. A fines de 2017, Google Maps Platform comenzó a migrar del certificado raíz de GeoTrust a este certificado y finalizó la migración a principios de 2018.

Casi todos los clientes de TLS están preconfigurados con el certificado GS Root R2 o lo reciben a través de actualizaciones de software normales. Si una aplicación se conecta a Google Maps Platform desde clientes que no reconocen este certificado, los desarrolladores de aplicaciones deberían asegurarse de que los clientes se prueben y, si es necesario, reciban el certificado actualizado.

El certificado GS Root R2 y todos los certificados raíz de GTS están disponibles en el sitio de GTS. Para fines de prueba, el sitio GTS también proporciona extremos con certificados TLS firmados por cada CA. En particular, si tu cliente puede establecer una conexión TLS con el extremo de prueba de GS Root R2, significa que confía en el certificado GS Root R2 y no debería verse afectado por el cambio próximo.

Google confiará en la CA GS Root R2, como mínimo, hasta fines de 2018. Después de eso, Google Maps Platform podría realizar una transición directa a la CA de GTS o, en ocasiones, recurrir a CA raíz pertenecientes a terceros, incluida la CA GS Root R3.

¿Cómo obtengo actualizaciones sobre este proceso de migración?

Destaca con una estrella el problema público 67842936 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.

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 tu aplicación confía en el conjunto recomendado de certificados raíz enumerados en el archivo PEM de muestra de Google, tu aplicación debería estar lista para seguir funcionando sin problemas durante la migración de certificado raíz, independientemente del servicio o la API de Google a los que llame. Consulta la pregunta ¿Debo instalar todos los certificados raíz del archivo PEM de muestra de Google? para obtener más detalles.

¿Cómo verifico si mi almacén de certificados necesita una actualización?

Prueba el entorno de tu aplicación con los extremos de prueba enumerados junto con cada una de las CA raíz en el sitio de GTS. Si puedes establecer una conexión TLS con el extremo de prueba de GS Root R2 y la zona de pruebas para certificados de Google, tu aplicación funcionará bien, al menos hasta finales de 2018.

Por lo tanto, te recomendamos que instales ahora todos los certificados del archivo PEM de muestra de Google a fin de que tu sistema esté preparado para seguir vigente en el futuro, a menos que estés seguro de que siempre te ocuparás de que tu entorno de producción tenga todas las actualizaciones y parches necesarios.

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

La herramienta de línea de comandos curl, disponible en la mayoría de las plataformas, ofrece una gran variedad de opciones para probar tu configuración. Para ver instrucciones sobre cómo obtener curl, consulta la sección Cómo obtener curl.

Cómo probar tu almacén de certificados predeterminado
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
Cómo verificar el paquete de CA raíz de Google
Descarga el archivo PEM de muestra de Google y, luego, sigue los pasos que se indican a continuación:
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

¿Cómo será el proceso de migración?

¿Cuándo se realizará la migración?

La primera fase de migración (el paso a certificados emitidos por CA intermedias basados en GS Root R2, comenzó a finales de 2017 y concluyó en la primera mitad de 2018.

Los programas respecto de las fases de migración posteriores se anunciarán en los próximos años, pero con anticipación suficiente al vencimiento del certificado de GS Root R2 2021.

Plan de lanzamiento general para cada servicio de Google

  • El lanzamiento en etapas comienza en un solo centro de datos.
  • Se implementa gradualmente en más centros de datos hasta lograr una cobertura global.
  • Si se detectan problemas graves en cualquier etapa, las pruebas pueden revertirse de forma temporal mientras se abordan los problemas.
  • 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 migraron 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 que sus sistemas 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.

¿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?

Consulta la sección ¿Cuáles son los requisitos mínimos recomendados para que un cliente de seguridad de la capa de transporte (TLS) se comunique con Google? en las Preguntas frecuentes de GTS.

Google Maps Platform no impone ningún requisito adicional.

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

La aplicación usa el almacén de certificados del sistema sin restricciones impuestas por los desarrolladores.

Aplicaciones para servicios web de Google Maps Platform

Si usas un SO común, p. ej., Ubuntu, Red Hat, Windows (versión 7 o posteriores) o Server (versión 8 o posteriores), OS X) que aún tiene mantenimiento y recibe actualizaciones con regularidad, tu almacén de certificados predeterminado ya debería incluir el certificado GS Root R2.

Si usas una versión de SO heredada que ya no recibe actualizaciones, puede o no que tengas el certificado GS Root R2. Por ejemplo, Windows XP SP2 incluye el certificado, pero Windows XP SP1 no. Los dispositivos heredados deben probarse para garantizar que confíen en el certificado.

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 Google 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 la API de Google Maps JavaScript ¿corren el riesgo de fallar? para obtener más información.

En las aplicaciones nativas para dispositivos móviles, tanto en Android como en iOS, que utilizan los SDK de Google Maps o de Places, 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 aplicación 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. Tal como se explica en la pregunta ¿Debo instalar todos los certificados raíz del archivo PEM de muestra de Google?, te recomendamos que importes todos los certificados raíz del archivo PEM de muestra de Google a tu almacén de certificados.

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?

¿Debo instalar todos los certificados raíz del archivo PEM de muestra de Google?

Si deseas dejar tu sistema preparado ahora, de una vez, para que siga funcionando sin problemas en el futuro, te recomendamos instalar todos los certificados del archivo PEM de muestra de Google. Esta recomendación es especialmente válida si no acostumbras aplicar de forma regular y rutinaria las actualizaciones que necesite tu sistema operativo o, por ejemplo, si mantienes tus propios conjuntos de certificados para tu aplicación.

¿Por qué no debería instalar certificados de CA intermedios?

Solo debes instalar los certificados raíz del archivo PEM de muestra de Google y depender del certificado raíz para verificar la autenticidad de toda la cadena de certificados que se basan en él. Esto se aplica también a los certificados de servidores individuales (p. ej., los proporcionados por el host maps.googleapis.com) y cualquiera de nuestras CA intermedias (p. ej., GIAG3, GTS CA 1O1 o GIAG4).

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 la API de Google Maps JavaScript ¿corren el riesgo de fallar?

La CA raíz GlobalSign R2 está bien incorporada y confían en ella la mayoría de los navegadores actualizados. Por lo tanto, es probable que estos navegadores puedan seguir conectándose a los servicios de Google durante un tiempo. Si se realiza un mantenimiento activo del navegador, es casi seguro que en algún momento también admitirá todas las demás CA raíz de Google.

Sin embargo, solo se garantiza que la API de Google Maps JavaScript funciona en los navegadores compatibles. Por eso, te recomendamos usar uno de los navegadores mencionados y mantenerlo actualizado a fin de garantizar que no tendrás problemas de uso.

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

También se espera que los dispositivos Android y Apple 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 ya incluyen al menos los certificados GS Root R2 y GS Root R3, aunque la lista de certificados de confianza puede variar según el fabricante y el modelo del dispositivo y la versión de Android que utilice. Las versiones más nuevas del Proyecto de código abierto de Android (AOSP) usadas en los dispositivos marca Google Nexus y Pixel también confían en el certificado GS Root R4 de forma predeterminada. La compatibilidad con las CA raíz de GTS es todavía mínima en cualquiera de las versiones de Android publicadas.

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 de iOS y posteriores admiten GS Root R2 y R3, las versiones 7 y posteriores también admiten GS Root R4. Al igual que sucede con las versiones actuales de Android, iOS todavía no admite las CA raíz de GTS (en la fecha de redacción de este contenido).

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?

Google está trabajando 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, consolas de juegos, impresoras, entre otros.

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 y tcpdump

Si bien la mayoría de las distribuciones de Linux ofrecen ambas herramientas, puedes encontrar versiones ya compiladas de wireshark para otros SO en https://www.wireshark.org. Puedes encontrar el código fuente de tcpdump y LibPCAP en https://www.tcpdump.org.

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 mediante Java.

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

Lo más importante que debes hacer es instalar los certificados raíz necesarios mencionados en el archivo PEM de muestra de Google en el almacén de certificados de confianza utilizado por tu aplicación. Sin embargo, puedes encontrar información útil en la sección Cómo administrar tus certificados de confianza.
  1. Trabaja junto con los administradores de tu sistema para actualizar tu almacén de certificados 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.
  5. Destaca con una estrella el problema público 67842936 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 pregunta ¿Cómo verifico si mi almacén de certificados 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:
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/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 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 interpreto correctamente el resultado de curl y garantizo que los resultados sean confiables?

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 certificado raíz utilizados

Ejecutar curl con la bandera -vvI también imprime el almacén de certificados utilizado, pero el resultado exacto puede variar según el sistema, tal como se muestra a continuación.

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/<username>/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 libssh2/1.4.2
> Host: cert-test.sandbox.google.com
> Accept: */*
>
Error en el protocolo de enlace TLS
Las líneas como las que se muestran a continuación 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 siguientes 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:
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
¿Cómo imprimo 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 ... -showcerts, puedes hacer lo siguiente para imprimir el certificado obtenido:
  1. Copia todo el certificado codificado en Base64, incluidos el encabezado y el pie de página:
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. Pega el contenido de tu búfer de copia en la terminal.
  4. Presiona la tecla Intro.
Para obtener ejemplos de entrada y salida, consulta la sección ¿Cómo imprimo certificados PEM en un formato de lenguaje natural? a continuación.

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

Nuevo certificado basado en la CA raíz GlobalSign: R2

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

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 permitió que los usuarios de teléfonos celulares verifiquen la lista de certificados de confianza en Configuración. En la siguiente 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 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 GS Root R2 GS Root R3 GS Root R4 GTS
2.3, 3.2, 4.x, 5.0
5.1, 6.x, 7.x, 8.x, 9
10

Por lo general, no es posible actualizar el almacén de certificados del sistema Android sin una actualización de firmware o sin acceso al dispositivo con derechos de administrador. Sin embargo, es probable que el conjunto actual de certificados raíz de confianza incluidos en la mayoría de las versiones de Android más utilizadas ofrezca un servicio sin interrupciones durante varios años, superior a la vida útil de la mayoría de los dispositivos actualmente 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 Listas de certificados raíz de confianza disponibles en iOS y iOS 5 y iOS 6: Lista de certificados raíz de confianza disponibles.

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 la siguiente 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 GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11, 12.0
12.1.3 y posteriores

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

La ubicación del almacén de certificados 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 (versiones de Debian, Ubuntu, CentOS y RHEL más antiguas), /etc/pki/ca-trust/source/anchors y /usr/share/pki/ca-trust-source (Fedora, CentOS y RHEL más recientes) o /var/lib/ca-certificates (OpenSUSE). Otras rutas de acceso a los certificados pueden ser /etc/ssl/certs (Debian, Ubuntu) o /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.

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 se encuentra en el subdirectorio certs.
$ ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

Si OpenSSL se basa en el almacén de certificados del sistema predeterminado, como en el ejemplo anterior, consulta la sección ¿Dónde se encuentra el almacén de certificados 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.

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 predeterminada 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.

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:

Java

Las aplicaciones de Java pueden usar su propio almacén de certificados, que en los sistemas Linux se suele encontrar en /etc/pki/java/cacerts o /usr/share/ca-certificates-java. Consulta los siguientes artículos 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:

¿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 imprimo 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}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
Esto debería crear una cantidad de archivos PEM individuales similares a los que se muestran a continuación:
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
Los archivos PEM issuer=….pem se pueden importar de forma individual o convertirse en un formato de archivo que tu almacén de certificados acepte.

¿Cómo convierto un archivo PEM a un formato 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 exporto un certificado desde el almacén de certificados 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 de qué manera exportar el certificado de cert8.db como un archivo .pem.

¿Cómo imprimo certificados PEM en un formato de lenguaje natural?

En los ejemplos siguientes, suponemos que tienes el archivo GlobalSign_Root_CA_-_R2.pem con el siguiente contenido:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Cómo imprimir certificados con OpenSSL

Ejecutar el comando
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
debería generar las siguientes líneas antes del certificado:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

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 GlobalSign_Root_CA_-_R2.pem
debería proporcionar el siguiente resultado:
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

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?

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, 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 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 certificada relacionada (ejemplo del archivo PEM de muestra de Google):

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

El archivo también puede contener solo la parte del certificado. En estos casos, el nombre del archivo, como GlobalSign_Root_CA_-_R2.pem, puede describir a qué CA pertenece el certificado. Se garantiza que la string del certificado entre los tokens -----BEGIN CERTIFICATE----- y -----END CERTIFICATE----- sea única para cada CA. Puedes comparar estas strings de manera confiable entre diferentes archivos PEM si no logras identificar las CA de otro modo.

Por lo tanto, puedes comparar cada uno de los certificados del archivo PEM de muestra de Google con los archivos PEM que extrajiste de tu almacén de certificados. Como cada certificado del paquete de CA raíz de Google está debidamente etiquetado, puedes verificar de forma confiable cuáles de los certificados ya están en tu almacén y cuáles aún debes agregar, incluso si los archivos PEM del almacén de certificados no se etiquetaron.

Aar 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 sobre GTS, así como el artículo How to Use X.509 Certificates and SSL For Secure Communications (Cómo usar los certificados X.509 y SSL para comunicaciones seguras).

Para obtener más detalles sobre temas avanzados, como la fijación de certificados, te puede resultar útil el artículo y la hoja de referencia sobre OWASP (Open Web Application Security Project), un proyecto abierto de seguridad de aplicaciones web. 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 JeeroenHD, Android 7 Nougat and certificate authorities (Android 7 Nougat y las autoridades certificadas) 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.