Cuándo instalar keystore & cuándo instalar sólo el certificado envuelto en keystore

Tengo un archivo PKCS # 12 que consideré como un archivo de almacén de claves ya que contiene una entrada de clave y una entrada de certificado .

En Android, veo que la gente instala programaticamente keystore de la siguiente manera (El código es de Android developer blog ):

byte[] keystore = . . (read from a PKCS#12 keystore) Intent installIntent = KeyChain.createInstallIntent(); installIntent.putExtra(KeyChain.EXTRA_PKCS12, keystore); startActivityForResult(installIntent, INSTALL_KEYSTORE_CODE); 

También veo que la gente instala programaticamente sólo el certificado envuelto dentro de keystore:

 Intent intent = KeyChain.createInstallIntent(); intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert); startActivity(intent); 

Además, también veo que la gente instala el keystore y el certificado envuelto en keystore . Por ejemplo, este artículo nos muestra cómo instalar primero keystore y luego instalar el certificado envuelto en keystore mediante programación.

Realmente me confundo acerca de cuándo debo instalar el almacén de claves solo y cuándo debo instalar el certificado (envuelto dentro del almacén de claves) solamente? ¿Y cuándo debo instalar ambos? ¿Podría alguien aclararme sobre esto por favor?

Por ejemplo, mi archivo PKCS # 12 de keystore (mycert.p12) contiene el par clave / certificado, se utiliza para conectarse al servidor VPN. ¿Cuándo debería instalar mi cliente android tanto el almacén de claves como el certificado envueltos en el almacén de claves? ¿Cuándo debe el cliente instalar sólo el certificado envuelto en keystore? Cuáles son las diferencias ? Estoy bastante confundido sobre esto.

Tengo un archivo PKCS # 12 que consideré como un archivo de almacén de claves ya que contiene una entrada de clave y una entrada de certificado.

Correcto.

En Android, veo que la gente instala programaticamente keystore de la siguiente manera …

Esto se hace cuando tiene un almacén de claves, es decir, un par de claves y un certificado.

También veo a las personas instalar mediante programación sólo el certificado envuelto dentro de keystore

Esto se hace cuando se tiene el certificado de otra persona , normalmente uno autofirmado, que no es de confianza por ninguna de las CA (autoridades de certificación) predeterminadas que ya están instaladas. Usted nunca debe tener que hacer esto.

Por lo tanto, tenga en cuenta que nunca hacer ambos con el mismo certificado, porque los casos (los propietarios) son diferentes. Nunca puede haber duda sobre qué proceso es apropiado. Si es tuyo, importa el keystore. Si es de otra persona, importe el certificado.

La referencia normativa definitiva para todo esto es la Recomendación X.509 de la UIT .

Por último, algunas notas sobre los artículos de mala calidad blog que han vinculado.

Desde unificar el acceso al almacén de claves en ICS :

En el pasado, era una práctica común para las aplicaciones mantener su propia tienda de claves si necesitaban autenticar un servidor web SSL seguro o autenticar al usuario a un servidor a través de un certificado de cliente.

Esto ya es incorrecto.

  1. Para autenticar un servidor web, no necesitará nada, si tiene un certificado firmado por CA. Si tiene un certificado autofirmado, necesitará importarlo en su truststore .

  2. Para autenticarse en un servidor web, necesita una almacén de claves que contenga su propia clave privada y un certificado, preferiblemente uno firmado por CA. De lo contrario, el servidor tiene que importar su certificado autofirmado en su truststore, es decir, el inverso de (1) anterior. No vaya por este camino. Certificados auto-firmados son mucho más problemas de lo que vale la pena, que no es nada, como se puede decir por el precio que usted paga por ellos.

Desde el uso del llavero ICS API :

Primero obtenemos la clave privada y la cadena de certificados usando el alias clave y luego creamos y verificamos una firma para comprobar si la clave es realmente utilizable.

Sin sentido completo. Ya tenemos la clave privada, la clave pública y el certificado. Ya son utilizables. Crear una firma y verificarla localmente es simplemente una completa pérdida de tiempo.

