Hi,
Holger Mikolon wrote on Tue, Feb 27, 2018 at 11:04:10PM +0100:
> jmc@ wrote:
>> i wonder whether we could more simply just use the date format [YY]YY,
>> explain the 2050 cutoff, and forget about mentioning asn.1 time
>> structures.
>>
>> or do you think there is a practical reason why the
On Wed, Feb 28, 2018 at 08:43:34PM +0100, Holger Mikolon wrote:
> > > > Index: openssl.1
> > > > ===
> > > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> > > > retrieving revision 1.87
> > > > diff -u -r1.87 openssl.1
> > > > ---
> > > Index: openssl.1
> > > ===
> > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> > > retrieving revision 1.87
> > > diff -u -r1.87 openssl.1
> > > --- openssl.1 18 Feb 2018 07:43:55 - 1.87
> > > +++ openssl.1
On Tue, Feb 27, 2018 at 11:04:10PM +0100, Holger Mikolon wrote:
> > hi.
> >
> > i wonder whether we could more simply just use the date format [YY]YY,
> > explain the 2050 cutoff, and forget about mentioning asn.1 time
> > structures.
> >
> > or do you think there is a practical reason why the
> hi.
>
> i wonder whether we could more simply just use the date format [YY]YY,
> explain the 2050 cutoff, and forget about mentioning asn.1 time
> structures.
>
> or do you think there is a practical reason why the user would need to
> know it? i suspect not.
Actually the mentioning of the
On Tue, Feb 27, 2018 at 08:54:48PM +0100, Holger Mikolon wrote:
> When playing with "openssl ca" with various validity end dates I could
> not manage end dates of 2050 or later - until I started reading code and
> the RFC 5280. As far as I understand it now (and is confirmed by various
> tests),
When playing with "openssl ca" with various validity end dates I could
not manage end dates of 2050 or later - until I started reading code and
the RFC 5280. As far as I understand it now (and is confirmed by various
tests), the openssl parameter "-enddate" expects one of two date/time
formats -
