当前位置: 首页 > news >正文

Selenium自动化测试中SSL/TLS证书问题的全面解决方案

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-2183(Sweet32)这种涉及弱加密算法的漏洞,即使证书本身有效,浏览器也可能出于安全考虑而拒绝连接。安全扫描工具经常会把使用老旧协议或算法的服务标记为存在此漏洞。

2.4 中间人代理证书的信任问题

在自动化测试中,我们有时会使用像mitmproxy这样的中间人代理来拦截和修改网络请求,以便进行性能测试、模拟异常或验证数据。这就需要你在浏览器或系统中安装mitmproxy的根证书。如果证书安装不正确、没有导入到浏览器信任的证书存储区,或者Selenium启动的浏览器实例使用了独立的用户数据目录而没有继承系统的证书信任,那么同样会导致证书错误。

3. 解决方案全景:从临时绕过到根治管理

面对证书问题,我们有不同层次的应对策略,从快速但粗糙的“绕过”,到稳定但复杂的“信任”,再到一劳永逸的“根治”。选择哪种方案,取决于你的测试场景、安全要求和维护成本。

方案选择速查表

方案类别典型方法优点缺点适用场景
临时绕过--ignore-certificate-errors
acceptInsecureCertsCapability
配置简单,快速解决问题不安全,可能影响页面功能,浏览器控制台会有错误临时测试、爬取公开数据(不推荐用于严肃测试)
主动信任--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(options=chrome_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(options=chrome_options) driver.get("https://your-secure-site.com")

注意:这个方法非常精准且安全,但前提是你能拿到证书的公钥,并且该证书相对固定。对于使用Let‘s Encrypt等自动续签且每次续签公钥可能变化的证书,就不太适用。

4.3 终极方案:将证书导入Chrome信任库

这是最彻底的方法,让浏览器从心底里信任这个证书,就像信任Google、Apple的证书一样。

步骤1:准备证书文件确保你拥有证书的.crt.pem文件。如果是自签名证书,这就是你生成的那个文件;如果是内部CA,你需要其根证书。

步骤2:手动导入(一次性的)

  1. 打开Chrome,访问chrome://settings/certificates
  2. 点击“授权中心”标签页。
  3. 点击“导入”,选择你的证书文件,按照向导完成导入,确保勾选“信任此证书以标识网站”。

步骤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-directory=Default') driver = webdriver.Chrome(options=chrome_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(options=firefox_options, desired_capabilities=caps) 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_profile=profile, options=firefox_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, check=True, capture_output=True, text=True) 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_profile=profile)

这段代码的核心是调用certutil命令,将指定证书以“受信任的根证书颁发机构”的身份添加到Firefox Profile的数据库中。这样,由该CA签发的所有证书都会被Firefox信任。

实操心得

  • 首次运行前,确保certutil工具可用。
  • 信任属性-t的参数是关键:
    • C:信任作为证书颁发机构(CA)。
    • ,:分隔符。
    • 三个位置分别对应SSL/TLS,Email,Object SigningC,,表示仅信任其为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上(手动):

  1. Win+R,输入certlm.msc,打开“本地计算机”的证书管理控制台。
  2. 展开“受信任的根证书颁发机构” -> “证书”。
  3. 右键“所有任务” -> “导入”,选择你的CA证书文件,按照向导完成。

在Windows上(命令行,适合自动化):可以使用PowerShell的Import-Certificate命令,但更通用的方法是用certutil(Windows自带):

# 以管理员身份运行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的urllib3,Selenium底层可能用到)试图使用不安全的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.crt

7.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生成的根证书。

  1. 启动mitmproxy并安装其证书:启动mitmproxymitmdump后,它会生成一个CA证书。通常位于~/.mitmproxy/mitmproxy-ca-cert.cer
  2. 让Selenium信任该证书:采用前面提到的系统级导入浏览器Profile导入的方法,将这个mitmproxy-ca-cert.cer证书导入为受信任的根证书。
  3. 配置Selenium使用代理
    from selenium import webdriver from selenium.webdriver.chrome.options import Options chrome_options = Options() chrome_options.add_argument('--proxy-server=http://localhost:8080') # mitmproxy默认端口 # 必须忽略证书错误,因为mitmproxy的证书是针对每个域名动态生成的,浏览器默认不信任 chrome_options.add_argument('--ignore-certificate-errors') driver = webdriver.Chrome(options=chrome_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目录损坏,会导致之前导入的证书失效。

  • 应对策略
    1. 自动化证书导入:不要依赖手动配置的Profile。将证书导入逻辑写入你的测试环境初始化脚本(conftest.pysession级别fixturepytestpytest_configure钩子)。
    2. 使用独立的、版本控制的Profile目录:在CI/CD中,每次从干净的、预配置好的Profile目录副本开始,而不是复用可能被修改的目录。
    3. 日志与验证:在测试启动初期,添加一个简单的健康检查,访问一个已知的使用内部证书的HTTPS页面。如果失败,则抛出明确的错误信息,提示证书信任可能失效,而不是让测试在后续步骤中莫名其妙地失败。

处理Selenium中的SSL/TLS证书问题,本质上是一场与浏览器安全模型和网络基础设施的“谈判”。没有一种放之四海而皆准的银弹,但通过理解原理、掌握从绕过、信任到根治的武器库,你完全可以将这个曾经的“拦路虎”变为可控的流程环节。记住,对于长期稳定的测试环境,投入时间做好证书的系统级信任,是回报率最高的选择,它能为你节省无数排查诡异问题的时间。最后,安全无小事,在自动化中处理证书时,务必明确环境边界,切勿将测试环境的宽松安全策略带入生产。

http://www.jsqmd.com/news/1111811/

相关文章:

  • Java毕业设计-基于 SpringBoot 技术的在线教育平台的设计与实现 基于 SpringBoot 的免费课程资源在线教育平台(源码+LW+部署文档+全bao+远程调试+代码讲解等)
  • Grok 4如何统一车载AI与军用JADC2系统
  • VC6下可直接编译运行的MFC队列演示程序(含完整界面资源与源码)
  • QtScrcpy+Selenium+ADB构建安卓混合应用自动化测试框架
  • Botan库实现格式保留加密:原理、代码与数据库集成实战
  • 基于AES算法的图像加密原理与Matlab实现详解
  • 《唤醒你的AI同事:WorkBuddy从零上手》033:数据分析案例
  • OCR(三)windows 环境基于c++的 paddle ocr 编译【CPU版本】
  • AMD Ryzen终极调试指南:5步掌握SMUDebugTool硬件级控制
  • Selenium自动化测试进程清理:钩子程序解决僵尸进程问题
  • Three.js房屋GLB模型:视角驱动边缘透明+自发光渲染方案
  • Adobe-GenP 3.0:终极指南教你3分钟解锁Adobe全套设计软件
  • 写期刊小论文用什么 AI 辅助工具?避坑虚假引用工具完整清单
  • 开源威胁情报库实战指南:从数据解析到自动化集成
  • DAPO:面向真实业务的去中心化自适应策略优化范式
  • Frida动态逆向分析淘特App签名机制:从Hook定位到脚本实战
  • Home Assistant HTTPS配置:Let‘s Encrypt插件与GoDaddy API限制实战解析
  • FiveM服务器可直接部署的加载页资源包,带动态CSS动画、Orbitron字体族与背景音效
  • OpenSSL AES-CBC加密解密C语言实现详解与实战避坑指南
  • AI驱动接口自动化:智能用例生成、执行与报告实战
  • Selenium WebDriver连接Edge浏览器调试端口失败问题全解析与解决方案
  • 如何5分钟搭建现代化企业级管理平台:基于FastAPI+Vue3的完整解决方案
  • 基于Rust构建高性能文件加密工具:从AES-256-GCM到命令行实现
  • Python实现HMAC-SHA256 API签名验证:从原理到工程实践
  • Noto Emoji字体渲染技术深度解析:CBDT与COLRv1架构对比
  • IIS 10 HTTPS SSL/TLS安全通道创建失败深度排查指南
  • Python+Playwright自动化测试框架搭建:从零到实战
  • 机器学习卡通化:从原理到端侧落地的全流程实践
  • Appium Inspector连接失败?5个Desired Capabilities配置坑与排障指南
  • CS2200-CP与PIC18F86J15构建高精度计时系统