[openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj

[Nayna Jain]

Hi all,

I am programmatically generating the self signed certificate and need to specify the "Not Before" and "Not After" date,

Wanted to understand what all formats are acceptable by this API ?

Also,  similarly while using API , what exactly is the time format  expected by X509_cmp_time(X509_get_notAfter(iv_pX509), .......);

Thanks & Regards,
Nayna Jain

[Victor Wagner]

On Mon, 13 Jul 2015 12:25:40 +0530
Nayna Jain <nayn...@in.ibm.com> wrote:

>
> Hi all,
>
> I am programmatically generating the self signed certificate and need
> to specify the "Not Before" and "Not After" date,
>
> Wanted to understand what all formats are acceptable by this API ?

X509_set_notAfter and X509_set_notBefore API expect ASN1_TIME structure.
You can use ASN1_TIME_set function to fill this structure. It expects
integer time_t value.

X509_cmp_time also expects integer time_t value.

So integer number of seconds since the beginning of the epoch (1.1.1970
GMT) is everything you need.

There is also ASN1_TINE_set_string function, which does deal with some
datetime format, but I suggest never use it. Use C runtime library
function strptime, which allows to specify format explicitely or mktime
to prepare time_t value from the user input. And use OpenSSL
ASN1_TIME_print function to convert ASN1_TIME to human-readble form.

>
> Also, similarly while using API , what exactly is the time format
> expected by X509_cmp_time(X509_get_notAfter(iv_pX509), .......);
>
> Thanks & Regards,
> Nayna Jain

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Jakob Bohm]

On 13/07/2015 12:22, Victor Wagner wrote:
> On Mon, 13 Jul 2015 12:25:40 +0530
> Nayna Jain <nayn...@in.ibm.com> wrote:
>
>> Hi all,
>>
>> I am programmatically generating the self signed certificate and need
>> to specify the "Not Before" and "Not After" date,
>>
>> Wanted to understand what all formats are acceptable by this API ?
> X509_set_notAfter and X509_set_notBefore API expect ASN1_TIME structure.
> You can use ASN1_TIME_set function to fill this structure. It expects
> integer time_t value.
>
> X509_cmp_time also expects integer time_t value.
>
> So integer number of seconds since the beginning of the epoch (1.1.1970
> GMT) is everything you need.
>
> There is also ASN1_TINE_set_string function, which does deal with some
> datetime format, but I suggest never use it. Use C runtime library
> function strptime, which allows to specify format explicitely or mktime
> to prepare time_t value from the user input. And use OpenSSL
> ASN1_TIME_print function to convert ASN1_TIME to human-readble form.

Does ASN1_TIME_set_string() support dates outside the
time_t range of the local libc?

This is important when creating root certs with expiry
dates after 2038 (specifically, any time >= epoch+2**31).
It is also important when creating self-signed Android
apk signing certificates (which /must/ be valid for at
least 30 years).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Salz, Rich]

> This is important when creating root certs with expiry dates after 2038

Not an issue for openssl. As long as you use ASN1_TIME values, it's okay. Might be an issue if converting to time_t on 32-bit platforms.

[Jakob Bohm]

On 14/07/2015 21:50, Salz, Rich wrote:

This is important when creating root certs with expiry dates after 2038

Not an issue for openssl. As long as you use ASN1_TIME values, it's okay.  Might be an issue if converting to time_t on 32-bit platforms.

Victor suggested to use only ASN1_TIME_set() together
with libc parsing functions.  That would obviously not
work outside the libc time_t range, hence my question
if ASN1_TINE_set_string() avoids that limitation,
despite Victor's suggestion to never use it.

[Salz, Rich]

>if ASN1_TINE_set_string() avoids that limitation, despite Victor's suggestion to never use it.

It does avoid the limitation, using only |struct tm| to hold parsed fields, and not building a |time_t| from it. Not sure why Viktor doesn't like it. It seems to me it's the only portable thing to ues.

--
Senior Architect, Akamai Technologies
IM: rich...@jabber.at Twitter: RichSalz

[Victor Wagner]

On Tue, 14 Jul 2015 20:35:31 +0200
Jakob Bohm <jb-op...@wisemo.com> wrote:

>
> Does ASN1_TIME_set_string() support dates outside the
> time_t range of the local libc?

Why do yo need time dates outside of 64-bit integer range?
Sun would explode into red giant sooner than that amount of time passes.

> This is important when creating root certs with expiry

> dates after 2038 (specifically, any time >= epoch+2**31).

I don't think that it is a good idea to issue certificates with
expire dates after 2038 now.

Notice - several years ago MD5 collision was discovered, and
certificates signed with md5WithRsaEncryption was phased out.

Now browser manufacturers planning to phase out sha1 certificates, even
though there is no published collision generation for sha1, people
are thinking it is possible enough to avoid using this hashing
algorithms.

