Cómo eliminar duplicados en el archivo de certificado de CA Bundle

1

Tengo un archivo de certificado de paquete de CA grande y cada vez que recibo una solicitud para agregar un nuevo certificado al paquete existente, necesito asegurarme de que no esté presente. Cómo puedo validar los duplicados.

La alineación del certificado dentro del paquete parece ser diferente.

Ejemplo:

Cert 1
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO

Cert 2
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL

Estos son duplicados y como están alineados de manera diferente, no pude hacer un extracto y comparar.

Sus sugerencias y aportaciones son bienvenidas.

    
pregunta user3512380 28.06.2014 - 23:49
fuente

1 respuesta

1

Aunque no lo dijiste, en su mayoría asumiré openssl . Un montón de software utiliza el formato PEM para certificados (que es base64 cuando mostró MÁS los guiones-COMIENZO y los guiones-líneas FINALES, SE NECESITAN), y bastante utiliza un archivo que contiene varios certificados de PEM llamado paquete, pero AFAIK solo se abre , y las aplicaciones que lo llaman, utilizan un archivo de paquete PEM para CA confiables .

Para información, la longitud de las líneas base64 difiere debido a que sigue diferentes estándares. Los RFC de PEM que definieron por primera vez la base64 dijeron 64. Los RFC de MIME que ahora se usan más ampliamente, por ejemplo, 76.

Opción 0: no molestarse. Un "archivo de CA" de openssl funciona bien con el mismo certificado (CA) que se produce más de una vez. Requiere un poco más de memoria, pero en los sistemas de escritorio modernos (o superiores) es probable que ni siquiera pueda medir el efecto de menos de unos pocos miles de certificados adicionales.

Opción 1: canonicalizar. Filtre cada certificado a través de openssl x509 con todos los valores predeterminados (que es copia, informe a PEM, PEM superado), es decir, openssl x509 <oldfile >newfile . El resultado consistirá en utilizar rupturas de 64 caracteres. Como beneficio adicional, puede especificar -subject para agregar un nombre legible (al principio) al principio del archivo, lo que se ignorará openssl o las aplicaciones que lo usen, pero es posible que otras aplicaciones no lo hagan.

Pero tanto para 0 como para 1, si tiene certificados diferentes para la misma CA , como uno vencido y una renovación, o uno roto y una solución, que no son duplicados por su definición, que NO funcionará de forma confiable; openssl hasta la fecha (1.0.1) usa solo el primer certificado encontrado para un CA (emisor) nombre y AKI si está disponible, lo cual Si no tienes cuidado es el incorrecto. (Se anuncia que 1.0.2 tendrá cambios en la validación de la cadena de certificados, y aún no he visto los detalles, por lo que esto puede cambiar).

Opción 2: use hashes de nombre. Use el método openssl "CApath" o "CAdir" además, o en su lugar: cree un directorio en el que coloque cada certificado CA como un archivo, y cada vez agrega uno do c_rehash (en Unix o Windows si instala perl, o si no es un equivalente de BAT). Si su nuevo certificado y cualquier otro existente tienen el mismo hash del nombre del sujeto, obtendrá enlaces (o nombres) con un sufijo que no sea ".0". Dos certificados con el mismo hash de tema, por ejemplo. abcdef01.0 y abcdef01.1 ALMOST ciertamente (no del todo) tienen el mismo Asunto, es decir, el nombre de la CA, pero puede o no ser el mismo certificado; compara esos archivos específicos.

Tenga en cuenta que después de haber construido un "CAdir" en este formato, la línea de comandos de openssl y al menos muchas aplicaciones le permiten usarlo en lugar de "CAfile"; algunos incluso dan el consejo, en su mayoría anticuado, de que es "más eficiente" (en 1995 marcó una diferencia, hoy en día es probablemente de 0.1 ms en lugar de 0.2 ms).

Otras herramientas: si he adivinado mal sobre openssl, puedes hacer la opción de canonicalización importando y exportando desde el almacén de claves de Windows, el almacén de claves de Firefox o un almacén de claves de Java. Espero que Mac, Apple y Android tengan capacidades similares, pero no las conozco.

Los dos primeros tienen GUI convenientes (pero tediosas); para Windows creo que todavía hay un formulario de línea de comandos pero, como es habitual en MS, lo cambian cada vez que parpadeas, así que dejé de intentar mantener el ritmo. Estos también tienen la propiedad, posiblemente mala o posiblemente buena, de que si deja estos certificados en el almacén de confianza y no los elimina, sus respectivos navegadores (es decir, Chrome o Firefox) confiarán en los certificados del sitio web de esas CA.

Para java (asumiendo que JRE está en su RUTA, de lo contrario, use la ruta de acceso)

  keytool -keystore whatever [-alias x] -importcert -rfc -file certfile
  keytool -keystore whatever [-alias x] -exportcert -rfc -file newfile

o aún más fácil: si importa y deja en un JKS todos los mismos certificados que su paquete de PEM, cada uno con un único -alias que debe especificar, y Si intenta agregar otra copia de un certificado que ya está en el JKS, le avisará. Sin embargo, no detectará certificados con la misma CA.

    
respondido por el dave_thompson_085 29.06.2014 - 15:43
fuente

Lea otras preguntas en las etiquetas