validar - Verificar una cadena de certificados usando openssl verificar

openssl ver csr

Question

Estoy construyendo una cadena de certificados propia con los siguientes componentes:
Root Certificate - Intermediate Certificate - User Certificate
Root Cert es un certificado autofirmado, el Certificado Intermedio está firmado por Root y el Usuario por Intermedio.

Ahora quiero verificar si un certificado de usuario tiene su ancla mediante el certificado raíz.

Con
openssl verify -verbose -CAfile RootCert.pem Intermediate.pem
la validación está bien En el siguiente paso valido el certificado de usuario con
openssl verify -verbose -CAfile Intermediate.pem UserCert.pem
y la validación muestra el error 20 en la búsqueda en profundidad 0: no se puede obtener el certificado del emisor local

¿Qué está mal?

Answer 1

De la documentación de "verificar": "Si se encuentra un certificado que es su propio emisor, se asume que es la CA raíz". En otras palabras, la CA raíz debe autofirmarse para que la verificación funcione. Por eso tu segundo comando no funcionó.

Intenta esto en su lugar:

openssl verify -CAfile RootCert.pem -untrusted Intermediate.pem UserCert.pem

Verificará toda su cadena en un solo comando.

Answer 2

Después de terminar un día entero en el mismo problema, sin conocimiento previo sobre los certificados SSL, descargué el Administrador de almacenes de claves de CERTivity e importé mi almacén de claves, y obtuve una visualización clara de la cadena de certificados.

Captura de pantalla :

Answer 3

El problema es que openssl -verify no hace el trabajo.

Como mencionó Priyadi , openssl -verify detiene en el primer certificado autofirmado, por lo que no verifica realmente la cadena, ya que a menudo el certificado intermedio es autofirmado.

Supongo que quiere estar seguro al 101% de que los archivos de certificado son correctos antes de intentar instalarlos en el servicio web productivo. Esta receta aquí realiza exactamente este control previo al vuelo.

Tenga en cuenta que la respuesta de Peter es correcta , sin embargo, la salida de openssl -verify no es una pista de que todo funcione realmente después. Sí, puede encontrar algunos problemas, pero no todos.

Aquí hay un script que hace el trabajo de verificar una cadena de certificados antes de instalarlo en Apache. Tal vez esto pueda mejorarse con algunas de las más místicas de OpenSSL magic, pero no soy un gurú de OpenSSL y estoy trabajando a continuación:

#!/bin/bash
# This Works is placed under the terms of the Copyright Less License,
# see file COPYRIGHT.CLL.  USE AT OWN RISK, ABSOLUTELY NO WARRANTY. 
#
# COPYRIGHT.CLL can be found at http://permalink.de/tino/cll
# (CLL is CC0 as long as not covered by any Copyright)

OOPS() { echo "OOPS: $*" >&2; exit 23; }

PID=
kick() { [ -n "$PID" ] && kill "$PID" && sleep .2; PID=; }
trap ''kick'' 0

serve()
{
kick
PID=
openssl s_server -key "$KEY" -cert "$CRT" "$@" -www &
PID=$!
sleep .5    # give it time to startup
}

check()
{
while read -r line
do
    case "$line" in
    ''Verify return code: 0 (ok)'')   return 0;;
    ''Verify return code: ''*)    return 1;;
#   *)  echo "::: $line :::";;
    esac
done < <(echo | openssl s_client -verify 8 -CApath /etc/ssl/certs/)
OOPS "Something failed, verification output not found!"
return 2
}

ARG="${1%.}"
KEY="$ARG.key"
CRT="$ARG.crt"
BND="$ARG.bundle"

for a in "$KEY" "$CRT" "$BND"
do
    [ -s "$a" ] || OOPS "missing $a"
done

serve
check && echo "!!! =========> CA-Bundle is not needed! <========"
echo
serve -CAfile "$BND"
check
ret=$?
kick

echo
case $ret in
0)  echo "EVERYTHING OK"
    echo "SSLCertificateKeyFile $KEY"
    echo "SSLCertificateFile    $CRT"
    echo "SSLCACertificateFile  $BND"
    ;;
*)  echo "!!! =========> something is wrong, verification failed! <======== ($ret)";;
esac

exit $ret

Tenga en cuenta que la salida después de EVERYTHING OK es la configuración de Apache, porque las personas que usan NginX o haproxy generalmente también pueden leer y entender esto perfectamente;)

Hay un GitHub Gist de esto que podría tener algunas actualizaciones.

Prerrequisitos de este script:

• Tiene los datos de raíz de CA confiables en /etc/ssl/certs como de costumbre, por ejemplo, en Ubuntu
• Cree un directorio DIR donde almacene 3 archivos:
  • DIR/certificate.crt que contiene el certificado
  • DIR/certificate.key que contiene la clave secreta para su servicio web (sin frase de contraseña)
  • DIR/certificate.bundle que contiene el paquete de CA. Sobre cómo preparar el paquete, ver más abajo.
• Ahora ejecute el script: ./check DIR/certificate (esto supone que el script se llama check en el directorio actual)
• Existe un caso muy improbable de que el script produzca CA-Bundle is not needed . Esto significa que usted (lea: /etc/ssl/certs/ ) ya confía en el certificado de firma. Pero esto es altamente improbable en la WWW.
• Para esta prueba, el puerto 4433 no debe ser utilizado en su estación de trabajo. Y mejor solo ejecútelo en un entorno seguro, ya que abre el puerto 4433 en breve al público, lo que podría ver conexiones externas en un entorno hostil.

