linux下使用openssl检测PE文件数字签名的证书是否有效

linux下使用openssl检测PE文件数字签名的证书是否有效,第1张

第一个坑: 有效期

windows在判断证书是否有效时不检测证书的有效期, 即使该证书超过有效期好几年了, 只要没有被吊销, 微软仍然认为它是有效的. 但在 openssl 提供的 X509_verify_cert 函数会验证证书的有效期, 因此需要注释掉验证有效期的那部分代码并重新编译 openssl...

OK, 从 openssl 官网 上下载最新的版本, 好吧, 现在还是刚刚修复 Heartbleed 漏洞的 1.0.1g 版本...

下载, 解压, 看下 INSTALL 文档, 先试试可以编译不:

./config

make

运伏梁孝缺稿气不错, 不用安装什么依赖直接编译成功. 将代码根目录产生的 libcrypto.a 添加到项目中测试渣衡下, OK, 可以使用, 下面开始折腾了~

在 crypto/x509/x509_vfy.c 的 153 行找到 X509_verify_cert 函数(在线查看), 局部变量 ok 缓存每一步验证是否通过, 它依次调用了:

check_issued

check_chain_extensions

check_name_constraints

check_trust

check_revocation

internal_verify

check_policy

其中 internal_verify (在线查看)验证了证书的有效期, 进入这个函数, 在 1654 行找到这个代码:

ok = check_cert_time(ctx, xs)

if (!ok)

goto end

看看 check_cert_time 函数, 确认是检查 notBefore 和 notAfter, 因此将上面三行代码注释掉, 验证证书时就不会检测有效期了.

然后就是重新编译 openssl, 将 libcrypto.a 集成到项目里了~

第二个坑: unhandled critical extension

搜索了下, 在 openssl 官网上找到这个:

-ignore_critical

Normally if an unhandled critical extension is present which is not supported by OpenSSL the certificate is rejected (as required by RFC5280). If this option is set critical extensions are ignored.

原来是当openssl遇到证书中有它不支持的 未处理的关键扩展(unhandled critical extension ?) 时, 它会拒绝加载该证书.

再搜索下 -ignore_critical, 在 verify.c 中找到如下代码片段:

else if (strcmp(*argv,"-ignore_critical") == 0)

vflags |= X509_V_FLAG_IGNORE_CRITICAL

然后再使用 X509_STORE_set_flags 函数设置标志位:

X509_STORE *ctx

...

X509_STORE_set_flags(ctx, vflags)

即可.

第三个坑: certificate signature failure

这个坑填不上了, openssl 说:

7 X509_V_ERR_CERT_SIGNATURE_FAILURE: certificate signature failure

the signature of the certificate is invalid.

在windows下导出证书文件, 直接用 openssl 验证, 在加载证书就会出错, PEM_read_bio_X509 返回为空....

第四个坑: A certificate was explicitly revoked by its issuer.

A certificate was explicitly revoked by its issuer. 是 Sysinternals 提供的工具sigcheck.exe 的检测结果, 把文件拎出来一看, 证书真的被撤销了...

OK, 只好根据证书上的 CRL Distribution Point(CRL 分发点) 提供的 URL 下载 撤销证书列表 文件, 然后在调用 X509_verify_cert 验证证书链之前, 设置填充被撤销的证书列表:

X509_CRL *d2i_X509_CRL_fp(FILE *fp, X509_CRL **crl)// 读取被撤销的证书列表

STACK_OF(X509_CRL) *sk_X509_CRL_new_null()

#define sk_X509_CRL_push(st, val) SKM_sk_push(X509_CRL, (st), (val)) // sk_X509_CRL_push(STACK_OF(X509_CRL) *crls, X509_CRL *crl)

void X509_STORE_CTX_set0_crls(X509_STORE_CTX *c, STACK_OF(X509_CRL) *sk) // 设置被撤销的证书列表

