¿Debería un servidor o un cliente poder verificar un certificado de cliente / servidor - cadena de certificados intermedios con una raíz conocida ca?

Navega tus respuestas
1

Estoy intentando probar la siguiente configuración:

Un servidor RADIUS funciona con el protocolo EAP-TLS. El cliente y el servidor tienen los siguientes certificados:

Cliente
Clave pública: clientcert_intermediatecert_chain.pem
Certificado CA: rootcert.pem

Servidor
Clave pública: servercert_intermediatecert_chain.pem
Certificado CA: rootcert.pem

Tanto el certificado del cliente ( clientcert.pem ) como el certificado del servidor ( servercert.pem ) están firmados por el mismo certificado intermedio ( intermediatecert.pem ), que está firmado por el certificado raíz ( rootcert.pem ).
Ambas cadenas, que están configuradas para ser las claves públicas, se juntan así (mediante el comando de Shell):
cat servercert.pem intermediatecert.pem > servercert_intermediatecert_chain.pem
cat clientcert.pem intermediatecert.pem > clientcert_intermediatecert_chain.pem

Ahora, el cliente intenta conectarse al servidor. Ambas partes envían sus claves públicas e intentan verificar las claves públicas recibidas con rootcert.pem

Sé que la forma "normal" sería, que la clave pública era solo el certificado del servidor o del cliente. Y el certificado CA sería la cadena imcert-rootcert, pero tengo que saber si esto también funcionará.

Ahora mis preguntas:

  1. ¿Es legítimo que la clave pública sea una cadena que consiste en el certificado del servidor / cliente y el certificado intermedio?
  2. Y si es así, ¿esto se aplica a ambos lados (servidor y cliente)?
  3. ¿Debería un servidor (como FreeRADIUS) o un cliente poder verificar cadenas como éstas con el certificado raíz, si las reciben de la parte del contador?

Según mi experiencia, FreeRADIUS no verifica el derecho de tal cadena de certificados. Si no me equivoco, FreeRADIUS usa la biblioteca OpenSSL y hace lo mismo que el siguiente comando en la situación que se muestra arriba:

openssl verify -CAfile rootcert.pem clientcert_intermediatecert_chain.pem

Y estoy bastante seguro de que esto no funciona. OpenSSL no puede verificar una cadena como esta con el certificado raíz. Falla cuando se trata de unir la cadena de confianza.
¿Esto es correcto?

Por cierto, FreeRADIUS devuelve el mismo error que el comando de verificación: error 20 at 0 depth: cannot find issuer certificate , lo que significa que no puede unir la cadena de confianza.

    
pregunta Jannis Kappertz 07.07.2017 - 09:58
fuente

2 respuestas

1

No es una respuesta completa (¿todavía?), pero:

Sí, la biblioteca OpenSSL llamada (directamente o como aquí a través de libssl) por un programa como FreeRADIUS puede verificar una cadena recibida; no, su línea de comando openssl verify no verifica una cadena. Esto se trata en enlace (mío), pero eso es downvoted y sugirió offtopic, así que copiaré la parte relevante aquí:

openssl línea de comando verify lee solo un certificado , el primero, del archivo dado como operando, o de cada archivo si se da más de uno. Esto difiere de los archivos especificados con las opciones -CAfile -trusted -untrusted que pueden (y típicamente contienen) certificados múltiples.

Su archivo clientcert_intermediatecert_chain.pem contiene el certificado de cliente y el certificado intermedio en ese orden. Solo se utiliza el certificado de cliente, se ignora el certificado intermedio y, como resultado, no tiene una cadena válida para verificar.

Para usar la línea de comando para simular / probar la validación realizada por un receptor (para una cadena de certificados de cliente, el servidor) suministra el certificado de hoja como el operando y todos los demás certificados (cadena) transmitidos (aquí el intermediario) con -untrusted y el (los) ancla (es) más cualquier intermediario 'conocido' en el almacén de confianza, ya sea explícito o predeterminado (su -CAfile root está bien, aunque hay otras formas válidas).

En cuanto al problema real (Y) con FreeRADIUS: ¿Está seguro de que el cliente está enviando la cadena? ¿Tienes algún rastro?

Como alternativa: si el cliente (o, en general, un par) no envía los certificados de cadena necesarios, pero están en el almacén de confianza local, lo que podría decirse que es algo espúreo, OpenSSL < em> will usará esos. Puede intentar agregar al menos temporalmente el certificado intermedio al archivo que usa para CA_file o al directorio hashnamed que usa para CA_path .

    
respondido por el dave_thompson_085 08.07.2017 - 07:46
fuente
0

Parece que el problema de mi configuración fue que el cliente no envió la cadena intermedia completa del cliente, sino solo el certificado del cliente (lo descubrí usando Wireshark). Al revés, el servidor de radio que envía una cadena intermedia de servidor funciona bien.

Entonces, para responder a mi pregunta: Sí, esta configuración debería funcionar, en ambas direcciones.

    
respondido por el Jannis Kappertz 02.08.2017 - 11:58
fuente

Lea otras preguntas en las etiquetas

¿Existe un riesgo en los datos privados del usuario cuando la aplicación de Android tiene permiso para acceder al hardware sin acceder a los datos del usuario? ¿Es posible realizar un ataque XSS en el título / subtítulo de una página web?