Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

We have lots of embedded TLS clients on the field. TLS Servers must be authenticated.

Because long power cuts may reset clock of those devices, we have requirement to use certificates with validity period: from 19700101000001Z to 99991231235959Z.

How to use openssl to create certificate requests with those kind of validity period?

I only find the -days option for setting period, and that is not enough.

share|improve this question

4 Answers 4

up vote 7 down vote accepted

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;
                    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_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).

share|improve this answer

As Thomas Pornin said, the certificate request does not contain any dates, the notBefore and notAfter dates are set when the new certificate is created (signed) by the CA.

If you use the openssl ca tool, you can set them using -startdate date and -enddate date command line options or using default_startdate and default_enddate in [ca] section of the config file.

share|improve this answer

I developed a simple tool gossl that allows specifying cert validity start date and duration in various time units. It is an alternative to openssl, coded in Go, without dependencies, MIT license.

share|improve this answer

If you can't make it, just fake it. ;-)

libfaketime (FakeTime Preload Library)
- report faked system time to programs without having to change the system-wide time

By faking the system time you can set "Not Before" to any value you like.

share|improve this answer
explain what this link tells us... – Matthew Peters Apr 27 at 0:13
If I understand the library correctly, you would have to set the web service's time to a non-correct time, which could screw up all other web apps, logging, correlating security logs, etc. – schroeder Apr 27 at 2:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.