Easy-RSA index.txt, seriales y duplicados

Easy-RSA index.txt, seriales y duplicados

Tenemos más de 700 certificados, generados para el uso de OpenVPN por Easy-RSA 2. No sé cómo sucedió esto (sospechando que alguien lo eliminó una vez index.txt, serialo ambas), pero más de la mitad de los certificados generados tienen números de serie idénticos. Además, el original index.txtcontiene sólo la mitad de todos los certificados (última mitad), sin incluir los anteriores.

Entonces, se pueden hacer nuevos certificados, está bien. Pero cuando intento revocar un certificado que no está en index.txt, aparece un error.

Intenté recrear index.txtmediante script:

    for cert in *.crt
do
  echo "-> $cert"
  enddate=`openssl x509 -enddate -noout -in $cert | sed 's/notAfter=//' | awk '\
    { year=$4-2000;
      months="JanFebMarAprMayJunJulAugSepOctNovDec" ;
      month=1+index(months, $1)/3 ;
      day=$2;
      hour=substr($3,1,2) ;
      minutes=substr($3,4,2);
      seconds=substr($3,7,2);
      printf "%02d%02d%02d%02d%02d%02dZ", year, month, day, hour, minutes, seconds}'`

  serial=`openssl x509 -serial -noout -in  $cert  |sed 's/serial=//'`
  subject=`openssl x509 -subject -noout -in  $cert  |sed 's/subject= //'`

  echo -e "V\t$enddate\t\t$serial\tunknown\t$subject" >>index.txt
done

Lee los certificados uno por uno, obtiene sus datos y completa nuevos index.txt. Todo parece estar bien.

Pero, según el texto superior, el script lo completa mediante certificados, que tienen números de serie iguales. Entonces, con este recién creado index.txtno puedo hacer nada con los certificados (crear, revocar, etc...)

La pregunta es: ¿hay alguna posibilidad de reparar index.txtla base si tengo todos los certificados? O, tal vez, cambiar de alguna manera el número de serie de un certificado (un simple cambio en el encabezado del *.crtarchivo no hace nada; el número de serie permanece antiguo cuando lo consulta openssl)

Si no, solo necesito revocar los certificados que no están en index.txt, ¿puedo hacerlo sin index.txtbase?

Respuesta1

Tenemos más de 700 certificados... más de la mitad de los certificados generados tienen un número de serie idéntico... el index.txt original contiene solo la mitad de todos los certificados (última mitad), sin incluir los anteriores.

Voy a intentar orientarte en la dirección correcta, pero probablemente no pueda llegar hasta el final porque no configuré un equipo de prueba y dupliqué el problema. Mis disculpas de antemano.

Si desea obtener una descripción general de nivel superior sobre la emisión de un certificado en una PKI privada, consulte¿Cómo se firma la Solicitud de firma de certificado con su Autoridad de certificación?Explica cómo haría las cosas manualmente si Easy-RSA no lo hiciera por usted.

Otro documento importante esRFC 4158, Infraestructura de clave pública de Internet X.509: creación de rutas de certificación. Esto es__el__documento que explica qué son las coincidencias y cómo se pueden utilizar tuplas como {Issuer Distinguished Name,Serial Number}o {Subject Distinguished Name,Public Key Identifier}para comparar dos certificados para determinar su equivalencia. OpenSSL utiliza este documento para realizar coincidencias. Consulte también la Sección 3.5.15,"Coincidencia de nombres distinguidos (DN) de terminales"y Sección 3.5.12,"Identificadores clave coincidentes (KID)".


Se supone que los números de serie son únicos. Éste es el problema a superar.Nombres distinguidos del sujeto (DN)son una historia diferente. Si los openssl.cnftiene unique_subject=yes, entonces no se pueden duplicar. Si es unique_subject=noasí, los DN se pueden duplicar.

Creo que necesitas hacer algunas cosas. Primero, utilice una versión moderna o actualizada de las utilidades OpenSSL. Aquí, "moderno" significa uno de los últimos 1.0.2 o 1.1.0. Las versiones anteriores de la utilidad tenían problemas sutiles al hacer coincidir nombres y números de serie.

En segundo lugar, examine su archivo de configuración (normalmente, openssl.cnfpero puede usar un archivo diferente, tal vez copiado, con -config filename) y escriba las configuraciones relevantes, como serial.txty unique_subject=no. Creo que estos son los relevantes [CA_Default]de openssl.cnf:

base_dir       = .
certificate    = $base_dir/cacert.pem  # The CA certifcate
private_key    = $base_dir/cakey.pem   # The CA private key
new_certs_dir  = $base_dir             # Location for new certs after signing
database       = $base_dir/index.txt   # Database index file
serial         = $base_dir/serial.txt  # The current serial number
unique_subject = no                    # Allow reuse of subjects

En tercer lugar, haga una copia de seguridad de todo, especialmente de las cosas importantes como index.txty serial.txt.

Cuarto, cree una lista de los certificados que desea revocar. La lista puede tener entradas como nombres de archivos - john-doe-vpn.pem. Muévelos a su propia carpeta si lo deseas. Preferiblemente, cada uno debe tener un número de serie único y todos DEBEN tener el mismo nombre de Emisor; Las funciones openssl cay ocspno pueden manejar más de un emisor a la vez, aunque para OCSP el protocolo sí podría.

Quinto, cree uno nuevo index.txtque contenga una línea para cada serie. Un enfoque es extraer el asunto, el número de serie y el vencimiento de cada archivo de certificado como en el script que publicó, aunque puede combinar la mayor parte del trabajo del shell en un openssl y un awk por certificado:

for f in *files*; do 
  openssl x509 -noout -enddate -serial -subject -in $f \
  | awk 'BEGIN{FS="=";OFS="\t"} /^serial/{num=$2} /^subject/{sub=$2} 
      /^notAfter/{split($2,a,/ /);mon=index(months,a[1])/3+1;day=a[2]...exp=sprintf(...)}
      END{print "V",exp,"",num,sub}' >>index.txt
done

Si es difícil eliminar (de manera confiable) las publicaciones seriadas duplicadas por adelantado, puede colocar todo y luego descartar los duplicados con awk -F'\t' '!already[$4]++'o sort -t$'\t' -k4,4 -uo similar.

Otro enfoque disponible en 1.0.2 y posteriores, pero solo documentado en 1.1.0, es utilizar openssl ca [-config conffile] -valid certfilepara realizar esta extracción automáticamente. Pero -validcarga innecesariamente la clave privada de la CA cada vez, por lo que si su clave privada está cifrada con contraseña, como es una buena práctica, esto significará escribir su contraseña una y otra vez; para ahorrar tiempo, reemplace temporalmente la clave de CA real y el certificado con una clave temporal sin cifrar y un certificado coincidente, pero por lo demás falso (probablemente autofirmado). -validno escribirá una entrada de serie duplicada, por lo que no necesita preocuparse por excluirlas o eliminarlas.

Coloque en el serialarchivo un valor que seaal menosel valor más alto de cualquier certificado emitido anteriormente; Si quieres pasar al siguiente 10000o 1000000lo que sea para estar seguro y quizás también más claro, está bien. Es posible que deba configurarlo unique_subject=noen este punto.

Sexto, marcar cada certificado (serial) del indexexpediente como revocado. Puede recorrer los archivos de certificados usando openssl ca -revokecada uno, pero es más fácil usar awk como:

awk -F'\t' -vOFS='\t' '{$1="R"; $3="161101000000Z"}' <index.txt >temp && mv temp index.txt
# if you want, you can add a comma and a reason, see man ca or 
# online at https://www.openssl.org/docs/manmaster/man1/ca.html
# under -crl_reason. But there isn't a code for 'CA stupid', and 
# in practice the reason doesn't really matter to reliers except 
# you should't use hold or remove (latter noted in the man) 

En séptimo lugar, genere una CRL a partir de esto indexcon openssl ca -gencrl [-crldays n] [-out file]y/o configure un respondedor OCSP usándolo si (alguno de) los certificados antiguos especificaban la extensión OCSP.

Octavo, una vez que distribuya la CRL y/o comience a ejecutar el (nuevo) respondedor OCSP,todoLos certificados con las series afectadas se revocan y provocarán que la comunicación falle si se usan (y se verifican adecuadamente). SicualquierSi algunos de los números de serie duplicados se encuentran en certificados que sus sistemas aún utilizan, primero deben reemplazarse. Si todavía tiene los archivos de solicitud (CSR) de los sistemas que utilizan los certificados afectados, puede volver a emitirlos openssl ca [-config conffile] [-in reqfile | -infiles reqfile...]y enviarlos a los sistemas en cuestión y hacer que los operadores de esos sistemas los instalen. De lo contrario, primero debe pedirle al operador de cada sistema que le envíe una CSR, que puede ser una que usaron (y guardaron) anteriormente o una nueva que generen.

Finalmente, restaure las entradas "buenas" (serie que no revocó) del indexarchivo anterior, combinándolas con las entradas nuevas para los certificados de reemplazo emitidos en el punto 8 justo arriba. Si está ejecutando un respondedor OCSP (ver arriba), también debe conservar las entradas revocadas; No, no importa, pero probablemente sea más fácil. Hacernorestaurar el valor anterior serialsi es inferior al certificado anterior más altooel nuevo certificado de reemplazo más alto; en su lugar, deje que continúe incrementándose a partir del nuevo valor.


Respecto a las for-loopfechas de impresión y:

hour=substr($3,1,2) ;
minutes=substr($3,4,2);
seconds=substr($3,7,2);
printf "%02d%02d%02d%02d%02d%02dZ", year, month, day, hour, minutes, seconds}'`

Ni siquiera te preocupes por las fechas. Si están caducados, no se pueden utilizar si su PKI funciona correctamente. Si le hace sentir mejor, elimine la clave privada asociada con el certificado y la clave pública.

Lo único que le importa es la lista de certificados a revocar, su número de serie y su nombre distinguido. Aquí, su lista estaría compuesta por certificados como (1) empleado saliente que posee un certificado vigente y una clave privada (es decir, el empleado se jubila o es despedido); (2) un empleado que perdió un dispositivo (es decir, la clave privada está en libertad); etc.


Otra opción que tienes... Quemar la PKI existente hasta los cimientos y empezar de nuevo. En este caso, el paso (1) es revocar la CA raíz y todas las CA intermedias/subordinadas. Luego, deseche la clave privada. El paso (2) es crear una nueva CA raíz, emitir nuevas CA intermedias/subordinadas y, finalmente, emitir nuevos certificados de entidad final. Para el paso (2), incluso puedes hacer el baile de fiesta de firmas.

Lo creas o no, OpenStack usa esta estrategia (o estaba considerando usarla). Es una especie de "PKI efímera" que debe permanecer el tiempo suficiente para satisfacer sus necesidades; y luego ser descartado cuando las cosas van mal.

Para reírte, quizás quieras ver el libro de Peter Gutmann.Seguridad de ingeniería. Es despiadado cuando se trata de PKI y CA públicas.

información relacionada