校园网下 Conda 的 SSL 证书错误

Linux

校园网下 Conda 的 SSL 证书错误

引言

在航院内某台服务器完成了校园网 Auth4 准入认证后，我以为一切网络请求都该正常了，结果在配置环境时使用 conda 更新时却报错了：

1
2
3
4
5
6
(base) sheny@kepler:~$ conda update conda
Collecting package metadata (current_repodata.json): failed

CondaSSLError: Encountered an SSL error. Most likely a certificate verification issue.

Exception: HTTPSConnectionPool(host='mirrors.tuna.tsinghua.edu.cn', port=443): Max retries exceeded with url: /anaconda/cloud/conda-forge/linux-64/current_repodata.json (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:997)')))

关键报错是：

1
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate

意思是：conda 在尝试访问 https://mirrors.tuna.tsinghua.edu.cn 时，收到的是一个 自签名证书，验证失败了。—— 说明请求没有被正常发到目标服务器，而是被“劫持”到了别的地方。为了验证这个情况，使用 curl 进行尝试（不加协议 curl 默认以 HTTP 协议链接）：

1
2
3
4
5
6
7
8
9
(base) sheny@kepler:~$ curl mirrors.tuna.tsinghua.edu.cn
<html>
<head>
<script type="text/javascript">location.href="http://auth6.tsinghua.edu.cn/index_159.html"</script>
</head>
<body>
Authentication is required. Click <a href="http://auth6.tsinghua.edu.cn/index_159.html">here</a> to open the authentication page.
</body>
</html>

果然，返回的是清华校园网的认证页面。也就是说，我的请求并没有真正抵达 tuna 镜像，而是在网络入口就被 NAC （Network Access Control）系统劫持，重定向到了认证页面。而对于 conda 这类工具，它们发现服务端返回了一个非法的自签证书，立即拒绝连接，这就是报错的根源。但确实对 IPv4 地址做过准入认证，那为什么 HTTPS 请求还是被拦截？IPv6 有影响吗？到底什么是“证书”？HTTPS 是怎么验证安全连接的？证书验证失败背后的流程是怎样的？这篇博客是围绕这些问题做得一些总结，不过可能有不太正确的地方。

校园网认证与双栈网络 —— IPv4 ≠ IPv6

双栈网络架构

现代操作系统普遍采用双栈（Dual Stack）网络架构，即同时启用 IPv4 和 IPv6 协议。每台主机通常拥有两个地址：一个 IPv4 地址（如：10.20.30.40）；一个 IPv6 地址（如：2001:da8::1234）。当访问一个网站（比如 mirrors.tuna.tsinghua.edu.cn），DNS 会返回两种记录：A 记录（IPv4）；AAAA 记录（IPv6）。随后，操作系统可能会根据 Happy Eyeballs 策略选择连接方式，比如优先尝试 IPv6，如果失败则回退到 IPv4。清华校园网同样采用 IPv4/v6 双栈架构，每台终端在联网时会被分配一个 IPv4 和一个 IPv6 地址。但在实际认证机制上，IPv4 和 IPv6 被视为两个相互独立的网络身份，尤其在“准入认证”体系中体现得尤为明显。清华校园网的认证系统（NAC）对不同的接入方式有不同的行为，主要分为两种接入类型：

image-20250428220333112

二层接入（L2） —— 支持 IPv4/v6 联动认证 ✅：二层接入适用于紫荆宿舍、教学楼无线网、以及部分院系宿舍/办公区等。特点是用户的设备通过交换机或 AP 直接连接到核心路由器，校园网核心路由器可获取用户的 MAC 地址 + IP 地址 + DHCP 租约，可以将 IPv4 和 IPv6 绑定为“同一用户”。因此，只需认证一次（IPv4 或 IPv6 任意一种），两个协议均可使用，断网时也会同时断开 IPv4 与 IPv6 连接。这类用户体验最佳，登录一次即可畅游双栈网络。

三层接入（L3） —— IPv4 和 IPv6 完全独立 ❌：三层接入适用于一些院系实验室、楼宇、有独立网关/交换机的网络。特点是用户通过自己所在单位的网关接入核心路由器，校园网核心路由器只能看到 IP，无法获取 MAC 和 DHCP 信息。因此其无法判断“谁是同一个用户”，导致无法联动 IPv4 与 IPv6 的认证状态。这意味着：使用 IPv4 登录认证成功后，只有 IPv4 联网是通的；此时如果应用走的是 IPv6，就仍会被 NAC 拦截。NAC 会根据不同协议类型选择不同认证服务器：

  • IPv4 认证使用 auth4.tsinghua.edu.cn
  • IPv6 认证使用 auth6.tsinghua.edu.cn