There are interesting mathematic results concerning big number
factorization, and experiments with quantum computing, so it seems that
soon we'll have to abandon RSA at all and use only EC algorithms.

So I don't think that one should issue certificates valid for more than
10 years, if he hopes to have even marginal security.

> It is also important when creating self-signed Android
> apk signing certificates (which /must/ be valid for at
> least 30 years).

Does android really have 32-bit time_t? And is it really signed?
I've thought that all modern systems have already switched to 64-bit
time_t or at least iterpret time_t as unsigned, which give time up to
2106.

[Jakob Bohm]

On 15/07/2015 11:13, Victor Wagner wrote:
> On Tue, 14 Jul 2015 20:35:31 +0200
> Jakob Bohm <jb-op...@wisemo.com> wrote:
>
>> Does ASN1_TIME_set_string() support dates outside the
>> time_t range of the local libc?
> Why do yo need time dates outside of 64-bit integer range?
> Sun would explode into red giant sooner than that amount of time passes.

It's all about 32 bit ints, not 64 bit ints.

>
>> This is important when creating root certs with expiry
>> dates after 2038 (specifically, any time >= epoch+2**31).
> I don't think that it is a good idea to issue certificates with
> expire dates after 2038 now.
>
> Notice - several years ago MD5 collision was discovered, and
> certificates signed with md5WithRsaEncryption was phased out.
>
> Now browser manufacturers planning to phase out sha1 certificates, even
> though there is no published collision generation for sha1, people
> are thinking it is possible enough to avoid using this hashing
> algorithms.

On the other hand, many of the new SHA-2 root certificates
also exist as cross certificates issued by (otherwise
disabled) old SHA-1 and MD5 root CAs that were deployed
into browsers and mobile devices before SHA-2 support was
added to most browsers and operating systems. This only
works because those old SHA-1/MD5 CAs were issued with
long lifetimes that outlast their actual active use.

At least one major CA made the mistake of originally
issuing their old root cert with a lifetime that
expired a few years ago, while the difficult to
update mobile devices that trust that cert remains
functional (hardware hasn't died).

Thus an update signed by a competing CA is needed to
provision those devices with the new extended lifetime
of that root cert, so those devices can then trust new
certificates issued with longer keys (close to the limit
of the crypto libraries embedded in ROM images).

A more widespread problem of this kind is that Windows 8
and Windows 8.1 do not include most of the Microsoft
accepted SHA-2 roots out of the box, but will instead
download those one by by one from Microsoft if and only
if the system has been configured to implicitly trust
any and all future changes to Microsoft's list of trusted
CAs.

> There are interesting mathematic results concerning big number
> factorization, and experiments with quantum computing, so it seems that
> soon we'll have to abandon RSA at all and use only EC algorithms.

I have yet to see any convincing arguments why QC doesn't
break EC too. So far the only argument I have seen is
that one published QC algorithm is most easily applied
to DL and RSA keys, which says very little about the
applicabilityof QC speedups to other NP problems.

> So I don't think that one should issue certificates valid for more than
> 10 years, if he hopes to have even marginal security.
>
>> It is also important when creating self-signed Android
>> apk signing certificates (which /must/ be valid for at
>> least 30 years).
>
> Does android really have 32-bit time_t? And is it really signed?
> I've thought that all modern systems have already switched to 64-bit
> time_t or at least iterpret time_t as unsigned, which give time up to
> 2106.

I haven't checked the local code on Android for this,
except that it does work very well with post-2038
expiry dates when validating certs. Note that most
Android devices use 32-bit CPUs with 32-bit int.

However the Linux/OSX/Windows workstations that are
used to generate the self-signed end certificates
that identify Android software packages will often be
32 bit systems with 32 bit signed time_t. And the
Android Market (Google Play) upload requirements
insist that the expiry is after 2038, in order to
recognize future App updates as being the same app
with access to previous version data.

If and when the QC disaster happens, Android will
presumable start requiring double signatures (the
file format supports this) with both the original
App cert and a new stronger cert. The specific
way such a requirement will be formulated (e.g.
should the new cert be issued by the old cert or
not, in which relative order should it be placed
in the signature collection etc.) has not yet
been defined.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Viktor Dukhovni]

On Wed, Jul 15, 2015 at 01:33:08AM +0000, Salz, Rich wrote:

> >if ASN1_TINE_set_string() avoids that limitation, despite Victor's suggestion to never use it.
>
> It does avoid the limitation, using only |struct tm| to hold parsed fields, and not building a |time_t| from it. Not sure why Viktor doesn't like it. It seems to me it's the only portable thing to ues.

Let's not confuse "Victor Wagner" and "Viktor Dukhovni". :-)

In Victor Wagner's defense, time_t with only 32 bits should be
getting increasingly rare.

--
Viktor.