La instalación de un certificado de CA no es muy diferente de la instalación de un archivo PKCS # 12: se carga el certificado en una matriz de bytes y se pasa como un complemento a la intención de instalación.

La diferencia es que utiliza KeyChain.EXTRA_CERTIFICATE en el caso del certificado de CA y KeyChain.EXTRA_PKCS12 en el caso del almacén de claves.

Puesto que nadie te ha contestado aún, espero que al menos pueda aclarar algunos puntos del artículo de blog que has vinculado.

En el pasado, era una práctica común para las aplicaciones mantener su propia tienda de claves si necesitaban autenticar un servidor web SSL seguro o autenticar al usuario a un servidor a través de un certificado de cliente.

Estos son los dos casos de uso básicos aquí:

  • Si está autenticando con un certificado de cliente (lo que demuestra al servidor que usted es un cliente autorizado), entonces sólo instalaría un certificado.
  • Si está intentando verificar la identidad del servidor, deberá validar el certificado del servidor. En este caso necesitará un almacén de claves instalado (posiblemente una cadena si no está usando certs autofirmados). La clave privada en el almacén de claves se utilizará para validar el certificado del servidor.

Ese segundo bit de código que tiene en su pregunta fue pensado para crear una cadena de certificados (cuando NO está usando certificados auto-firmados):

Primero obtenemos la clave privada y la cadena de certificados usando el alias clave y luego creamos y verificamos una firma para comprobar si la clave es realmente utilizable. Dado que estamos utilizando un certificado autofirmado, la 'cadena' consta de una sola entrada, pero para un certificado firmado por una entidad emisora ​​de certificados necesitará encontrar el certificado de entidad final real en la matriz devuelta.

La instalación de un certificado de CA no es muy diferente de la instalación de un archivo PKCS # 12: se carga el certificado en una matriz de bytes y se pasa como un complemento a la intención de instalación.

 Intent intent = KeyChain.createInstallIntent(); intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert); startActivity(intent); 

Espero que esta explicación ayuda! 🙂

Con respecto a un androide o cualquier otro "cliente", es decir, una aplicación,

Un truststore (clave pública solamente) se requiere siempre que necesite validar el certificado (o una cadena del certificado) que es enviado a través por el servidor durante la comunicación del SSL (en caso de la comunicación del ssl el servidor presentará siempre su certificado al cliente).

Si el certificado del servidor ya está firmado por una autoridad de certificados de confianza (lo que implica que el certificado ya está presente en el java-runtime-truststore que normalmente se puede encontrar en $JAVA_HOME/jre/lib/security/cacerts ), este paso no es necesario. A menos que se esté usando un SSLContext personalizado (lo que también significa que se está utilizando un TrustManager personalizado).

Por ejemplo, el certificado actual de SO está firmado por DigiCert identificado por SHA1-Thumbprint: 5F: B7: EE: 06: 33: E2: 59: DB: AD: 0C: 4C: 9A: E6: D3: 8F: 1A: 61: C7 : DC: 25 y probablemente estarían presentes en el almacén de confianza 'cacerts' bajo el alias 'digicerthighassuranceevrootca'. Si un cliente java debía hacer una solicitud a https://stackoverflow.com entonces por defecto no habría ningún almacén de claves específico o truststore requerido para la comunicación.

Generalmente se requiere un almacén de claves (clave privada y pública) cuando se requiere que el cliente firme digitalmente algunos datos que se están publicando en el servidor. Un ejemplo común es la firma xml, puede encontrar una mención aquí

También se requiere si el servidor espera que el cliente presente su propio certificado para la autenticación como parte del apretón de manos de ssl bidireccional. Por lo que he encontrado esto no es común.

Enlaces:

SSL de dos vías

El propio Keystore de SO y la publicación de truststore

  • Acceso web automático de Webview de Android al sitio Web de https estableciendo cookies de token
  • ¿Cómo resolver el problema "ingrese la contraseña para el almacenamiento de credenciales"?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.