只有以 HTTP 协议访问某些白名单站点时，校园网才可能触发自动跳转认证页面；否则，就会静默失败。所以，对于三层接入用户，如果希望使用命令行工具正常访问外网资源，确保 IPv6 也完成了准入认证。因此对于身处于航院的三层接入的服务器，虽然完成了 IPv4 认证，在命令行中运行：

1
conda update conda

Conda 使用 https://mirrors.ustc.edu.cn，HTTPS 请求走 IPv6 → 没有认证 → 被 NAC 拦截 → 返回一个 自签名 HTTPS 证书 → ❌ SSL 验证失败。

场景 二层接入 三层接入
IPv4 与 IPv6 是否联动 ✅ 是 ❌ 否
只认证 IPv4，是否 IPv6 也能通 ✅ 是 ❌ 不通
是否可能 curl/conda 报 SSL 错 ❌ 一般不会 ✅ 可能发生
是否需特别注意命令行应用 ❌ 少见问题 ✅ 高发问题

为什么校园网无法重定向 HTTPS

HTTPS

那么为什么只有 HTTP 协议才能被校园网重定向，而 HTTPS 却不行呢？证书到底是什么呢？我们每天都在访问 https:// 开头的网站，但 HTTPS 的“安全”到底从何而来？为什么一个证书可以让你信任你访问的网站？又是什么机制保证了“别人不能冒充百度、谷歌”？要理解这些问题，我们得先明白：HTTPS 本质上是「HTTP + TLS」。

  • HTTP：负责数据格式，浏览器和服务器怎么传内容
  • TLS（原名 SSL）：负责“加密、安全和验证”

HTTPS 本质上就是在普通 HTTP 通信外面包了一层 TLS 加密层，TLS 做了三件事：1. 加密通信内容（别人无法偷听）；2. 验证服务器身份（别人无法冒充）；3. 确保通信完整性（别人无法中途篡改）。其中，验证服务器身份的功能就是通过证书来实现的。HTTPS 通信的大致流程可以分成以下四点：

  1. 客户端发起请求（Client Hello）：浏览器发起连接请求，声明自己支持的加密算法、TLS 版本等；2. 服务器响应（Server Hello）：返回服务器的证书（包含域名、公钥、CA 签名等），还可能包含 DH 参数、Session 信息等；3. 客户端验证证书：检查域名是否匹配（如访问 baidu.com，证书必须是 baidu.com），检查 CA 是否是受信任的机构（浏览器内置的 CA 列表），检查证书是否过期、是否被吊销，如果证书无效，就中断连接；4. 建立密钥并加密通信：客户端生成一个“预主密钥（pre-master secret）”，用服务器提供的公钥加密它，发送给服务器，服务器用自己的私钥解密，双方基于这个预主密钥生成会话密钥（symmetric key）。从此开始，所有通信都用这个会话密钥加密，防窃听、篡改

而如果没有 HTTPS，访问 http://baidu.com，内容是明文的。于是中间人就可以偷看数据、篡改收到的内容、插入认证页 / 广告、冒充要访问的网站。这正是校园网 NAC 对 HTTP 的操作方式。

网站证书

网站证书（SSL 证书） 是服务器出示给客户端的一份“身份证明”，它包含以下信息：

字段 内容
CN 网站的域名（如 www.baidu.com）
Issuer 谁签发了这张证书（如 DigiCert Inc.）
有效期 证书什么时候生效，什么时候过期
公钥 用于加密数据，配合私钥使用
签名 由上级 CA 使用其私钥签名，保证内容没被篡改

证书由权威的第三方机构 CA（Certificate Authority, 证书颁发机构）签发，像是一张盖了章的证明信，告诉客户端：“我就是百度，证书是真的，DigiCert 为我作保。”

证书申领的具体流程大致是这样的：

🔨 1. 服务器自己生成一对密钥（公钥 + 私钥）

  • 网站管理员（或服务器软件，如 Nginx/Apache 配置时）
  • 在本地生成一对密钥对（通常用 openssl 命令）：
1
openssl genrsa -out server.key 2048