同时, 也要设置检查被撤销证书列表的标志位 X509_V_FLAG_CRL_CHECK, 然后再调用X509_verify_cert 验证证书链即可.

填了第四个坑后又引起了第五个坑(如何获取撤销证书列表)和第六个坑(设置检测撤销证书列表的标识位后, 如果该证书没有撤销证书列表则直接报错)...

第五个坑: 获取撤销证书列表文件

证书上的 CRL Distribution Point(CRL 分发点) 属于扩展属性, 在 PKCS #7: Cryptographic Message Syntax V1.5 上没有相关介绍.

在 StackOverflow 上找到这个问答 Openssl - How to check if a certificate is revoked or not, 其中第二个回答说 CRL 是在 RFC 5280 中定义的, 除了证书中附带被撤销的证书列表以外还有使用 OCSP 协议的, 即使证书撤销列表也分为使用 URL分发点和 LDAP DNs(???)提供的, 目前先考虑使用 URL 作为 CRL分发点 的情况吧.

然而 openssl 没有提供直接获取 CRL 分发点 URL 的API, 那个回答说 Apache 的 mod_ssl 模块有本地 CRL 和 OCSP 检测的实现代码, 但没有说明哪里有检测使用 URL 作为 CRL分发点 的实现方法.

然后又在 frank4dd.com上找到这个代码 certextensions.c, 他给出了一个如何使用 openssl 从 X.509v3 版本的证书文件中提取扩展内容的示例程序, 太感谢 Frank4DD 这位仁兄了~~~

到这里后, 可以直接使用他的示例程序, 根据关键字 Full Name 和 URI 定位 CRL 分发点 的 URL, 也可以看看 openssl 是如何提取这个 URL 的, 然后自己实现一个接口.

如果自作孽使用第二种方法的话, 就编译个 debug 版的 openssl 库, 然后调试跟进X509V3_EXT_print 函数, 一步一步的向下走, 直到走到 GENERAL_NAME_print 函数, 这里就是终点了...然后就知道了 CRL 分发点 的 URL 的编号为 6, 也就是 GEN_URI, 直接取结果吧.

第六个坑: CRL有效期

在windows环境下每次查看PE文件的数字签名时, windows 都会从 CRL分发点 下载吊销证书列表做验证, 一般来说, 每个 CRL的有效期是非常短的, 大概只有 5~20 天的有效期吧, 然而我们不可能像 windows 一样每次查看数字签名时就从 CRL分发点 下载最新的吊销列表.

另外, windows 遇到过期的 CRL 时不会产生证书链无效的结果, 但 openssl 在遇到过期的 CRL 时就会导致证书链验证失败, 因此在加载和验证 CRL 时, 要忽略 CRL 的有效期.

分析 openssl 源代码, X509_verify_cert 调用 check_revocation , 之后调用 check_cert , 然后再调用 check_crl , 在这个函数里有检测 CRL 有效期的代码:

if (!(ctx->current_crl_score &CRL_SCORE_TIME))

{

ok = check_crl_time(ctx, crl, 1)

if (!ok)

goto err

}

将其注释掉即可忽略检测 CRL 有效期.

第七个坑: CRL 列表为空导致 openssl 认为没有加载 CRL

9 初始化顺序

10 证书名: key_id

ELF,COFF是机器语言格式,对应于不同的芯片平台(ARM,x86),他们的汇编语言所使用的格式和寄存器等都不宽首同

而PE文件结构是在COFF指令结笑宽构的基础上进行了包装,加入了一些DOS文件头,导入表,导出表,资源表等,然后PE载入器根据一定的流程载入执行慎升数该PE文件

比如,同是x86芯片上的linux和windows,windows的PE文件是无法在linux下执行的,因为linux载入器按照自己的规范根本找不到入口点等,虽然都是x86平台上的COFF或类似的代码格式.....


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/tougao/12271558.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-24
下一篇 2023-05-24

发表评论

登录后才能评论

评论列表(0条)

保存