Thank you. I have applied the change to the latest LibreSSL portable tarball and tested it.
With the new define (SMALL_TIME_T) enabled, a 32-bit time_t build using "openssl s_client -connect" can successfully connect to a server and verify its certificate chain when one or more notAfter dates after 2038 are present. However, using "nc -c" fails to connect to the same server. The reason being that libtls also needs to clamp the notAfter date. Unfortunately the new ASN1_time_tm_clamp_notafter symbol is not public and is located in libcrypto which makes it unavailable to libtls. Seems to me there are two approaches: 1) duplicate the ASN1_time_tm_clamp_notafter function in libtls 2) make the symbol public to avoid duplicating code and potentially creating an out-of-sync/maintenance problem The two patches in this series take approach (2). The first makes ASN1_time_tm_clamp_notafter public and the second calls it from the appropriate place in libtls. A 32-bit time_t build including these two additional patches (and with SMALL_TIME_T defined) successfully connects using "nc -c" to servers with one or more notAfter dates after 2038. These patches are submitted under the standard OpenBSD license. --Kyle On Aug 13, 2017, at 14:26, Bob Beck wrote: > https://github.com/openbsd/src/commit/b943944faeecf3a978bf3f57df1b35335ffecbec > > On Sun, Aug 13, 2017 at 1:56 PM, Bob Beck <b...@obtuse.com> wrote: > >> >> So. To summarize my take on this >> >> If you're still running OSX 9, I think you like peril.. for lots of >> reasons.. Running OpenSSL is probably the least of your perils. >> >> Sadly, Linux Raspberry PI sucks, because 32 bit Linux still hasn't >> dealt >> with this. >> >> RFC 5280 section 4.1.2.5 guarantees you may see these. >> >> So in the interest of allowing 32 bit linux to use LibreSSL, I've >> just >> committed a change to that portable >> can make use of. >> >> We will allow portable to clamp he notAfter field in a certificate >> to the >> largest represntable 32 bit time >> if a notafter field from a certificate is larger than that value. >> We do >> not clamp any other times >> in any other places (a larger than 32 bit notBefore, for example, >> would >> continue to be not accepted. >> >> This will alllow RFC 5280 4.1.2.5 compliant certs, and certs with >> notAfter >> dates after 2038 to >> be accepted as if the notAfter date was 03:14:08 UTC on Tuesday, 19 >> January 2038.