这时得到：

秘钥类型 作用
私钥（private key） 只有服务器自己保存，绝不能泄露
公钥（public key） 将包含在后续提交给 CA 的请求中

📝 2. 服务器生成一个 证书签名请求（CSR）

  • 然后用自己的私钥生成一个 CSR 文件（Certificate Signing Request）：
1
openssl req -new -key server.key -out server.csr

CSR 文件里包含：

内容 描述
公钥（Public Key） 提供给 CA 使用
域名（Common Name, CN） 你的网站域名，比如 www.baidu.com
组织信息（可选） 比如公司名字、部门
一个签名 由你的私钥签名，证明是你自己发的

🏢 3. 服务器把 CSR 提交给 CA

  • 把 server.csr 发给一个权威的证书机构（CA，比如 DigiCert, GlobalSign, Let's Encrypt）
  • CA 会进行一系列验证（验证你拥有这个域名）
  • 验证成功后，CA 会用自己的 CA 私钥签名这份公钥信息，生成正式的证书 .crt 文件返回给你

这个 .crt 文件证书文件，里面包含服务器生成的公钥、域名、有效期、以及 CA 的签名。当我们访问 https://www.baidu.com 的时候，就可以在浏览器里查看百度的证书：

image-20250428222538597

🧾 这是一个“可信”证书的标准特征：

项目 内容 说明
📛 颁发对象 baidu.com 证书绑定的域名，必须匹配你访问的网址
🏢 组织信息 Beijing Baidu Netcom Science Technology Co., Ltd 真实公司注册信息，提升可信度
🧾 颁发者（CA） GlobalSign RSA OV SSL CA 2018 一个全球受信任的权威证书机构（CA）
🕒 有效期 2024年7月8日 - 2025年8月9日 通常有效期为 1 年，过期自动报错
🔒 SHA-256 指纹 一串长长的哈希值 用于唯一标识该证书，防篡改、防伪造

当然我们在云平台比如腾讯云或者阿里云使用证书服务时，不需要这么麻烦。在比如腾讯云申请 SSL 证书时，腾讯云会自动完成密钥生成、CSR 生成以及证书申领的全过程。成功后，腾讯云直接把证书和私钥一起打包发送给我们。我们下载下来的证书压缩包通常包含以下内容：

文件名 说明
cloud.tencent.com_bundle.crt 最终的服务器证书（含根证书链）
cloud.tencent.com.key 你的私钥
cloud.tencent.com.csr CSR 文件（申请证书时用过，可以忽略）
cloud.tencent.com_bundle.pem 合并格式的证书（某些服务器配置用）

在部署（比如宝塔、Nginx、Apache）时：密钥（KEY）对应 .key 文件，证书（CERT/PEM）：对应 .crt 文件。

img

校园网证书篡改

这是我们在校园网中尚未准入认证时，尝试访问 https://www.baidu.com 时，浏览器弹出的警告界面：

  • 报错信息：NET::ERR_CERT_COMMON_NAME_INVALID
  • 证书签发者是：HTTPS-Self-Signed-Certificate-652dbdaa9c1db920
  • 证书没有任何可信组织信息，且有效期异常长（20年）
  • Chrome 提示：“您的连接不是私密连接”

这意味着：我们的 HTTPS 连接被校园网 NAC 系统拦截，并伪造了一个自签名假证书。

image-20250428220716765

在正常情况下，HTTPS 通信就像我们和打算和“张三”聊天（发起 HTTPS 连接）：1. 有人走过来说“我是张三”（服务器返回证书）；2. 你要求“出示身份证”（浏览器验证证书）；3. 身份证是真的、盖了公安局公章（证书由可信 CA 签发）✅；4. 你们成功建立“密语”（TLS 安全信道），别人偷听也没用。但是，如果身份证是他自己打印的（自签证书），我们马上就会警觉，浏览器也一样：直接拦截连接并报警。

