From 909873bda30c1d568adef767b35558ced5c86d81 Mon Sep 17 00:00:00 2001 From: Paul Yang Date: Mon, 10 Jul 2017 01:52:33 +0800 Subject: [PATCH] Update doc/ca.pod to clarify description for dates "Note" part is based on PR #3566 Reviewed-by: Ben Kaduk Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/3895) --- doc/man1/ca.pod | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/doc/man1/ca.pod b/doc/man1/ca.pod index 4a5970892c..ab8ce7211f 100644 --- a/doc/man1/ca.pod +++ b/doc/man1/ca.pod @@ -164,12 +164,16 @@ Don't output the text form of a certificate to the output file. =item B<-startdate date> This allows the start date to be explicitly set. The format of the -date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure). +date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure), or +YYYYMMDDHHMMSSZ (the same as an ASN1 GeneralizedTime structure). In +both formats, seconds SS and timzone Z must be present. =item B<-enddate date> This allows the expiry date to be explicitly set. The format of the -date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure). +date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure), or +YYYYMMDDHHMMSSZ (the same as an ASN1 GeneralizedTime structure). In +both formats, seconds SS and timzone Z must be present. =item B<-days arg> @@ -716,6 +720,14 @@ For example if the CA certificate has: then even if a certificate is issued with CA:TRUE it will not be valid. +=head1 HISTORY + +Since OpenSSL 1.1.1, the program follows RFC5280. Specifically, +certificate validity period (specified by any of B<-startdate>, +B<-enddate> and B<-days>) will be encoded as UTCTime if the dates are +earlier than year 2049 (included), and as GeneralizedTime if the dates +are in year 2050 or later. + =head1 SEE ALSO L, L, L, L, -- 2.25.1