Al crear certificados autofirmados, ¿se supone que CA.crt debe instalarse en la máquina cliente?

La cadena de confianza en sí se puede explicar en términos de la estructura del certificado.

Si comenzamos desde el certificado de su servidor (es decir, el certificado que normalmente usaría para apache):

• su certificado de servidor es generado por una autoridad de certificación, en función de una CSR que proporcione. Ese CSR contiene su clave pública y otra información que la CA puede o no estar interesada en utilizar.
• la CA recibe su CSR y (generalmente) creará un certificado firmado utilizando una CA intermedia. Su certificado tendrá dos claves públicas: una para el asunto (que es la clave pública extraída de su CSR) y otra para la parte emisora, que es el certificado intermedio de la CA.
• la CA » El certificado intermedio es en sí mismo un certificado firmado (con algunas opciones especiales), donde la clave de asunto será la clave pública de la CA intermedia (que es la misma clave pública que se encuentra en la Clave pública del emisor de su certificado de servidor). La clave de firma (o emisión) será el certificado raíz de la CA (alternativamente, será otro intermedio).
• El certificado raíz de la CA es (generalmente) un certificado autofirmado. En la práctica, esto significa que las claves de Emisor y Asunto son la misma clave pública.

Puede ver esto verificando los certificados en la naturaleza, por ejemplo:

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

La cadena de confianza de esta construcción se puede resumir como (estoy comenzando desde el » bottom «- el certificado de Equifax):

• la CA raíz (Equifax) delega las actividades del día a día a una CA intermedia (GeoTrust) y firma un certificado que representa este hecho (es decir, estableciendo CA: TRUE, KeyUsage: keyCertSign). En otras palabras, la CA raíz «confía» en el intermediario para emitir certificados en su nombre (con suerte, después de completar una serie de pasos de validación obligatorios).
• en esta cadena, el intermedio (Geotrust) ha delegado a una CA de Google (CN = Google Internet Authority G2).
• el delegado (también conocido como la CA intermedia de Google) luego firma un CSR, que efectivamente es un documento que indica que para un determinado conjunto de nombres (t El CN, y posiblemente los Nombres alternativos del sujeto), un par de claves privada / pública es válido / confiable (la confianza aquí proviene del hecho de que han validado el reclamo para hablar por un nombre dado; en este caso, la CA de Google ha emitido un certificado para * .google.com).

Tenga en cuenta que las CA (raíz) suelen estar autofirmadas; en general, se confía en una CA porque se rige por un conjunto de procesos y procedimientos que garantizan que no emite certificados a las personas quién no debería tenerlos. Por eso no puedo salir y obtener un certificado que diga que soy Google.Por lo tanto, esta es una especie de convención (aunque respaldada por mecanismos formales), y si inicia su propia CA, la distribución de sus certificados raíz (e intermedios) logra exactamente lo mismo que la distribución de los certificados de otras CA: hace que los certificados se emitan por esa CA sea aceptado como válido (es decir, confiable) por el sistema.

En términos más prácticos, el almacén de confianza (para openSSL) es más o menos un montón de archivos con una convención de nomenclatura específica. Consulte https://www.openssl.org/docs/faq.html#USER5 :

Cuándo un certificado está verificado, su CA raíz debe ser «confiable» por OpenSSL, esto generalmente significa que el certificado de CA debe colocarse en un directorio o archivo y el programa relevante debe configurarse para leerlo

Ese directorio es / etc / ssl / certs (hay otros, como / etc / pki en RH-likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 proporciona una descripción general adicional de cómo se agrega un certificado a la tienda, como does https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

La versión corta es que update-ca -ificates automatiza el proceso y es la herramienta de uso común.

La versión un poco más larga es que los certificados deben almacenarse mediante hash (por ejemplo, en archivos con nombres basados en la salida de openssl x509 -hash -in cert.pem), para que openSSL pueda validar cadenas de manera eficiente.

Consulte https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html para obtener información adicional.

actualizado para responder a las preguntas en los comentarios:

El certificado del servidor , en esta discusión, se define como confiable o no en función de su cadena de confianza. Si piensa en cómo (p. Ej.) curl https://google.com funciona, es un poco más fácil de entender:

• curl abre una conexión TLS a Google, que devuelve un certificado.
• curl mira ese certificado de «usuario final», es decir, el certificado del servidor, y busca específicamente al emisor.
• si el emisor es «conocido» en el almacén de confianza, se valida el resto de la cadena de confianza (es decir, se comprueba el certificado del emisor del certificado del servidor, y si éste tiene un emisor distinto a él mismo, se comprueba ese emisor, etc.). Solo si se puede validar la cadena de confianza total, el certificado se considera válido.

Sin embargo, no sería absolutamente práctico distribuir cadenas de confianza si fuera necesario incluir certificados de usuario final. No tengo cifras sobre cuántos sitios web hay, pero en base al hecho de que Alexa proporciona un 1M superior, supondría que es más de 1 millón.

¿Cuál es el punto de una cadena de confianza: generalmente necesita tener los certificados del emisor cerca, pero no necesita que los certificados finales se distribuyan, porque le dicen quién es el emisor.

Y puede verificar que no lo sean » miente, porque puede verificar la clave pública del emisor (y la cadena de confianza que establece que es la clave adecuada) y validar si el certificado del usuario final (es decir, el servidor) fue realmente firmado por la contraparte privada del emisor «. clave pública.

Así que no, no debe distribuir los certificados de usuario final, sino solo la cadena de confianza o, en términos más simples: distribuir todos los certificados que genere donde las BasicConstraints (legítimamente) dicen algo al menos CA: TRUE. No distribuyas nada que no cumpla con esa condición, porque es una pérdida de tiempo y espacio en disco – todo lo que no diga CA: TRUE se puede validar con algo que sí lo haga.

Comentarios

• Entonces, ¿eso significa que, en cualquier caso, el cliente necesita acceso al certificado de CA raíz, o simplemente al certificado de CA del cual el servidor certificado fue firmado por? ¿O todavía me falta por completo algún punto?
• Para verificar el certificado del servidor, los clientes necesitarían acceso a la cadena de plena confianza para ese certificado. De lo contrario, el cliente considerará que el certificado no es válido o le pedirá al usuario que lo acepte. En su caso, parece algo probable que no esté configurando un punto de distribución para sus CA / CRL, por lo que la forma más sencilla es asegurarse de que sus certificados estén en / etc / ssl / certs en las máquinas cliente. tl; dr: un certificado tiene un uso limitado para establecer confianza si no puede ' establecer su cadena de confianza. Y necesita validar la cadena completa para establecer eso. Así que haga que toda la cadena de confianza esté disponible.
• ¿Eso significa que si hay una CA raíz, una CA intermedia y el certificado firmado en el servidor, los tres certificados deben estar disponibles para el cliente dentro de la /etc/ssl/certs directorio? ¿Como todos estos contienen las claves públicas?