1. 项目概述当自动化测试撞上SSL/TLS证书墙如果你正在用Selenium做自动化测试特别是爬取数据或者测试内部系统那么“您的连接不是私密连接”、“NET::ERR_CERT_AUTHORITY_INVALID”或者“创建 TLS 客户端凭据时发生严重错误。内部错误状态为 10013。”这类弹窗你一定不陌生。这堵“证书墙”几乎是每个自动化测试工程师的必经之路它能让你的脚本在关键时刻卡住让整个测试流程功亏一篑。今天要聊的就是如何一劳永逸地解决Selenium自动化测试中的SSL/TLS证书问题让你写的脚本在任何HTTPS页面面前都能畅通无阻。这个问题之所以棘手是因为它横跨了网络协议、浏览器安全策略和自动化工具配置三个领域。简单来说HTTPS网站需要一个受信任的证书来建立安全连接。当你用Selenium启动一个浏览器时这个浏览器可能不信任你测试环境中的证书比如自签名证书、过期的证书或者像chls.pro.ssl这类调试工具安装的证书或者遇到了像CVE-2016-2183这样的老漏洞扫描误报。浏览器的职责就是保护用户所以它会坚决地拦截这些它认为不安全的连接而Selenium的默认行为是尊重浏览器的安全策略这就导致了自动化流程的中断。本指南的目标读者是那些已经会用Selenium写基础脚本但在处理HTTPS站点、特别是非公开或测试环境站点时感到头疼的测试开发者和爬虫工程师。我将从问题根源讲起提供从简单绕过到高级管理的全套解决方案并分享我踩过无数坑之后总结出的实战经验。无论你用的是Chrome、Firefox还是Edge无论你的证书是自签的、机构签发的还是调试工具生成的这里都有对应的“药方”。2. 核心问题拆解为什么Selenium会“怕”证书在深入解决方案之前我们必须先搞清楚敌人是谁。SSL/TLS证书问题在Selenium自动化中通常表现为两大类症状一是浏览器直接弹出红色警告页阻止页面加载二是脚本在后台报错例如“no required ssl certificate was sent”或TLS握手失败。其背后的核心原因可以归结为以下几点。2.1 信任链的断裂自签名与私有CA证书这是测试环境中最常见的情况。在开发或预发布环境中我们经常使用自签名证书或者由内部私有证书颁发机构签发的证书。这些证书没有嵌入到操作系统或浏览器的全球受信任根证书列表中。当Selenium驱动浏览器访问这样的站点时浏览器会进行证书验证检查证书是否过期、域名是否匹配、颁发者是否可信。一旦发现颁发者不可信信任链验证失败浏览器便会毫不犹豫地拦截。注意很多人会尝试用--ignore-certificate-errors这个Chrome选项它确实能绕过警告但这是“掩耳盗铃”。它只是让浏览器不显示警告页但底层的不安全连接状态可能会影响页面中某些依赖安全上下文的JavaScript代码的执行导致测试结果不可靠。2.2 安全协议的协商失败你可能会遇到“创建 TLS 客户端凭据时发生严重错误。内部错误状态为 10013。”这样的错误。这通常发生在Windows系统上特别是使用较老版本的Pythonrequests库或某些网络库时。其根本原因是客户端你的Selenium脚本或背后的驱动库尝试与服务器协商一个过时或不安全的SSL/TLS协议版本如SSLv2、SSLv3而服务器已禁用这些不安全的协议或者系统策略禁止使用它们。这不仅仅是浏览器的问题也可能是发起HTTP请求的客户端库的问题。2.3 浏览器安全特性的“过度保护”现代浏览器如Chrome和Edge安全策略日益严格。例如它们对证书的公共密钥强度、签名算法有最低要求。如果遇到使用弱算法如SHA-1的证书或者像CVE-2016-2183Sweet32这种涉及弱加密算法的漏洞即使证书本身有效浏览器也可能出于安全考虑而拒绝连接。安全扫描工具经常会把使用老旧协议或算法的服务标记为存在此漏洞。2.4 中间人代理证书的信任问题在自动化测试中我们有时会使用像mitmproxy这样的中间人代理来拦截和修改网络请求以便进行性能测试、模拟异常或验证数据。这就需要你在浏览器或系统中安装mitmproxy的根证书。如果证书安装不正确、没有导入到浏览器信任的证书存储区或者Selenium启动的浏览器实例使用了独立的用户数据目录而没有继承系统的证书信任那么同样会导致证书错误。3. 解决方案全景从临时绕过到根治管理面对证书问题我们有不同层次的应对策略从快速但粗糙的“绕过”到稳定但复杂的“信任”再到一劳永逸的“根治”。选择哪种方案取决于你的测试场景、安全要求和维护成本。方案选择速查表方案类别典型方法优点缺点适用场景临时绕过--ignore-certificate-errorsacceptInsecureCertsCapability配置简单快速解决问题不安全可能影响页面功能浏览器控制台会有错误临时测试、爬取公开数据不推荐用于严肃测试主动信任--ignore-certificate-errors-spki-list浏览器选项导入证书相对安全只信任特定证书配置稍复杂证书更换后需更新配置测试环境有固定自签名证书系统级根治将证书导入操作系统或浏览器的信任存储一劳永逸所有应用包括Selenium都信任需要系统权限操作有风险公司内部开发/测试环境证书长期不变编程式处理使用desired_capabilities或浏览器特定选项灵活可集成到测试框架中需要编写更多代码不同浏览器差异大需要动态处理多种证书情况的框架我个人在实际项目中对于长期存在的测试环境强烈推荐采用“系统级根治”或“主动信任”方案。虽然初期配置麻烦一点但能从根本上消除不稳定因素让测试脚本像访问HTTP一样顺畅地访问HTTPS这才是自动化的意义所在。接下来我们将深入每一种方案的实操细节。4. 实战指南Chrome/Edge浏览器的证书处理Chrome及其内核的Edge浏览器是目前Selenium自动化最主流的平台。处理它们的证书问题主要有以下几种武器。4.1 基础绕过使用--ignore-certificate-errors这是最广为人知的方法通过在启动浏览器时添加命令行参数来实现。from selenium import webdriver from selenium.webdriver.chrome.options import Options chrome_options Options() chrome_options.add_argument(--ignore-certificate-errors) chrome_options.add_argument(--ignore-ssl-errors) driver webdriver.Chrome(optionschrome_options) driver.get(https://your-internal-site-with-self-signed-cert.com)实操心得--ignore-certificate-errors和--ignore-ssl-errors通常一起使用以确保覆盖更广的错误类型。这种方法启动的浏览器地址栏仍然会显示“不安全”的提示但不会弹出拦截页面。致命缺点页面中所有通过JavaScript发起的子请求如Fetch、AJAX如果也遇到证书问题依然可能失败导致页面功能不全。因此这只能作为最后手段或纯视觉/布局测试时使用。4.2 高级信任信任特定证书的公钥SPKI这是比简单忽略所有错误更优雅、更安全的方案。Chrome支持通过--ignore-certificate-errors-spki-list参数只信任拥有特定公钥的证书。即使证书到期续签只要公钥不变就依然受信任。步骤1获取证书的公钥SPKI指纹你需要目标网站的证书文件.crt或.pem。可以通过浏览器导出或者用OpenSSL命令从服务器获取。openssl s_client -connect your-server:443 -showcerts /dev/null 2/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64这条命令会输出一个Base64编码的字符串这就是证书的公钥SPKI指纹。步骤2在Selenium中配置from selenium import webdriver from selenium.webdriver.chrome.options import Options chrome_options Options() spki_fingerprint YOUR_BASE64_ENCODED_SPKI_FINGERPRINT_HERE chrome_options.add_argument(f--ignore-certificate-errors-spki-list{spki_fingerprint}) driver webdriver.Chrome(optionschrome_options) driver.get(https://your-secure-site.com)注意这个方法非常精准且安全但前提是你能拿到证书的公钥并且该证书相对固定。对于使用Let‘s Encrypt等自动续签且每次续签公钥可能变化的证书就不太适用。4.3 终极方案将证书导入Chrome信任库这是最彻底的方法让浏览器从心底里信任这个证书就像信任Google、Apple的证书一样。步骤1准备证书文件确保你拥有证书的.crt或.pem文件。如果是自签名证书这就是你生成的那个文件如果是内部CA你需要其根证书。步骤2手动导入一次性的打开Chrome访问chrome://settings/certificates。点击“授权中心”标签页。点击“导入”选择你的证书文件按照向导完成导入确保勾选“信任此证书以标识网站”。步骤3让Selenium使用已配置好的用户数据目录关键点来了Selenium默认启动一个全新的、干净的浏览器实例它不会使用你刚才手动配置的证书库。因此我们必须指定一个持久的用户数据目录。from selenium import webdriver from selenium.webdriver.chrome.options import Options chrome_options Options() # 指定一个固定的用户数据目录路径例如 ‘./chrome_profile’ chrome_options.add_argument(--user-data-dir./chrome_profile) # 可以指定配置文件目录非必需 # chrome_options.add_argument(--profile-directoryDefault) driver webdriver.Chrome(optionschrome_options) driver.get(https://your-internal-site.com)第一次运行后./chrome_profile目录会被创建。此时你需要手动操作一次用这个脚本启动浏览器后手工访问上述证书管理页面导入证书。关闭浏览器后下次再用同一个--user-data-dir启动Selenium证书信任关系就已经在了。避坑技巧确保运行Selenium脚本的用户有对该目录的读写权限。如果有多套测试环境需要不同的证书可以为每套环境创建不同的--user-data-dir路径。在CI/CD流水线中可以考虑预先准备一个已经导入好证书的“黄金镜像”用户数据目录打包进Docker镜像或直接复制使用。5. 实战指南Firefox浏览器的证书处理Firefox使用自己独立的证书存储NSS库不依赖于操作系统的证书库。因此处理方式与Chrome有所不同。5.1 使用acceptInsecureCerts能力这是跨浏览器标准WebDriver W3C标准中定义的能力Firefox和Chrome都支持。它指示浏览器接受不安全的证书。from selenium import webdriver from selenium.webdriver.firefox.options import Options firefox_options Options() # 方法一通过Options设置 firefox_options.accept_insecure_certs True # 方法二通过Desired Capabilities设置更标准 from selenium.webdriver.common.desired_capabilities import DesiredCapabilities caps DesiredCapabilities.FIREFOX.copy() caps[acceptInsecureCerts] True driver webdriver.Firefox(optionsfirefox_options, desired_capabilitiescaps) driver.get(https://your-site.com)和Chrome的忽略错误类似这只是一个绕过警告的开关并非真正的信任。5.2 通过Firefox配置信任特定证书这才是根治Firefox证书问题的正确方式。我们需要通过Firefox的配置文件about:config或profiles.ini来操作但更实用的方法是在Selenium启动前通过编程方式修改Firefox的证书库。核心工具certutilcertutil是Mozilla NSS工具集的一部分用于管理证书数据库。我们需要用它把证书导入到Selenium将要使用的Firefox Profile中。步骤1创建或定位Firefox Profile目录Selenium启动Firefox时可以指定一个Profile路径。from selenium.webdriver.firefox.options import Options from selenium.webdriver.firefox.firefox_profile import FirefoxProfile profile FirefoxProfile(profile_directory/path/to/your/custom/profile) # 或者让Selenium创建一个新的我们记住路径 # profile FirefoxProfile() # profile_path profile.path firefox_options Options() driver webdriver.Firefox(firefox_profileprofile, optionsfirefox_options)步骤2获取并安装certutil在Linux上通常通过libnss3-tools包安装。在Windows上可以从Mozilla或旧版Firefox安装目录中找到或者使用预编译的工具。# Ubuntu/Debian sudo apt-get install libnss3-tools # CentOS/RHEL sudo yum install nss-tools步骤3编写证书导入脚本假设你的证书文件是my_ca.crt你可以编写一个Python函数在启动浏览器前执行导入。import os import subprocess def import_cert_into_firefox_profile(cert_path, profile_path): 将证书导入指定的Firefox Profile :param cert_path: 证书文件路径 :param profile_path: Firefox Profile目录路径 # 找到certutil工具路径可能需要根据系统调整 certutil_path certutil # 假设已在PATH中 # Firefox Profile的证书数据库文件 cert_db_path os.path.join(profile_path, cert9.db) # Firefox 60 # 构建导入命令 # -A: 添加一个受信任的证书 # -n: 证书昵称 # -t: 信任属性。C,, 表示信任为CA颁发者 # -i: 输入证书文件 # -d: 证书数据库目录 cmd [ certutil_path, -A, -n, My Internal CA, # 给证书起个名字 -t, C,,, -i, cert_path, -d, sql: profile_path ] try: subprocess.run(cmd, checkTrue, capture_outputTrue, textTrue) print(f证书已成功导入到 {profile_path}) except subprocess.CalledProcessError as e: print(f证书导入失败: {e.stderr}) raise # 在创建driver前调用 profile FirefoxProfile(profile_directory./firefox_profile) import_cert_into_firefox_profile(./my_ca.crt, profile.path) driver webdriver.Firefox(firefox_profileprofile)这段代码的核心是调用certutil命令将指定证书以“受信任的根证书颁发机构”的身份添加到Firefox Profile的数据库中。这样由该CA签发的所有证书都会被Firefox信任。实操心得首次运行前确保certutil工具可用。信任属性-t的参数是关键C信任作为证书颁发机构CA。,分隔符。三个位置分别对应SSL/TLS,Email,Object Signing。C,,表示仅信任其为SSL/TLS CA。如果想完全信任可以用CT,CT,CT。这种方法非常可靠是自动化测试环境搭建的标准做法之一。你可以把这个证书导入逻辑封装成conftest.py中的fixture在测试开始前自动执行。6. 系统级与网络级根治方案对于团队协作或CI/CD环境在每台机器、每个浏览器Profile里单独配置证书太繁琐。系统级方案可以一劳永逸。6.1 将证书导入操作系统信任库这是最根本的方法。证书被操作系统信任后所有依赖系统证书库的应用程序包括Chrome、Edge、curl、wget等都会自动信任。在Linux (Ubuntu/Debian) 上# 1. 将CA证书复制到系统CA证书目录 sudo cp your-ca.crt /usr/local/share/ca-certificates/your-ca.crt # 2. 更新CA证书存储 sudo update-ca-certificates执行后系统会提示添加了1个证书。Chrome和Firefox如果配置为使用系统证书库都会生效。在Windows上手动按WinR输入certlm.msc打开“本地计算机”的证书管理控制台。展开“受信任的根证书颁发机构” - “证书”。右键“所有任务” - “导入”选择你的CA证书文件按照向导完成。在Windows上命令行适合自动化可以使用PowerShell的Import-Certificate命令但更通用的方法是用certutilWindows自带# 以管理员身份运行PowerShell certutil -addstore -f Root C:\path\to\your-ca.crt在macOS上# 1. 将证书导入钥匙串访问并始终信任 sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain your-ca.crt重要警告将证书导入系统根信任区是高风险操作。请绝对确保你导入的是你完全可控的内部CA证书而不是来自不明来源的证书。恶意CA证书可以用于中间人攻击解密你的所有HTTPS流量。6.2 处理TLS协议协商错误错误10013当遇到“内部错误状态为 10013”时这通常是客户端如Python的urllib3Selenium底层可能用到试图使用不安全的TLS协议。我们需要强制客户端使用安全的协议。在Python脚本中全局设置推荐import ssl import urllib3 # 禁用不安全的SSLv2和SSLv3启用TLSv1.2及以上 ssl._create_default_https_context ssl._create_unverified_context # 注意这会跳过验证慎用 # 更好的方式是创建自定义的安全上下文 import ssl context ssl.create_default_context(ssl.Purpose.SERVER_AUTH) context.minimum_version ssl.TLSVersion.TLSv1_2 # 设置最低TLS版本为1.2 context.check_hostname False # 如果不验证主机名如用IP访问 context.verify_mode ssl.CERT_NONE # 如果不验证证书仅用于测试环境 # 对于使用requests库的情况Selenium本身不直接使用但你的测试代码可能用 import requests from requests.adapters import HTTPAdapter from urllib3.poolmanager import PoolManager class TLSAdapter(HTTPAdapter): def init_poolmanager(self, *args, **kwargs): kwargs[ssl_context] context # 使用上面创建的安全上下文 return super().init_poolmanager(*args, **kwargs) session requests.Session() session.mount(https://, TLSAdapter())在系统级别设置Windows PowerShell错误信息中提到的[System.Net.ServicePointManager]::SecurityProtocol是.NET Framework的设置。如果你的脚本环境受此影响可以在脚本开头设置# 在Python中模拟设置影响基于.NET的组件如某些Windows API调用 import os os.environ[SSL_CERT_FILE] path/to/cert.pem # 设置证书文件可选 # 更直接的方法是确保你的Python环境使用更新的OpenSSL库根本的解决方法是升级你的Python版本和依赖库如urllib3,requests,cryptography确保它们支持并默认使用TLSv1.2。7. 与常见测试框架及CI/CD的集成解决了本地问题如何让它在团队服务器和流水线上也能稳定运行7.1 在Docker容器中运行在Docker里运行Selenium测试是CI/CD的常态。你需要确保容器内系统信任你的证书。Dockerfile示例FROM selenium/standalone-chrome:latest # 或基于任何包含Chrome的镜像 # 1. 安装工具用于导入证书 USER root RUN apt-get update apt-get install -y ca-certificates curl # 2. 将你的内部CA证书复制到镜像中 COPY your-internal-ca.crt /usr/local/share/ca-certificates/ # 3. 更新系统CA存储 RUN update-ca-certificates # 4. 可选对于Chrome也可以直接导入到Chrome的NSSDB中 # 安装libnss3-tools RUN apt-get install -y libnss3-tools # 创建一个Chrome信任证书的脚本 COPY trust_cert.sh /tmp/ RUN chmod x /tmp/trust_cert.sh /tmp/trust_cert.sh # 切换回非root用户如果基础镜像有要求 USER 1200 # 你的测试脚本和依赖安装... COPY requirements.txt . RUN pip install -r requirements.txt COPY . .trust_cert.sh脚本内容可能如下针对Chrome#!/bin/bash # 找到Chrome使用的证书库位置可能因版本而异 CERT_DB_DIR$HOME/.pki/nssdb # 如果目录不存在则创建 mkdir -p $CERT_DB_DIR # 使用certutil导入证书 certutil -d sql:$CERT_DB_DIR -A -t C,, -n Internal CA -i /usr/local/share/ca-certificates/your-internal-ca.crt7.2 在Jenkins/GitLab CI等流水线中原理与Docker类似关键在于在运行测试任务之前将证书信任步骤作为前置步骤。GitLab CI.gitlab-ci.yml示例片段test:e2e: image: python:3.9-slim before_script: - apt-get update apt-get install -y wget ca-certificates libnss3-tools unzip # 1. 安装Chrome和ChromeDriver略 # 2. 从安全的变量或文件服务器获取内部CA证书 - echo $INTERNAL_CA_CERT /usr/local/share/ca-certificates/internal-ca.crt # 3. 更新系统证书 - update-ca-certificates # 4. 为当前用户如gitlab-runner的Chrome导入证书 - mkdir -p $HOME/.pki/nssdb - certutil -d sql:$HOME/.pki/nssdb -A -t C,, -n Internal-CA -i /usr/local/share/ca-certificates/internal-ca.crt # 5. 安装Python依赖 - pip install -r requirements.txt script: - python run_selenium_tests.py这里INTERNAL_CA_CERT是一个存储在GitLab CI/CD变量中的、经过Base64编码的证书内容避免了将证书文件直接存入代码库。8. 高级场景与疑难杂症排查即使掌握了以上方法在实际复杂环境中仍可能遇到怪问题。这里记录一些“坑”和排查思路。8.1 使用mitmproxy等代理时的证书问题当你用mitmproxy拦截HTTPS流量时必须让浏览器信任mitmproxy生成的根证书。启动mitmproxy并安装其证书启动mitmproxy或mitmdump后它会生成一个CA证书。通常位于~/.mitmproxy/mitmproxy-ca-cert.cer。让Selenium信任该证书采用前面提到的系统级导入或浏览器Profile导入的方法将这个mitmproxy-ca-cert.cer证书导入为受信任的根证书。配置Selenium使用代理from selenium import webdriver from selenium.webdriver.chrome.options import Options chrome_options Options() chrome_options.add_argument(--proxy-serverhttp://localhost:8080) # mitmproxy默认端口 # 必须忽略证书错误因为mitmproxy的证书是针对每个域名动态生成的浏览器默认不信任 chrome_options.add_argument(--ignore-certificate-errors) driver webdriver.Chrome(optionschrome_options)关键点即使导入了mitmproxy的根证书你仍然需要--ignore-certificate-errors。因为mitmproxy为每个站点签发的证书其主机名可能与你访问的原始主机名不完全匹配例如使用了IP地址会导致主机名验证失败。这个参数可以绕过主机名验证。8.2 处理“SSL/TLS协议信息泄露漏洞(CVE-2016-2183)”这是一个古老的漏洞涉及使用弱加密算法3DES。现代浏览器和服务端早已禁用不安全的算法。如果你的测试环境被扫描器报出此漏洞说明环境中可能还存在支持弱算法的服务。对于测试这通常不影响Selenium自动化测试的执行。浏览器会自动协商安全的算法。这个报警更多是安全合规要求。根治方法在测试服务器上禁用不安全的加密套件。例如在Nginx配置中ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers on;然后重启Nginx服务。这样扫描器就不会再报此漏洞浏览器连接也会使用更安全的算法。8.3 证书链不完整与no required ssl certificate was sent这个错误通常意味着服务器在TLS握手时没有发送完整的证书链即缺少中间证书。浏览器无法构建从服务器证书到受信任根证书的完整路径。排查使用openssl命令检查服务器发送的证书链openssl s_client -connect your-server:443 -showcerts查看输出中包含了几个证书块。通常应该看到服务器证书和至少一个中间CA证书。解决这不是客户端Selenium能解决的问题。需要服务器管理员在Web服务器如Nginx、Apache、IIS配置中将服务器证书和中间证书合并为一个文件服务器证书在前中间证书在后并在配置中指定这个合并后的文件。Nginx示例ssl_certificate /path/to/combined_certificate.crt;IIS需要通过MMC控制台将证书链完整导入。8.4 浏览器更新或Profile损坏导致配置失效有时浏览器版本大更新或者Profile目录损坏会导致之前导入的证书失效。应对策略自动化证书导入不要依赖手动配置的Profile。将证书导入逻辑写入你的测试环境初始化脚本conftest.py的session级别fixture或pytest的pytest_configure钩子。使用独立的、版本控制的Profile目录在CI/CD中每次从干净的、预配置好的Profile目录副本开始而不是复用可能被修改的目录。日志与验证在测试启动初期添加一个简单的健康检查访问一个已知的使用内部证书的HTTPS页面。如果失败则抛出明确的错误信息提示证书信任可能失效而不是让测试在后续步骤中莫名其妙地失败。处理Selenium中的SSL/TLS证书问题本质上是一场与浏览器安全模型和网络基础设施的“谈判”。没有一种放之四海而皆准的银弹但通过理解原理、掌握从绕过、信任到根治的武器库你完全可以将这个曾经的“拦路虎”变为可控的流程环节。记住对于长期稳定的测试环境投入时间做好证书的系统级信任是回报率最高的选择它能为你节省无数排查诡异问题的时间。最后安全无小事在自动化中处理证书时务必明确环境边界切勿将测试环境的宽松安全策略带入生产。