openssl – Cree un certificado autofirmado con fecha de finalización en el pasado

Pregunta:

Me gustaría crear certificados autofirmados sobre la marcha con fechas de inicio y finalización arbitrarias, incluidas fechas de finalización en el pasado . Preferiría usar herramientas estándar, por ejemplo, OpenSSL, pero cualquier cosa que haga el trabajo sería genial.

La pregunta de Stack Overflow ¿ Cómo generar un certificado openssl con vencimiento de menos de un día? hace una pregunta similar, pero quiero que mi certificado esté autofirmado.

En caso de que se lo pregunte, los certificados son necesarios para las pruebas automatizadas.

Respuesta:

Tiene dos formas de crear certificados en el pasado. Fingiendo la hora (1) (2), o definiendo el intervalo de tiempo al firmar el certificado (3).

1) En primer lugar, sobre fingir la hora: para hacer que un programa piense que está en una fecha diferente a la del sistema, eche un vistazo a libfaketime y faketime

Para instalarlo en Debian:

sudo apt-get install faketime

Luego usaría faketime antes del comando openssl .

Para ejemplos de uso:

$faketime 'last friday 5 pm' /bin/date
Fri Apr 14 17:00:00 WEST 2017
$faketime '2008-12-24 08:15:42' /bin/date
Wed Dec 24 08:15:42 WET 2008

Del man faketime :

Se engañará al comando dado para que crea que la hora actual del sistema es la especificada en la marca de tiempo. El reloj de pared seguirá funcionando a partir de esta fecha y hora a menos que se especifique lo contrario (consulte las opciones avanzadas). En realidad, faketime es un contenedor simple para libfaketime, que usa el mecanismo LD_PRELOAD para cargar una pequeña biblioteca que intercepta las llamadas del sistema a funciones como time (2) y fstat (2).

Entonces, por ejemplo, en su caso, puede definir muy bien una fecha de 2008 y luego crear un certificado con una validez de 2 años hasta 2010.

faketime '2008-12-24 08:15:42' openssl ... 

Como nota al margen, esta utilidad se puede utilizar en varias versiones de Unix, incluido MacOS, como envoltorio de cualquier tipo de programa (no exclusivo de la línea de comandos).

Como aclaración, solo los binarios cargados con este método (y sus hijos) tienen su hora cambiada, y la hora falsa no afecta la hora actual del resto del sistema.

2) Como indica @Wyzard, también tiene el paquete datefudge que es muy similar en uso a faketime .

Como diferencias, datefudge no influye en fstat (es decir, no cambia la creación de la hora del archivo). También tiene su propia librería, datefudge.so, que carga usando LD_PRELOAD.

También tiene un static time -s donde el tiempo al que se hace referencia siempre se devuelve a pesar de cuántos segundos adicionales hayan pasado.

$ datefudge --static "2007-04-01 10:23" sh -c "sleep 3; date -R"
Sun, 01 Apr 2007 10:23:00 +0100

3) Además de fingir la hora, y aún más simple, también se puede definir el punto de inicio y final de validez del certificado al firmar el certificado en OpenSSL.

El concepto erróneo de la pregunta a la que se vincula en su pregunta es que la validez del certificado no se define en el momento de la solicitud (en la solicitud de CSR), sino al firmarlo.

Cuando utilice openssl ca para crear el certificado autofirmado, agregue las opciones -startdate y -enddate .

El formato de fecha en esas dos opciones, según las fuentes de openssl/crypto/x509/x509_vfy.c en openssl/crypto/x509/x509_vfy.c , es ASN1_TIME también conocido como ASN1UTCTime: el formato debe ser YYMMDDHHMMSSZ o YYYYMMDDHHMMSSZ.

Citando openssl/crypto/x509/x509_vfy.c :

int X509_cmp_time(const ASN1_TIME *ctm, time_t *cmp_time) { static const size_t utctime_length = sizeof("YYMMDDHHMMSSZ") - 1; static const size_t generalizedtime_length = sizeof("YYYYMMDDHHMMSSZ") - 1; ASN1_TIME *asn1_cmp_time = NULL; int i, day, sec, ret = 0; /* * Note that ASN.1 allows much more slack in the time format than RFC5280. * In RFC5280, the representation is fixed: * UTCTime: YYMMDDHHMMSSZ * GeneralizedTime: YYYYMMDDHHMMSSZ * * We do NOT currently enforce the following RFC 5280 requirement: * "CAs conforming to this profile MUST always encode certificate * validity dates through the year 2049 as UTCTime; certificate validity * dates in 2050 or later MUST be encoded as GeneralizedTime." */

Y del registro de CAMBIOS (¿error de 2038?): Este registro de cambios es solo una nota al pie adicional, ya que solo concierne a aquellos que usan directamente la API.

Cambios entre 1.1.0e y 1.1.1 [xx XXX xxxx]

*) Agregue los tipos ASN.1 INT32, UINT32, INT64, UINT64 y variantes con el prefijo Z. Estos están destinados a reemplazar LONG y ZLONG y ser seguros para el tamaño. El uso de LONG y ZLONG no se recomienda y está programado para su desaprobación en OpenSSL 1.2.0.

Entonces, la creación de un certificado desde el 1 de enero de 2008 hasta el 1 de enero de 2010, se puede hacer como:

openssl ca -config /path/to/myca.conf -in req.csr -out ourdomain.pem \
-startdate 200801010000Z -enddate 201001010000Z

o

openssl ca -config /path/to/myca.conf -in req.csr -out ourdomain.pem \
-startdate 0801010000Z -enddate 1001010000Z

-startdate y -enddate aparecen en las fuentes openssl y en el registro de CAMBIOS; como señaló @guntbert, aunque no aparecen en la página principal man openssl , también aparecen en man ca :

-startdate date this allows the start date to be explicitly set. The format of the date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure). -enddate date this allows the expiry date to be explicitly set. The format of the date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).

Citando openssl/CHANGE :

Cambios entre 0.9.3ay 0.9.4 [9 de agosto de 1999]

*) Arregle los argumentos -startdate y -enddate (que faltaban) en el programa 'ca'.

PD En cuanto a la respuesta elegida de la pregunta a la que hace referencia de StackExchange: generalmente es una mala idea cambiar la hora del sistema, especialmente en los sistemas de producción; y con los métodos en esta respuesta, no necesita privilegios de root cuando los usa.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım