Not according to the PKIX RFC 5280
CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime.
Conforming applications MUST be able to process validity
This is, unfortunately, the tip of an iceberg. The timezone offset is actually
stored in the ASN1 string, it's just not displayed. There's a bunch of
RFC-compliant issues involved, date and time parsing, etc.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
#2990] Bug Report:openssl timezone issue
This is, unfortunately, the tip of an iceberg. The timezone offset is actually
stored in the ASN1 string, it's just not displayed. There's a bunch of
RFC-compliant issues involved, date and time parsing, etc.
--
Rich Salz, OpenSSL dev team; rs
: [openssl.org #2990] Bug Report:openssl timezone issue
Hello,
I’ve found there is issue in opensssl for timezone. As I understood if I add
time zone then it will be create as per that time zone but it has been created
by adding that much amount of time. As shown below.
When I am going to create
Hello,
I’ve found there is issue in opensssl for timezone. As I understood if I add
time zone then it will be create as per that time zone but it has been created
by adding that much amount of time. As shown below.
When I am going to create certificate with –startdate and –enddate in format