校园网的 NAC 之所以要伪造证书，主要是因为 HTTPS 的加密特性使得它无法直接篡改传输内容。为了绕过这个限制，NAC采用了“伪造服务器”的方式：

  1. 你发起访问请求，比如 https://www.baidu.com。
  2. NAC 拦截了你的请求，没有把它转发到真正的百度服务器。
  3. NAC 自己伪造了一个假证书（通常是自签名证书），假装自己就是百度。
  4. 如果自己伪造的证书被相信了，那么我们就和 NAC 之间建立了一个加密连接（虽然对方是伪造的）。这样 NAC 就能把篡改后的网页（比如认证登录页面）以 HTTPS 的形式发回给你，而你也能正常接收到认证内容。
  5. 但实际上浏览器收到 NAC 伪造的证书后，会进行验证：
    • 发现证书不是受信任的 CA 签发 ❌
    • 发现证书的域名与目标网站不匹配 ❌
  6. 验证失败，浏览器立刻弹出安全警告，并阻止继续访问，防止用户被中间人攻击。

所以如果我们在 curl 中使用了 -k（或 --insecure）参数，强行跳过证书验证，那么 curl 就会信任 NAC伪造的服务器，建立起加密连接。而在 HTTP 中，因为没有加密，NAC 可以轻松返回如下内容：

1
<script>location.href="http://auth4.tsinghua.edu.cn"</script>

浏览器立刻跳转到认证页面，用户甚至察觉不到中间被劫持了。而在 HTTPS 中，一旦握手失败，浏览器就立刻中断连接，保护用户。

协议 NAC能做什么？ 浏览器表现 安全性
HTTP 直接篡改内容，插入认证页 正常跳转 ❌ 不安全，明文传输
HTTPS 无法篡改内容，只能伪造证书 显示证书错误，拒绝连接 ✅ 加密+身份验证

📚 总结：从校园网认证到 HTTPS 安全机制

在本文中，我们从一次 conda update 遇到 SSL 认证失败的问题出发，系统梳理了现代网络环境中的一系列关键概念。

首先，现代操作系统普遍启用了 IPv4/IPv6 双栈网络。每台设备通常同时拥有一个 IPv4 地址和一个 IPv6 地址。当访问域名时，系统会优先尝试使用 IPv6，如果失败则回退到 IPv4。在清华校园网这样的环境中，二层接入用户可以通过一次认证同时打通 IPv4 和 IPv6，但三层接入用户由于核心路由器无法识别 MAC 地址，因此 IPv4 和 IPv6 需要分别独立认证。这就导致即使你已经认证通过 IPv4，IPv6 仍可能无法直接使用，尤其在命令行工具（如 curl、conda）优先使用 IPv6时，常常会遇到连接失败、证书错误等问题。

在校园网 NAC（网络准入控制）机制下，HTTP 和 HTTPS 流量的处理也截然不同。由于 HTTP 是明文传输，NAC 可以轻松篡改 HTTP 返回内容，将原本请求的网页直接替换为跳转到认证页（如 auth4.tsinghua.edu.cn）。浏览器不会警觉，用户也能顺利完成认证。而 HTTPS 流量则是加密的，NAC 无法篡改加密内容，因此只能伪装成目标服务器，伪造一个自签名证书返回。浏览器在验证证书时，发现证书未由受信任的 CA 签发、域名不匹配，立即中断连接，显示“您的连接不是私密连接”的安全警告，从而保护了用户免受中间人攻击。

为了深入理解这一过程，我们系统介绍了 HTTPS 的核心流程。HTTPS 是在 HTTP 协议之上加了一层 TLS 加密，TLS协议负责加密通信内容、验证服务器身份以及确保数据传输完整性。服务器必须提前生成一对公钥和私钥，并将公钥连同域名信息生成 CSR 文件，提交给受信任的证书颁发机构（CA）。CA在验证后，用自己的私钥对服务器的公钥信息签名，颁发正式证书。浏览器在建立 HTTPS 连接时，会检查证书是否由受信任的 CA 签发、是否域名匹配、是否在有效期内。任何一项不符合，连接都会被中断，保障用户安全。此外，我们还解释了在云服务平台（如腾讯云）下载证书时，为什么可以直接获得私钥文件。因为在申请过程中，如果选择“由云平台自动生成 CSR”，那么平台会在服务器端自动生成密钥对，因此证书包中会包含私钥（.key 文件）。而如果是用户自己生成 CSR 并上传，那么私钥永远只掌握在用户手中。

最终，通过这些知识，我们理解了为何在校园网环境下 HTTPS 无法像 HTTP 那样被 NAC 拦截跳转，同时也复盘了 HTTPS 为什么能够在互联网上保护通信的机密性与可信性 —— 证书的真实性验证了服务器身份，加密确保了传输安全，而标准化流程保证了整个互联网生态的健康运行。