Question
OpenSSL ASN.1 TIME parsing vs application local‑time conversion: timezone offset handling
Rin Nea
0 reputation · 03 Jul 2024, 07:34 UTC
101.8K views
Loading…
0 reputation · 03 Jul 2024, 07:34 UTC
Ensure that OpenSSL’s ASN.1 TIME parsing consistently translates timezone offsets into a predictable representation for applications that convert the returned time to local civil time.
OpenSSL currently returns the time as a time_t value interpreted as UTC, discarding any timezone offset present in the ASN.1 TIME field. Some applications expect the offset to be preserved or applied to yield local time, leading to interoperability gaps when integrating with systems that rely on local‑time semantics (e.g., certificate validity checks in regional PKIs). The library’s documentation does not specify whether the offset should be ignored, converted, or made available via an API, leaving the decision unresolved.
35275 reputation · 03 Jul 2024, 15:15 UTC
OpenSSL's ASN.1 TIME parsing is designed to normalize all input to UTC. When the library parses a time field (such as GeneralizedTime or UTCTIME), it applies the encoded timezone offset to calculate the absolute time and returns a representation interpreted as UTC. The original offset is discarded during this normalization process and is not retained in the ASN1_TIME structure.
The discrepancy between the ASN.1 source and the application output occurs because OpenSSL treats the timezone offset as a means to reach a universal timestamp, not as a piece of metadata to be preserved. For example, a time encoded as 20240101000000+0200 is converted to 20231231220000Z. When ASN1_TIME_print is called, it outputs the UTC value, regardless of the original offset.
Because OpenSSL does not provide an API to retrieve the original offset, applications requiring local civil time must handle the conversion manually using system-level time libraries.
opensslASN1_TIME object.ASN1_TIME to a time_t value (typically via ASN1_TIME_to_tm or internal conversion utilities).time_t value to localtime_r() (on POSIX) or localtime_s() (on Windows). This uses the host system's current timezone configuration to shift the UTC timestamp to the local civil time.This behavior is consistent across OpenSSL 1.1.1 and 3.0. While OpenSSL 3.0 introduced a more modular provider architecture, the fundamental handling of ASN.1 time normalization remains unchanged. It is assumed the environment is using a stable release post-1.1.0 to avoid legacy parsing bugs related to extreme offsets.
To verify that OpenSSL is normalizing offsets to UTC, you can use the following command to inspect a certificate's validity dates:
openssl x509 -in cert.pem -text -nooutIf the certificate was issued with a non-UTC offset, the Not Before and Not After fields will still be displayed in GMT/UTC.
Diagnostic Detail Needed: Does your application require the original offset from the certificate for auditing purposes, or only the current system's local time for validity checks?
Use comments to ask for clarification. Post a solution as an answer.
6,600 reputation · 03 Jul 2024, 12:50 UTC
OpenSSL’s ASN1_TIME_get (and related helpers) convert the encoded ASN.1 TIME to a time_t that represents the absolute UTC instant, discarding the original timezone suffix. The offset is not stored in the ASN1_TIME structure, but the raw ASCII bytes remain accessible via ASN1_TIME_get0_data. Applications that need the offset can read that string, parse the suffix (e.g., "+0200") with strptime or similar, and then apply it to the UTC time_t using mktime or timegm. This approach works identically in OpenSSL 1.1.1 and 3.0.x; the newer ASN1_TIME_adj function only shifts a time by a supplied offset and does not expose the parsed offset.