The "99991231235959Z" end of validity period may run you into trouble, because some software still converts date to an internal representation as a number of seconds since the "Epoch" (January 1st, 1970, 00:00 UTC) over a signed 32-bit integer. This internal representation fails on January 2038. Setting a validity period which spans beyond that fateful date may imply that your certificates will be rejected by some implementations.
Also, when a device sees its clock reset due to a long power cut, I suppose it does not get reset to a random date; it gets reset to a "default" date. Your certificate validity does not have to cover eight thousand years, but "just" the current days (for devices with a clock well adjusted) and the days around the default value to which clocks are reset when they lose power. Setting the validity period to range from 1970 to, say, 2037, ought to cover all cases, and will keep the internal representation (if used by a specific implementation) in the range where 32-bit signed arithmetic is good.
Be aware that if your devices do not have an accurate clock, then you will not have reliable revocation support, unless you enforce OCSP with client nonces.
That being said, validity period is not part of the certificate request. The period is chosen at the time the certificate is emitted, by the CA.
The OpenSSL command-line tool can be used as a very crude CA, although it was mostly designed for debugging. That tool offers "commands", two of which being able to create an X.509 certificate, x509
and req
. Both provide only one option to adjust the validity period, which is the -days
option. This is quite plainly visible if you take a look at the source code, e.g. in apps/x509.c
:
if ((x=X509_new()) == NULL) goto end;
if (sno == NULL)
{
sno = ASN1_INTEGER_new();
if (!sno || !rand_serial(NULL, sno))
goto end;
if (!X509_set_serialNumber(x, sno))
goto end;
ASN1_INTEGER_free(sno);
sno = NULL;
}
else if (!X509_set_serialNumber(x, sno))
goto end;
if (!X509_set_issuer_name(x,req->req_info->subject)) goto end;
if (!X509_set_subject_name(x,req->req_info->subject)) goto end;
X509_gmtime_adj(X509_get_notBefore(x),0);
X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL);
As you see in this code snippet, the new X.509 certificate structure is created, (and defaults the start and end of the validity period to the current date); the two last lines of the code adjust the validity period using the days
parameter, and nothing else.
So if you want to adjust the validity period to arbitrary dates, you have two possibilities:
Set the current date of your computer to the start date you wish to use, so that openssl
believes that we really are in the early 1970s; and set -days
to 24000 or so. This is an awful hack and setting the clock of your computer back in the pre-Disco past might be difficult (modern computers automatically set their clock with NTP), and may break things (e.g. a MacOS X 10.5 computer will not be able to connect to WiFi if its clock is before year 2000).
Emit the certificate programmatically, using OpenSSL as a library, not as a command-line tool (alternative: modify OpenSSL source code to include the command-line options you need for x509
and/or req
).