libwebsockets中ASN1时间到struct tm转换的问题分析

在libwebsockets项目的4.3.3版本及main分支中，发现了一个关于ASN1时间格式转换为struct tm结构体的潜在问题。这个问题涉及到SSL/TLS证书中时间戳的解析处理，值得开发者重视。

问题背景

在SSL/TLS证书中，有效期等信息使用ASN1时间格式表示。libwebsockets中有一个函数lws_tls_openssl_asn1time_to_unix负责将这种格式转换为Unix时间戳。该函数在处理两种不同长度的ASN1时间字符串时存在转换逻辑问题。

问题细节

ASN1时间格式有两种表示方式：

1. 13字符格式：YYMMDDHHMMSSZ（年份用2位表示）
2. 15字符格式：YYYYMMDDHHMMSSZ（年份用4位表示）

当前代码在处理这两种格式时存在两个主要问题：

1. 年份基准错误：代码直接将解析出的年份数值赋给tm_year，而实际上struct tm中的tm_year字段表示的是从1900年开始的年数。例如，2025年应该表示为125（2025-1900），但代码直接赋值为2025。

2. 2位年份处理不符合RFC5280规范：对于13字符格式，RFC5280规定：

   • YY≥50时，解释为19YY
   • YY<50时，解释为20YY 当前代码简单地在YY基础上加100，这会导致2049年后出现错误。

解决方案

经过讨论，确定了以下修正方案：

1. 对于15字符格式（4位年份）：

   • 解析出完整年份后减去1900，直接得到tm_year的正确值

2. 对于13字符格式（2位年份）：

   • 先解析出2位年份数值
   • 根据RFC5280规范处理年份转换
   • 对于YY<50的情况，加100得到正确的tm_year值（因为2000-1900=100）

技术影响

这个问题的修正确保了：

• 证书有效期检查的准确性
• 符合RFC5280规范要求
• 正确处理2000年后的所有日期
• 保持与系统时间函数（如mktime）的兼容性

开发者建议

在处理时间转换时，开发者应当注意：

1. 清楚了解各时间结构体的定义和基准
2. 严格遵循相关RFC规范
3. 特别注意2位年份的"千年虫"问题
4. 进行充分的边界测试（特别是跨世纪的日期）

这个问题的发现和解决过程展示了开源社区协作的力量，也提醒我们在处理时间相关逻辑时需要格外谨慎。