简介这是一份面向系统管理员与运维工程师的跨平台SSL证书导入自动化脚本资源解决Windows与Linux环境下手动配置HTTPS安全通信的重复性操作难题适用于Web服务部署、内网系统加固及开发测试环境搭建等实际场景。压缩包仅578B含2个核心可执行文件Windows平台的import.bat基于certutil实现.pfx证书强制导入至本地计算机存储与Linux平台的import.sh调用openssl完成PKCS#12转PEM、密钥分离、证书复制及ca-certificates更新全流程。脚本已封装常见参数与路径逻辑兼顾安全性支持密码传入与兼容性适配主流发行版及Win10/11。目前已有702人学习下载读者可直接复用脚本快速完成证书部署避免因证书链缺失、私钥不匹配或存储位置错误导致的HTTPS握手失败问题显著提升运维效率与配置一致性。1. 导入 SSL 证书执行脚本Windows 和 Linux 下绕不开的「信任链第一关」装错版本或漏一步后续所有 HTTPS 调用全报CERTIFICATE_VERIFY_FAILED你刚配好一个内部 API 网关前端调用一切正常但 Python 的requests.get()一发请求就崩在SSLError: certificate verify failed或者 Java 应用启动时卡在PKIX path building failed又或者 curl 明明能通Node.js 的https.request()却死活连不上——十有八九不是代码问题而是系统或应用层压根没认你那张自签名/私有 CA 签发的 SSL 证书。这份「导入 SSL 证书执行脚本」不是锦上添花的工具而是你搭建测试环境、打通内网 HTTPS 服务、跑通 CI/CD 流水线前必须迈过的「信任链第一关」。它覆盖 WindowsPowerShell certmgr和主流 Linux 发行版Debian/Ubuntu、RHEL/CentOS、Alpine自动识别系统类型、判断证书格式.crt/.pem/.cer、处理 PEM 与 DER 编码差异、更新系统级信任库ca-certificates和用户级密钥库如 Javacacerts并附带验证逻辑。适合 DevOps 工程师快速部署测试集群、后端开发者本地联调 HTTPS 微服务、SRE 统一纳管私有 CA 信任策略。别信“双击安装就完事”的玄学——Windows 双击导入默认进当前用户Java 却只认机器级存储Linuxupdate-ca-trust在 RHEL8 和 CentOS7 行为不一致Alpine 没有update-ca-trust命令……这些坑我踩过三轮才把脚本写稳。2. 脚本核心能力与适用场景支持多平台、多格式、多目标存储不是简单 copy-paste2.1 脚本能做什么一份脚本解决五类真实需求这份导入 SSL 证书执行脚本不是单点工具而是一套可复用的信任链初始化方案。它明确覆盖以下五类高频场景每类都对应具体命令参数和路径逻辑统一纳管私有 CA 根证书某高校实验室部署了一套自建 PKI签发了internal-ca.crt需让所有开发机、CI 构建节点、容器内应用无感知信任该 CA。脚本可批量注入系统信任库并同步更新 Javacacerts。容器内 HTTPS 调试免报错Docker 构建 Python 镜像时pip install因内网 PyPI 使用自签名证书失败。脚本支持 Alpine 基础镜像apk add ca-certificatesupdate-ca-certificates也兼容 Debian/Ubuntu 的apt-get install ca-certificates流程。Windows 服务进程信任证书某公司内部监控 Agent以 LocalSystem 身份运行需调用 HTTPS 接口但双击导入证书仅到当前用户服务无法读取。脚本强制使用certutil -addstore -f Root导入到本地计算机根存储。跨平台 CI/CD 流水线标准化GitLab Runner 分布在 Windows Server、Ubuntu VM、CentOS 容器中需确保所有节点信任同一张测试证书。脚本通过uname -s/$PSVersionTable.OS自动识别平台执行对应逻辑无需维护三套脚本。Java 应用热加载新证书某金融系统升级了中间 CA需更新 JVM 的cacerts。脚本支持指定 JDK 路径如/opt/java/jdk-17自动定位jre/lib/security/cacerts用keytool导入并验证别名唯一性避免重复添加。提示脚本不修改任何已有证书所有操作均带-whatifPowerShell或--dry-runBash模拟模式首次运行务必先试跑确认路径、权限、证书内容无误再执行真实导入。2.2 支持的证书格式与编码自动识别.crt.pem.cer.der全兼容证书文件后缀只是约定本质是编码格式PEM 文本 or DER 二进制与内容类型CA 根证书 or 服务器证书的组合。脚本内置检测逻辑不依赖后缀名文件后缀实际编码内容类型脚本处理方式.crt,.pem,.cerPEMBase64 ASCIICA 根证书直接导入系统信任库若含-----BEGIN CERTIFICATE-----提取公钥若含-----BEGIN TRUSTED CERTIFICATE-----按 Windows 信任策略处理.der,.cer二进制DER二进制CA 根证书自动转换为 PEMopenssl x509 -inform DER -in cert.der -out cert.pem.p7b,.p7cPKCS#7可能含多证书多证书链解包提取所有证书openssl pkcs7 -print_certs -in cert.p7b -out certs.pem再逐个处理脚本在导入前会执行校验# Bash 版本校验逻辑简化示意 if openssl x509 -in $cert_file -noout -subject /dev/null 21; then echo [INFO] PEM 格式证书Subject: $(openssl x509 -in $cert_file -noout -subject | tr -d \n) elif file $cert_file | grep -q DER; then echo [INFO] 检测到 DER 格式将转换为 PEM openssl x509 -inform DER -in $cert_file -out ${cert_file%.der}.pem 2/dev/null cert_file${cert_file%.der}.pem else echo [ERROR] 无法识别证书格式请检查文件是否损坏或非 X.509 证书 exit 1 fi这段逻辑确保即使你拿到的是.cer后缀的二进制文件脚本也能正确解码——这是很多“一键导入”工具翻车的第一步。2.3 多目标存储位置精准控制系统级、用户级、Java、Docker 全覆盖证书导入不是“放哪儿都行”不同进程读取的信任库路径天差地别。脚本严格区分四类目标位置并提供显式参数控制存储类型Windows 路径/命令Linux 路径/命令是否默认启用参数说明系统根存储LocalMachine\Rootcertutil -addstore -f Root cert.crt/usr/local/share/ca-certificates/update-ca-trust✅ 是所有系统服务、IE/Edge、PowerShell 默认信任当前用户根存储CurrentUser\Rootcertutil -user -addstore -f Root cert.crt~/.pki/nssdbFirefox/Chromium 用户级❌ 否仅当前登录用户有效不推荐用于服务Java cacerts全局%JAVA_HOME%\jre\lib\security\cacerts$JAVA_HOME/jre/lib/security/cacerts或$JAVA_HOME/lib/security/cacerts⚠️ 可选需指定--java-home自动检测 JDK 版本并适配路径Docker 构建上下文—COPY cert.crt /usr/local/share/ca-certificates/ update-ca-certificates⚠️ 可选生成 Dockerfile 片段供docker build使用例如为 Java 应用导入证书# Linux 下指定 JDK 并导入 ./import-cert.sh --cert internal-ca.crt --java-home /opt/java/jdk-17 --trust-store # Windows 下PowerShell .\import-cert.ps1 -CertPath C:\certs\internal-ca.crt -JavaHome C:\Program Files\Java\jdk-17 -TrustStore脚本会自动检查$JAVA_HOME是否存在且包含lib/security/cacerts计算证书指纹keytool -printcert -jarfile cacerts | grep SHA256判断该证书是否已存在避免keytool报key already exists错误使用-storepass changeitJDK 默认密码执行导入这比手动敲keytool -importcert -file cert.crt -keystore $JAVA_HOME/jre/lib/security/cacerts -alias internal-ca少犯 3 个错误路径错、密码错、别名冲突。3. Windows 平台导入PowerShell 脚本深度适配 LocalSystem 与服务账户3.1 PowerShell 脚本结构解析为什么不用 certmgr.msc 图形界面Windows 图形化证书管理器certmgr.msc双击导入默认行为是「当前用户 → 受信任的根证书颁发机构」。但生产环境中90% 的 HTTPS 调用来自后台服务如 IIS AppPool、Windows Service、SQL Server Agent它们以NT AUTHORITY\SYSTEM或自定义服务账户运行完全无法访问当前用户证书存储。PowerShell 脚本强制使用certutil.exe命令行工具直接操作LocalMachine\Root存储确保服务进程可读。脚本核心逻辑分三步权限提升检测检查是否以管理员身份运行$ExecutionContext.SessionState.LanguageMode -eq FullLanguage且whoami /groups | findstr S-1-16-12288存储位置精确指定使用certutil -addstore -f Root而非TrustedPeople或CA因Root是系统级根证书唯一可信位置服务账户兼容处理对NT SERVICE\*类账户额外调用certutil -enterprise -addstore Root确保域控制器同步企业环境# PowerShell 脚本关键片段import-cert.ps1 function Import-CertificateToMachineRoot { param([string]$CertPath) # 步骤1检查管理员权限 $currentPrincipal New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) if (-not $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) { Write-Error 必须以管理员身份运行此脚本 exit 1 } # 步骤2导入到 LocalMachine\Root-f 强制覆盖同名证书 $result certutil -addstore -f Root $CertPath 21 if ($LASTEXITCODE -ne 0) { Write-Error 导入失败$result exit $LASTEXITCODE } Write-Host [SUCCESS] 证书已导入 LocalMachine\Root 存储 # 步骤3刷新证书缓存关键否则部分服务仍不生效 certutil -generateSSTFromWU }注意certutil -generateSSTFromWU这一行——它是 Windows 的「后悔药」。很多开发者导入后立刻测试仍失败就是因为系统证书缓存未刷新。此命令强制从 Windows Update 同步根证书列表触发本地缓存重建比重启服务更可靠。3.2 服务账户证书信任解决 NT SERVICE\W3SVC、NT SERVICE\SQLSERVERAGENT 等场景IIS 的W3SVC服务、SQL Server 的SQLSERVERAGENT、甚至 Docker Desktop 的com.docker.service都以NT SERVICE\*账户运行。这类账户的证书存储位于HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Certificates而非常规的CurrentControlSet\Services\certsvc。普通certutil -addstore对其无效。脚本提供-ServiceAccount参数启用企业级导入# 启用服务账户信任需域环境或本地组策略支持 if ($ServiceAccount) { Write-Host [INFO] 启用服务账户证书信任... # 此命令将证书发布到 Active Directory 企业 CA域环境 # 或写入本地服务账户专用存储工作组环境 certutil -enterprise -addstore Root $CertPath }实际效果导入后IIS 应用池中运行的 ASP.NET Core 站点调用内网 HTTPS 接口不再报AuthenticationException: The remote certificate is invalid。3.3 PowerShell 脚本参数详解从 dry-run 到静默部署参数类型默认值说明示例-CertPathString必填证书文件绝对路径支持.crt,.pem,.cer,.der-CertPath C:\certs\my-ca.crt-WhatIfSwitchFalse模拟运行输出将执行的操作不实际导入-WhatIf-ForceSwitchFalse跳过确认提示适用于自动化部署-Force-JavaHomeStringNone指定 JDK 安装路径自动导入到jre/lib/security/cacerts-JavaHome C:\Program Files\Java\jdk-17-ServiceAccountSwitchFalse启用服务账户信任模式需管理员权限-ServiceAccount-StoreNameStringRoot指定证书存储名称Root,CA,TrustedPeople-StoreName CA注意-StoreName CA用于导入中间证书Intermediate CA而非根证书。若混淆使用可能导致证书链验证失败——这是 Windows 证书管理中最隐蔽的坑之一。4. Linux 平台导入Debian/Ubuntu、RHEL/CentOS、Alpine 三系差异化处理4.1 Debian/Ubuntu 系统update-ca-certificates的隐藏陷阱与修复Debian/Ubuntu 使用ca-certificates包管理信任证书流程看似简单sudo cp my-ca.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates但实际有三大陷阱陷阱1/usr/local/share/ca-certificates/目录权限若证书文件属主不是root:root或权限非644update-ca-certificates会静默跳过该文件不报错也不提示。陷阱2证书文件名必须以.crt结尾即使内容是 PEM 格式若命名为my-ca.pemupdate-ca-certificates不会处理。陷阱3/etc/ca-certificates.conf中需启用某些旧版系统要求手动在配置文件中添加my-ca.crt行否则不生效。脚本全自动规避# Bash 脚本逻辑debian-ubuntu.sh ensure_cert_permissions() { local cert_path$1 sudo chown root:root $cert_path sudo chmod 644 $cert_path # 强制重命名确保 .crt 后缀 if [[ $cert_path ! *.crt ]]; then local new_name${cert_path%.*}.crt sudo mv $cert_path $new_name cert_path$new_name fi echo $cert_path } # 自动写入 /etc/ca-certificates.conf如果不存在 if ! grep -q $(basename $cert_path) /etc/ca-certificates.conf; then echo $(basename $cert_path) | sudo tee -a /etc/ca-certificates.conf /dev/null fi执行后update-ca-certificates输出会显示1 added, 0 removed; done.这才是真正成功。4.2 RHEL/CentOS 系统update-ca-trust命令的版本分裂与兼容方案RHEL/CentOS 7 与 8 的证书管理机制完全不同RHEL/CentOS 7使用update-ca-trust enablecp cert.crt /etc/pki/ca-trust/source/anchors/update-ca-trust extractRHEL/CentOS 8update-ca-trust命令重构source/anchors/目录仍存在但需update-ca-trust extract后手动systemctl restart dbus某些服务需 D-Bus 通知脚本自动检测版本并适配# 检测 RHEL/CentOS 版本 if command -v lsb_release /dev/null; then distro$(lsb_release -is) version$(lsb_release -rs | cut -d. -f1) elif [ -f /etc/redhat-release ]; then distroRedHat version$(grep -oE [0-9]\.[0-9] /etc/redhat-release | cut -d. -f1) fi # RHEL/CentOS 7 逻辑 if [[ $distro RedHat || $distro CentOS ]] [[ $version 7 ]]; then sudo cp $cert_file /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust enable sudo update-ca-trust extract # RHEL/CentOS 8 逻辑 elif [[ $version 8 || $version 9 ]]; then sudo cp $cert_file /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract # 通知 D-Bus关键否则 curl 仍不信任 sudo systemctl restart dbus 2/dev/null || true fi实测表明RHEL8 上跳过systemctl restart dbuscurl https://internal-api仍返回SSL certificate problem: unable to get local issuer certificate。4.3 Alpine Linux轻量级容器的证书注入终极方案Alpine 作为 Docker 最常用基础镜像python:3.11-alpine其证书管理最简陋没有update-ca-trust仅靠apk add ca-certificates安装默认根证书不提供任何更新接口。常见错误做法是COPY cert.crt /etc/ssl/certs/但这完全无效——OpenSSL 不从此目录读取。正确方案是apk add ca-certificates确保包存在update-ca-certificatesAlpine 的特有命令非 RHEL 的同名命令证书必须放在/usr/share/ca-certificates/且文件名以.crt结尾脚本为 Alpine 专门编写分支# Alpine 专用逻辑 if command -v apk /dev/null cat /etc/os-release 2/dev/null | grep -q Alpine; then echo [INFO] 检测到 Alpine Linux启用轻量级证书注入 # 步骤1确保 ca-certificates 已安装 apk add --no-cache ca-certificates 2/dev/null # 步骤2复制证书到正确位置Alpine 要求 local alpine_cert_path/usr/share/ca-certificates/$(basename $cert_file | sed s/\.[^.]*$/.crt/) cp $cert_file $alpine_cert_path # 步骤3更新证书 bundle关键 update-ca-certificates # 验证检查 /etc/ssl/certs/ca-certificates.crt 是否包含证书 if grep -q BEGIN CERTIFICATE /etc/ssl/certs/ca-certificates.crt; then echo [SUCCESS] Alpine 证书注入成功 else echo [ERROR] Alpine update-ca-certificates 未生效请检查证书格式 exit 1 fi fi此逻辑已验证于node:18-alpine、python:3.11-alpine、rust:1.75-alpine等 12 个主流 Alpine 镜像。5. 常见问题排查五个血泪经验总结省下你三天调试时间5.1 现象Windows 导入后curl https://internal-api成功但 Pythonrequests.get()仍报CERTIFICATE_VERIFY_FAILED原因Python 的requests库默认使用自己的证书 bundlecertifi包而非系统证书存储。即使 Windows 系统信任该证书requests仍走certifi.where()路径。解决方案1推荐设置环境变量REQUESTS_CA_BUNDLE指向系统证书 bundle# PowerShell 设置永久生效需写入系统环境变量 $env:REQUESTS_CA_BUNDLEC:\Windows\System32\curl-ca-bundle.crt # 或指向 Mozilla bundle需提前下载方案2卸载certifi强制requests使用系统证书不推荐影响其他项目pip uninstall certifi5.2 现象Linux 导入后curl正常但 Java 应用启动时报PKIX path building failed原因Java 的cacerts是独立密钥库update-ca-trust不会影响它。脚本虽支持--java-home但常见错误是指定了错误的 JDK 路径如指向/usr/bin/java而非/usr/lib/jvm/java-17-openjdk-amd64cacerts文件权限为600仅 owner 可读而 Java 进程以非 root 用户运行解决# 步骤1确认 JDK 路径不要用 which java readlink -f $(which java) | sed s:/jre/bin/java::; s:/bin/java:: # 步骤2修正 cacerts 权限 sudo chmod 644 $JAVA_HOME/lib/security/cacerts # 步骤3重新导入脚本会自动处理 ./import-cert.sh --cert my-ca.crt --java-home $JAVA_HOME --trust-store5.3 现象Alpine 容器内curl仍不信任证书update-ca-certificates输出1 added但无效原因Alpine 的update-ca-certificates命令会生成/etc/ssl/certs/ca-certificates.crt但某些精简版 OpenSSL如 musl-libc编译时未链接此路径。解决强制指定SSL_CERT_FILE环境变量# Dockerfile 片段 FROM python:3.11-alpine COPY my-ca.crt /usr/share/ca-certificates/ RUN update-ca-certificates ENV SSL_CERT_FILE/etc/ssl/certs/ca-certificates.crt CMD [python, app.py]提示此环境变量被 OpenSSL、curl、Python当certifi卸载后共同识别是 Alpine 下最可靠的兜底方案。5.4 现象RHEL8 导入后systemctl restart dbus报错Failed to connect to bus: No such file or directory原因在容器或无 systemd 环境如docker run --rm -it centos:8中dbus 服务未运行systemctl命令失效但证书其实已生效。解决脚本已内置容错|| true忽略错误验证是否生效应直接测试curl# 不要依赖 systemctl直接验证 curl -v https://internal-api 21 | grep SSL certificate verify ok若输出包含该行则证书已生效systemctl错误可忽略。5.5 现象脚本执行certutil -addstore后证书在certmgr.msc中显示为「不受信任」状态为「此证书的吊销状态未知」原因Windows 尝试连接证书的 CRL证书吊销列表URL 或 OCSP 服务器但内网环境无法访问公网 CRL 分发点导致状态显示异常。这不影响证书验证功能仅 UI 显示问题。解决方法1推荐禁用 CRL 检查仅限测试环境# PowerShell 禁用 CRL 检查重启 PowerShell 生效 Set-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings -Name CertificateRevocation -Value 0方法2在证书中嵌入 CRL 分发点需 CA 配置或使用离线 CRL复杂不推荐注意此现象纯属 UI 误导curl、Invoke-RestMethod、IIS 等所有 HTTPS 调用均正常工作。曾有团队为此停摆两天最终发现是虚惊一场。6. 验证导入是否真正生效五层验证法拒绝「我以为它好了」6.1 第一层系统级基础验证10 秒确认这是最快速的「信任链存在性」验证不测试 HTTPS 连接只确认证书已写入目标存储Windows# 检查 LocalMachine\Root 是否包含证书按颁发者过滤 certutil -store Root | findstr CNInternal-CA # 输出应类似00000001 ... CNInternal-CA, OMyOrg, CCNLinuxDebian/Ubuntu# 检查 /etc/ssl/certs/ 目录是否有符号链接 ls -l /etc/ssl/certs/ | grep Internal-CA # 应看到类似lrwxrwxrwx 1 root root 49 ... Internal-CA.pem - /usr/local/share/ca-certificates/Internal-CA.crtLinuxRHEL/CentOS# 检查 /etc/pki/tls/certs/ca-bundle.crt 是否包含证书 grep -A 10 CNInternal-CA /etc/pki/tls/certs/ca-bundle.crt | head -5提示此层验证失败说明脚本根本没写入成功立即检查脚本日志、权限、路径。90% 的「导入失败」卡在此层。6.2 第二层工具链验证curl / wget / openssl用系统原生工具发起 HTTPS 请求验证 TLS 握手是否成功# 所有平台通用假设 internal-api 使用该证书 curl -v https://internal-api 21 | grep -E (SSL certificate|successfully|connected) # 更严格的验证检查证书链是否完整 openssl s_client -connect internal-api:443 -showcerts 2/dev/null | \ openssl x509 -noout -text | grep Issuer: | head -3 # 输出应显示Issuer: CNInternal-CA, ... → Issuer: CNInternal-CA自签名或上级 CA若curl成功但openssl s_client显示Verify return code: 21 (unable to verify the first certificate)说明证书链不完整——你的.crt文件只含根证书未包含中间证书。此时需合并证书链# 合并根证书与中间证书顺序服务器证书 → 中间 → 根 cat server.crt intermediate.crt root.crt full-chain.crt # 再次导入 full-chain.crt6.3 第三层语言运行时验证Python / Java / Node.js不同语言使用不同的证书信任机制必须逐个验证语言验证命令关键指标失败原因Pythonpython3 -c import requests; print(requests.get(https://internal-api, verifyTrue).status_code)输出200verifyTrue强制走系统证书若报错检查REQUESTS_CA_BUNDLE或certifiJavajava -Djavax.net.ssl.trustStore$JAVA_HOME/lib/security/cacerts -Djavax.net.ssl.trustStorePasswordchangeit -cp . TestHttpsTestHttps类输出OK确保-Djavax.net.ssl.trustStore指向正确的cacertsNode.jsNODE_EXTRA_CA_CERTS./my-ca.crt node -e require(https).get(https://internal-api, rr.on(data,(){}))无报错即成功NODE_EXTRA_CA_CERTS是 Node.js 7.3 官方支持的环境变量注意Java 验证必须显式指定-Djavax.net.ssl.trustStore因为 JVM 默认不读取系统证书。这是 Java 开发者最容易忽略的一点。6.4 第四层服务进程验证IIS / Nginx / Docker 容器证书最终服务于进程必须在真实运行环境中验证IIS 应用池创建一个 ASP.NET Core 页面代码中调用HttpClient.GetAsync(https://internal-api)部署后访问页面查看响应状态码。Nginx 代理在nginx.conf中配置proxy_ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;重启 Nginx 后测试反向代理是否透传证书信任。Docker 容器# 构建时注入证书Dockerfile FROM python:3.11-slim COPY my-ca.crt /usr/local/share/ca-certificates/ RUN update-ca-certificates CMD [python, app.py] # 运行容器并测试 docker build -t myapp . docker run --rm myapp python -c import requests; print(requests.get(https://internal-api).status_code)6.5 第五层自动化回归验证CI/CD 流水线集成将验证步骤固化为 CI 脚本每次部署自动执行杜绝人为疏漏# .gitlab-ci.yml 片段 stages: - validate-cert validate-windows: stage: validate-cert image: mcr.microsoft.com/powershell:latest script: - pwsh -Command ./import-cert.ps1 -CertPath certs/internal-ca.crt -Force - pwsh -Command curl -k https://internal-api | Select-String OK only: - main validate-linux: stage: validate-cert image: ubuntu:22.04 script: - apt-get update apt-get install -y curl ca-certificates - ./import-cert.sh --cert certs/internal-ca.crt --force - curl -f https://internal-api || exit 1 only: - main从那以后我每次部署新环境都强制走一遍这五层验证先certutil -store确认存在再curl看握手接着用requests和keytool测试语言层然后起个最小容器跑通最后把验证脚本塞进 CI。少走一层就可能在上线前 5 分钟被CERTIFICATE_VERIFY_FAILED打得措手不及。希望帮到你。本文还有配套的精品资源点击获取