Vous avez deux façons de créer des certificats dans le passé. Soit truquer l'heure (1) (2), soit définir l'intervalle de temps lors de la signature du certificat (3).
1) Tout d'abord, sur le fait de simuler le temps: pour faire croire à un programme qu'il est dans une date différente du système, regardez libfaketime
etfaketime
Pour l'installer dans Debian:
sudo apt-get install faketime
Vous utiliseriez alors faketime
avant la openssl
commande.
Pour des exemples d'utilisation:
$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
De man faketime
:
La commande donnée sera amenée à croire que l'heure système actuelle est celle spécifiée dans l'horodatage. L'horloge murale continuera de fonctionner à partir de cette date et heure, sauf indication contraire (voir les options avancées). En fait, faketime est un simple wrapper pour libfaketime, qui utilise le mécanisme LD_PRELOAD pour charger une petite bibliothèque qui intercepte les appels système à des fonctions telles que time (2) et fstat (2).
Ainsi par exemple, dans votre cas, vous pouvez très bien définir une date de 2008, et créer ensuite un certificat d'une validité de 2 ans jusqu'en 2010.
faketime '2008-12-24 08:15:42' openssl ...
En guise de remarque, cet utilitaire peut être utilisé dans plusieurs versions Unix, y compris MacOS, comme un wrapper pour tout type de programmes (non exclusif à la ligne de commande).
À titre de clarification, seuls les binaires chargés avec cette méthode (et leurs enfants) ont leur heure modifiée, et la fausse heure n'affecte pas l'heure actuelle du reste du système.
2) Comme l'indique @Wyzard, vous avez également le datefudge
package qui est très similaire à l'utilisation faketime
.
En tant que différences, datefudge
n'influence pas fstat
(c'est-à-dire ne change pas la création de l'heure du fichier). Il possède également sa propre bibliothèque, datefudge.so, qu'il charge à l'aide de LD_PRELOAD.
Il a également un -s
static time
où le temps référencé est toujours renvoyé malgré le nombre de secondes supplémentaires qui se sont écoulées.
$ datefudge --static "2007-04-01 10:23" sh -c "sleep 3; date -R"
Sun, 01 Apr 2007 10:23:00 +0100
3) En plus de simuler le temps, et encore plus simplement, vous pouvez également définir le point de départ et le point de fin de validité du certificat lors de la signature du certificat dans OpenSSL.
L'idée fausse de la question à laquelle vous liez dans votre question est que la validité du certificat n'est pas définie au moment de la demande (à la demande de RSE), mais lors de sa signature.
Lorsque vous utilisez openssl ca
pour créer le certificat auto-signé, ajoutez les options -startdate
et -enddate
.
Le format de date dans ces deux options, selon opensl sources at openssl/crypto/x509/x509_vfy.c
, est ASN1_TIME alias ASN1UTCTime: le format doit être YYMMDDHHMMSSZ ou YYYYMMDDHHMMSSZ.
Citant 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."
*/
Et à partir du journal CHANGE (bug 2038?) - Ce journal des modifications est juste une note de bas de page supplémentaire, car il ne concerne que ceux qui utilisent directement l'API.
Changements entre 1.1.0e et 1.1.1 [xx XXX xxxx]
*) Ajoutez les types ASN.1 INT32, UINT32, INT64, UINT64 et les variantes préfixées par Z. Celles-ci sont destinées à remplacer LONG et ZLONG et à être de taille sûre. L'utilisation de LONG et ZLONG est déconseillée et programmée pour dépréciation dans OpenSSL 1.2.0.
Ainsi, la création d'un certificat du 1er janvier 2008 au 1er janvier 2010, peut se faire comme:
openssl ca -config /path/to/myca.conf -in req.csr -out ourdomain.pem \
-startdate 200801010000Z -enddate 201001010000Z
ou
openssl ca -config /path/to/myca.conf -in req.csr -out ourdomain.pem \
-startdate 0801010000Z -enddate 1001010000Z
-startdate
et -enddate
apparaissent dans les openssl
sources et le journal des modifications; comme l'a noté @guntbert, bien qu'ils n'apparaissent pas dans la man openssl
page principale , ils apparaissent également dans 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).
Citant openssl/CHANGE
:
Changements entre 0.9.3a et 0.9.4 [09 août 1999]
*) Correction des arguments -startdate et -enddate (qui manquaient) au programme 'ca'.
PS Quant à la réponse choisie à la question à laquelle vous faites référence de StackExchange: c'est généralement une mauvaise idée de changer l'heure du système, en particulier dans les systèmes de production; et avec les méthodes de cette réponse, vous n'avez pas besoin des privilèges root lorsque vous les utilisez.