> > > 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 -0000 1.87 > > > +++ openssl.1 27 Feb 2018 21:38:06 -0000 > > > @@ -360,8 +360,8 @@ > > > The number of days to certify the certificate for. > > > .It Fl enddate Ar date > > > Set the expiry date. > > > -The format of the date is YYMMDDHHMMSSZ > > > -.Pq the same as an ASN.1 UTCTime structure . > > > +The format of the date is [YY]YYMMDDHHMMSSZ, > > > +with all four year digits required for dates after 2050. > > > > "dates after 2050" reads like "2051 and later" to me, which would be wrong. > > It should rather be "dates after 31 Dec 2049". In other words: > > You must specify 2049 as 49 and 2050 as 2050. > > > > so dates *from* 2050, rather than after? > > but..."you *must* specify 2049 as 49": "2049" is valid, right? > > jmc
I did some experiments today; you're right, "2049" works just like "49". Sorry for the wrong claim - it's been obviously too late yesterday :- ) Specifying "2050", however, is not equal to "50" (==1950). So the wording "from 2050" or "after 2049" would both work. With that exception your above diff reads correct to me. And I checked that -startdate and -enddate behave equally. However (and I don't know if that's relevant to someone) the ASN.1 structure used for dates before 2050 is always "UTCTime", no matter if the YYYY or YY format was provided on command line. I checked it by parsing a certifciate with "openssl asn1parse". As already said, I don't see a value in documenting that structure. Others might. Holger
