能，但仅限PEM格式（以-----BEGIN CERTIFICATE-----开头的Base64文本）；DER格式需用d2i_X509。验证可用file或openssl x509 -in -text -noout命令，失败则为DER。
PEM_read_X509 能直接读 CRT/CER 吗？
能，但前提是文件是 PEM 格式（即以 -----BEGIN CERTIFICATE----- 开头的 Base64 文本）。很多 .crt 或 .cer 文件确实是 PEM 编码的，尤其在 Linux/macOS 环境下；而 Windows 常见的 .cer 文件可能是 DER 二进制格式——这时 PEM_read_X509 会返回 nullptr，且 ERR_get_error() 报 ASN1_R_HEADER_TOO_LONG 或 ERR_R_ASN1_LIB。
验证方法很简单：
- 用
file cert.crt看输出是否含 “ASCII text” 或 “PEM certificate” - 或直接跑
openssl x509 -in cert.crt -text -noout：能成功打印就是 PEM；若报 “unable to load certificate”，大概率是 DER
如果是 DER，得换 d2i_X509 + fread 读原始字节，不能硬塞给 PEM 接口。
从内存字符串解析 PEM 格式证书要绕开哪些坑？
别直接传 C 字符串指针给 PEM_read_X509——它只接受 FILE* 或 BIO*。正确路径是用 BIO_new_mem_buf 构造 BIO：
立即学习“C++免费学习笔记（深入）”；
const unsigned char* buf = reinterpret_cast<const unsigned char*>(pem_str.c_str()); BIO* bio = BIO_new_mem_buf(buf, pem_str.size()); X509* x509 = PEM_read_bio_X509(bio, nullptr, nullptr, nullptr); BIO_free(bio); // 必须 free，否则内存泄漏
注意点：
-
BIO_new_mem_buf的第二个参数不能传-1（它不自动找 \0），必须显式传长度 - 如果
pem_str末尾有多余空行或 BOM（比如 UTF-8 BOMEF BB BF），PEM_read_bio_X509会静默失败 - 读完务必调
X509_free(x509)，OpenSSL 不做 RAII
提取 CN/O/OU 等字段为什么总是乱码或为空？
因为 X509_NAME_get_text_by_NID 返回的是原始 ASN.1 字符串编码（可能是 UTF8String、PrintableString 或 T61String），不是标准 C 字符串，且不保证以 \0 结尾。直接 printf("%s", ...) 很可能崩或乱码。
安全做法分两步：
- 先用
X509_NAME_get_entry拿到X509_NAME_ENTRY*，再用X509_NAME_ENTRY_get_data拿到ASN1_STRING* - 调
ASN1_STRING_to_UTF8(&utf8_ptr, asn1_str)转成带 \0 的 UTF-8 缓冲区（返回值是长度，utf8_ptr需OPENSSL_free）
常见错误：
- 误用
NID_commonName却没包含openssl/obj_mac.h，编译不过 - 查
NID_commonName返回 -1 就崩溃——证书未必有 CN，得容错 - 用
free释放ASN1_STRING_to_UTF8分配的内存，实际该用OPENSSL_free
检查有效期时为什么本地时间总差 8 小时？
因为 ASN1_TIME_to_tm 默认按系统本地时区解释 UTC 时间戳。证书里写的是 20250101000000Z，但在东八区机器上调 ASN1_TIME_to_tm 会转成 08:00，导致提前判定过期。
绕过时区最稳的方式是：
- 用
ASN1_TIME_normalize强制归一为 UTC 格式（OpenSSL 1.1.1+） - 或跳过
struct tm，直接用ASN1_TIME_print写入BIO，再读出标准字符串（如"Jan 1 00:00:00 2025 GMT"） - 比较有效期别自己算 time_t：用
ASN1_TIME_diff(&days, &secs, notBefore, notAfter)，它内部已处理时区归一
硬转 time_t 是最大陷阱——不同 OpenSSL 版本对 generalizedtime 和 utctime 的解析逻辑有差异，线上环境极易出错。