¿Cómo crear el archivo certificate.bundle ?

En la WWW la cadena de confianza usualmente se ve así:

• certificado de confianza de /etc/ssl/certs
• certificado (s) intermedio desconocido (s), posiblemente firmado por otra CA
• su certificado ( certificate.crt )

Ahora, la evaluación se lleva a cabo de abajo hacia arriba, esto significa, primero, se lee su certificado, luego se necesita el certificado intermedio desconocido, luego tal vez el certificado de firma cruzada y luego /etc/ssl/certs se consulta para encontrar el certificado de confianza adecuado.

El paquete de ca se debe componer exactamente en el orden de procesamiento correcto, esto significa, el primer certificado necesario (el certificado intermedio que firma su certificado) aparece primero en el paquete. Entonces se necesita el certificado de firma cruzada.

Por lo general, su CA (la autoridad que firmó su certificado) proporcionará ya un archivo de paquete de CA adecuado. De lo contrario, debe seleccionar todos los certificados intermedios necesarios y agruparlos en un solo archivo (en Unix). En Windows, solo puede abrir un editor de texto (como notepad.exe ) y pegar los certificados en el archivo, el primero necesario en la parte superior y luego los demás.

Hay otra cosa. Los archivos deben estar en formato PEM. Algunas CAs emiten el formato DER (un binario). PEM es fácil de detectar: ​​es ASCII legible. Para obtener más información sobre cómo convertir algo en PEM, consulte Cómo convertir .crt a .pem y siga el camino de ladrillos amarillos.

Ejemplo:

Tienes:

• intermediate2.crt el certificate.crt intermedio que firmó su certificate.crt
• intermediate1.crt otro certificado intermedio, el cual chocó intermediate2.crt
• crossigned.crt que es un certificado de firma cruzada de otra CA, que firmó intermediate1.crt
• crossintermediate.crt que es otro intermediario de la otra CA que firmó crossigned.crt (probablemente nunca verás tal cosa)

Entonces el cat apropiado se vería así:

cat intermediate2.crt intermediate1.crt crossigned.crt crossintermediate.crt > certificate.bundle

¿Y cómo puede saber qué archivos se necesitan o no y en qué secuencia?

Bueno, experimenta, hasta que el check te diga que todo está bien. Es como un juego de rompecabezas de computadora para resolver el enigma. Cada. Soltero. Hora. Incluso para profesionales. Pero mejorará cada vez que necesite hacer esto. Así que definitivamente no estás solo con todo ese dolor. Es SSL, ¿sabes? SSL es probablemente uno de los peores diseños que he visto en más de 30 años de administración profesional de sistemas. ¿Alguna vez te has preguntado por qué crypto no se ha convertido en algo común en los últimos 30 años? Es por eso. ''nuff dijo.

Answer 4

Ese es uno de los pocos trabajos legítimos para el cat :

openssl verify -verbose -CAfile <(cat Intermediate.pem RootCert.pem) UserCert.pem

Actualizar:

Como Greg Smethells señala en los comentarios, este comando confía implícitamente en Intermediate.pem . Recomiendo leer la primera parte de mail.python.org/pipermail/cryptography-dev/2016-August/… (la segunda parte trata específicamente sobre pyOpenSSL y no es relevante para esta pregunta).

En caso de que la publicación se vaya, citaré los párrafos importantes:

Desafortunadamente, un certificado "intermedio" que es en realidad una raíz / autofirmado se tratará como una CA confiable cuando se usa el comando recomendado que se mencionó anteriormente:

$ openssl verificar -CAfile <(cat geotrust_global_ca.pem rogue_ca.pem) fake_sometechcompany_from_rogue_ca.com.pem fake_sometechcompany_from_rogue_ca.com.pem: OK

Parece que openssl dejará de verificar la cadena tan pronto como se encuentre un certificado raíz, que también puede ser Intermediate.pem si es autofirmado. En ese caso RootCert.pem no es considerado. Así que asegúrese de que Intermediate.pem provenga de una fuente confiable antes de confiar en el comando anterior.

Answer 5

Puede verificar fácilmente una cadena de certificados con openssl. La cadena completa incluirá el certificado CA, por lo que debería ver los detalles sobre la CA y el certificado en sí.

openssl x509 -in fullchain.pem -text -noout

Answer 6

Tuve que hacer una verificación de un certificado de letsencrypt y lo hice así:

1. Descargue el certificado raíz y el certificado intermedio de la cadena de confianza de letsencrypt: https://letsencrypt.org/certificates/
2. ejecute este comando:

openssl verify -CAfile letsencrypt-root-cert/isrgrootx1.pem.txt -untrusted letsencrypt-intermediate-cert/letsencryptauthorityx3.pem.txt /etc/letsencrypt/live/sitename.tld/cert.pem /etc/letsencrypt/live/sitename.tld/cert.pem: OK

Espero que te ayude para tus certificados de letencrypt. Gracias por Priyadi, su solución me ayudó a encontrar este comando. Palease asegúrate de aumentar su solución.