数字证书_CA_详解

目录

一、数字证书简介

[二、 CA(证书颁发机构)](#二、 CA(证书颁发机构))

[(一) 证书链(信任链)](#(一) 证书链(信任链))

[1. 根证书](#1. 根证书)

[2. 中间证书](#2. 中间证书)

[3. 网站证书](#3. 网站证书)

[(二) 抓包软件的证书链与信任机制](#(二) 抓包软件的证书链与信任机制)

[1. 抓包通信流程](#1. 抓包通信流程)

[2. 证书链伪造与信任验证流程](#2. 证书链伪造与信任验证流程)

[(三) 关于移动设备的CA](#(三) 关于移动设备的CA)


一、数字证书简介

数字证书就是网站的身份证 + 公钥 、是用来证明身份搭建加密通道用的

证书通常包含以下信息:

  • 持有者的信息: 网站域名(最重要的)、组织名称(对于企业级证书)、地址等。
  • 公钥: 用于加密信息的密钥。
  • 颁发者信息: 签发该证书的证书颁发机构名称。
  • 有效期: 证书的生效日期和到期日期。
  • 数字签名: 由 CA 使用其私钥生成的签名,用于证明证书的真实性和完整性。浏览器可以用 CA 的公钥来验证这个签名。

二、 CA(证书颁发机构)

CA全称:Certificate Authority,即"证书颁发机构",负责签发证书 和提供背书服务的机构。

  • 签发: CA 生成一张新的证书,并用自己的私钥对其内容进行数字签名,正式颁布这个证书。
  • 背书: CA 用自己的名义担保:这个证书里的信息(比如域名、身份、公钥)是我验证过、我认可的。
  • 关于申请证书,有免费的CA(一般用于个人网站),有收费的CA(用于企业/银行等需高信任场景)。

注:CA(证书颁发机构)是一个角色,全球有很多个CA,任何合法的组织都可以成为 CA,只要它有能力签发并管理证书。

(一) 证书链(信任链)

注:如果证书链出现问题,客户端会提示证书不被信任等信息。

证书链:网站证书 → 中间证书 → 根证书。

验证过程

  • 客户端(浏览器)拿到网站证书,用中间证书的公钥验证它的签名。
  • 再用根证书的公钥验证中间证书的签名。
  • 最后确认根证书是否在客户端的信任列表中。

证书提供

  • 服务器:发送网站证书和中间证书。
  • 客户端:预装根证书,不需要服务器提供。

1. 根证书

根证书是信任链的起点,由根证书颁发机构自签名,客户端(浏览器)默认信任根证书

根证书预装在您的设备(比如电脑、手机的操作系统或浏览器)中,作为验证其他证书的"信任锚点"。

2. 中间证书

中间证书由根CA签发,授权给中间证书颁发机构,用来签发网站证书。

3. 网站证书

网站证书由中间CA签发,颁给具体的网站或服务器,包含网站的公钥和身份信息(如域名),用于加密通信和证明身份。

网站证书是你访问的网站 拿给浏览器的"身份证",里面包含网站域名、公钥等信息。

常见网站证书类型:

  • DV(域名验证证书)
    • 只验证域名所有权,比如你能证明你控制了 abc.com,就能签。
  • OV(组织验证证书)
    • 除了验证域名,还验证组织/企业的合法存在性和注册信息(工商注册、电话等)。
  • EV(扩展验证证书)
    • 最高级别验证,验证企业真实身份、营业执照、电话、注册地址等。
    • 部分浏览器(不同版本)会在地址栏显示"绿色锁"和公司名。

(二) 抓包软件的证书链与信任机制

1. 抓包通信流程

以访问 https://www.baidu.com 为例:

Burp Suite 在本地充当代理服务器,整个 HTTPS 抓包过程的核心通信路径如下:

  • 浏览器访问百度,实际连接的是本地的 BurpSuite 代理(如 127.0.0.1:8080)
    • 浏览器只与 Burp 通信,浏览器不与百度服务器做交互。
  • Burp 将请求转发给真实的百度服务器
  • 百度返回响应 → Burp 拦截并解析 → 再转发给浏览器
    • 浏览器收到的响应其实是 Burp 伪装百度发出的。

2. 证书链伪造与信任验证流程

由于浏览器访问的是 HTTPS,必须进行证书验证。流程如下:

  • 浏览器要求:提供 https://baidu.com 的合法证书
  • 但此时它连接的是 BurpSuite,不是百度。
  • Burp 动态生成伪造的"baidu.com"站点证书
    • 此证书由 Burp 内部的自签名 CA 生成(非真实百度证书)。
  • 浏览器校验证书的签发者
  • 若浏览器的CA中没有Burp自签名CA,浏览器就会提示:证书无效 / 连接不安全 / 无法建立安全连接等安全告警。

所以抓包软件一般都会有一个CA证书导入导出的功能。

(三) 关于移动设备的CA

安卓和苹果都把CA明确区分成了两种:

  • 系统 CA(System CA)
    • 出厂时就内置在操作系统里的根证书
    • 只能由厂商签名后刷入系统分区
    • 默认所有 App 都信任
    • 普通用户(非 root)无法修改或新增
  • 用户 CA(User CA)
    • 用户手动安装的证书(比如通过设置 → 安全 → 受信任凭据 → 用户)
    • 存在于用户空间

从 Android 7/ iOS 10 开始以后的版本,默认大部分APP不信任用户CA,所以即使把抓包软件的CA证书导入到手机中也没用除非是把证书装到了系统CA区(需要ROOT权限)

注:手机开启ROOT之后,也会遭受大部分APP限制,ROOT手机限制使用之类的。

相关推荐
程序员的世界你不懂7 小时前
(9)-Fiddler抓包-Fiddler如何设置捕获Https会话
前端·https·fiddler
Think Spatial 空间思维11 小时前
【实施指南】Android客户端HTTPS双向认证实施指南
android·网络协议·https·ssl
昔我往昔12 小时前
https和http有什么区别-http各个版本有什么区别
网络协议·http·https
Bright166815 小时前
mkcert实现本地https
网络协议·http·https
锐成191916 小时前
FTPS、HTTPS、SMTPS以及WebSockets over TLS的概念及其应用场景
网络协议·https·ssl
2501_9159214316 小时前
高敏感应用如何保护自身不被逆向?iOS 安全加固策略与工具组合实战(含 Ipa Guard 等)
websocket·网络协议·tcp/ip·http·网络安全·https·udp
2501_9151063217 小时前
App 上线后还能加固吗?iOS 应用的动态安全补强方案实战分享(含 Ipa Guard 等工具组合)
websocket·网络协议·tcp/ip·http·网络安全·https·udp
2501_9159184119 小时前
iOS 项目怎么构建稳定性保障机制?一次系统性防错经验分享(含 KeyMob 工具应用)
websocket·网络协议·tcp/ip·http·网络安全·https·udp
2501_9159090619 小时前
从零搭建到 App Store 上架:跨平台开发者使用 Appuploader与其他工具的实战经验
websocket·网络协议·tcp/ip·http·网络安全·https·udp