#证书 #客户端证书 #TLS客户端 #rustls #平台 #存储 #本地

rustls-native-certs

rustls-native-certs 允许 rustls 使用平台本地证书存储

17个版本

新版本 0.7.2 2024年8月19日
0.7.1 2024年7月3日
0.7.0 2023年12月3日
0.7.0-alpha.32023年11月30日
0.1.0 2019年11月4日

网络编程类别中排名6

Download history 958035/week @ 2024-05-03 1021400/week @ 2024-05-10 1040675/week @ 2024-05-17 1041282/week @ 2024-05-24 1187039/week @ 2024-05-31 1193255/week @ 2024-06-07 1119553/week @ 2024-06-14 1200179/week @ 2024-06-21 1190135/week @ 2024-06-28 1246459/week @ 2024-07-05 1273074/week @ 2024-07-12 1319332/week @ 2024-07-19 1331452/week @ 2024-07-26 1311328/week @ 2024-08-02 1347480/week @ 2024-08-09 1109436/week @ 2024-08-16

每月下载量5,357,746
用于2,268个crate(188直接使用)

Apache-2.0 OR ISC OR MIT

32KB
354

Logo

rustls-native-certs 允许 rustls 在作为TLS客户端运行时使用平台的本地证书存储。

此功能支持Windows、macOS和Linux

  • 在所有平台上,首先检查环境变量 SSL_CERT_FILE。如果已设置,则从该变量指定的路径加载证书,如果无法从给定路径加载证书,则返回错误。如果未设置,则使用特定于平台的证书源。
  • 在Windows上,证书从系统证书存储加载。使用 schannel crate 访问Windows证书存储API。
  • 在macOS上,证书从密钥链加载。用户、管理员和系统信任设置按Apple的文档合并。使用 security-framework crate 访问密钥存储API。
  • 在Linux和其他类UNIX操作系统上,使用 openssl-probe crate 查找系统CA捆绑包的文件名。

状态

rustls-native-certs 目前处于开发阶段。

如果您想帮忙,请参阅 CONTRIBUTING.md

rustls Documentation

发布历史

  • 0.7.0 (2023-12-03)
    • 切换到使用 pki-types crate。
      • load_native_certs 现在返回 Vec<pki_types::CertificateDer<'static>>,而不是之前的 Vec<Certificate>
      • 移除了 Certificate 新类型。
    • 更新依赖项。
  • 0.6.3 (2023-06-14)
    • 将 MSRV 提升至 1.60。
    • Windows:避免存储当前无效的证书。
    • Certificate 实现 AsRef<[u8]>
  • 0.6.2 (2022-04-14):
    • 更新依赖项。
  • 0.6.1 (2021-10-25):
    • 允许所有平台使用 SSL_CERT_FILE 进行覆盖。
  • 0.6.0 (2021-10-24):
    • 完全移除 rustls 依赖。
  • 0.5.0 (2020-11-22):
    • 更新依赖项。
    • 使 rustls 依赖可选,以用于 reqwest 的证书类型。感谢 @est31。
  • 0.4.0 (2020-07-05):
    • 更新依赖项。
  • 0.3.0 (2020-02-24):
    • 支持更广泛的 UNIX 平台。
    • 更新依赖项。
  • 0.2.0 (2020-01-26):
    • 即使存在无效证书,也返回有效证书。这允许调用者选择“尽力而为”的行为。
  • 0.1.0 (2019-11-04):
    • 初始发布。

API

该库公开一个具有此签名的单个函数

pub fn load_native_certs() -> Result<Vec<pki_types::CertificateDer<'static>>, std::io::Error>

成功时,该函数返回一个加载了该平台上找到的根证书快照的 Vec<pki_types::CertificateDer<'static>>。此函数以特定于平台的方式失败,并以 std::io::Error 表达。

此函数可能很昂贵:在某些平台上,它涉及加载和解析约 300KB 的磁盘文件。因此,应谨慎调用此函数。

工作示例

请参阅 examples/google.rs

我应该使用这个还是 webpki-roots

(背景:webpki-roots 是一个编译 Mozilla 根证书集的 crate。)

webpki-roots 相比,此 crate 在许多方面都更可取。以下是优缺点总结

优点

  • 此 crate 尊重本地根证书配置:既删除用户认为不可信的根,也添加本地可信根。后者对于需要在企业环境中与“透明”TLS 终止中间盒一起工作的应用程序至关重要。
  • 此 crate 立即反映底层系统配置由于 webpki-roots 编译了根证书,因此更新这些证书需要定期更新此 crate、重新编译和重新部署应用程序。这是一个漫长的过程,可能会在严重错误发行的情况下成为负担。
  • 此 crate 与开发辅助工具兼容,如 mkcert

缺点

  • 使用操作系统证书存储并不等同于依赖操作系统信任验证,因为平台验证器可能会在决定是否信任操作系统证书存储中看似包含的根之前施加额外的标准(例如,到期日期)。
  • 操作系统证书存储有时会受到 恶意软件 或仅仅是 不良软件 的影响。
  • 如果禁用或不再受支持,操作系统更新系统可能实际上在保持根证书更新方面相当糟糕
  • 基于 Debian 的 Linux 发行版上 ca-certificates 软件包的质量较差。在撰写本文时,该软件包包含了 Mozilla 集合中未包含的许多证书,原因可能是它们未通过审计并被撤回,或者由于签发错误而被移除
  • 您可能希望出于支持或(可能不妥)安全原因,防止本地配置的影响

许可协议

rustls-native-certs 采用以下三种许可协议进行分发

  • Apache License version 2.0。
  • MIT 许可协议。
  • ISC 许可协议。

它们分别包含在 LICENSE-APACHE、LICENSE-MIT 和 LICENSE-ISC 中。您可以选择根据这些许可协议中的任何一个使用此软件。

依赖项

~0.3–7.5MB
~46K SLoC