TLS Certificate Checker

检查网站的TLS/SSL证书：主题/颁发者、有效期、SAN、证书链完整性以及常见的HTTPS配置错误。可选择跟随重定向，验证最终目的地是否使用有效的HTTPS证书。支持导出JSON/PDF报告。

Loading…

关于 TLS证书检查器

当HTTPS出现问题时，用户会看到可怕的警告，机器人也会停止信任您的网站。本工具获取URL，可选择跟随重定向，并检查保护最终HTTPS端点的TLS证书。它帮助您发现即将过期的证书、不完整的证书链、主机名/SAN不匹配以及其他常见导致浏览器错误和SEO/可用性问题的隐患。

功能特点

  • 检查证书主题和颁发者（为谁颁发，由谁颁发）。
  • 验证日期：生效前/过期后，并对即将过期发出警告。
  • 检查SAN（主题备用名称）和主机名覆盖范围（www与根域名、子域名）。
  • 检测证书链问题（缺少中间证书/证书链不完整）。
  • 可选跟随重定向，以验证最终URL的HTTPS强制实施情况。
  • 识别常见的HTTPS陷阱（错误的主机、错误的证书、混合重定向流程）。
  • 便于复制的结果和发现，用于事件工单。
  • 下载JSON和PDF报告，用于文档记录和回归检查。

🧭 使用方法 for tls-certificate-checker

1

粘贴要测试的URL

输入目标URL。您可以粘贴 https://example.com，甚至是 http://example.com（如果您想确认它最终会升级到HTTPS）。

2

启用“跟随重定向”以模拟真实行为

如果您想验证用户和爬虫实际到达的目的地（http→https，非www→www），请保持启用“跟随重定向”。

3

运行检查并查看摘要

检查关键项目：有效期、主机名/SAN匹配以及证书链是否完整。

4

检查发现的问题并修复根本原因

如果您看到警告（即将过期、不匹配、证书链不完整），请在TLS终止层（CDN、反向代理、负载均衡器或Web服务器）修复它们。

5

导出JSON/PDF用于跟踪

下载报告以附加到运维/SEO工单，或保留前后快照。

技术规格

输入与操作

本工具检查URL并检查解析后的HTTPS端点的TLS证书。

能力详情
支持的URL形式HTTP或HTTPS URL（可启用重定向跟随）。
重定向处理可选；启用后，将跟随至配置的最大重定向次数。
TLS重点检查证书属性及常见配置错误。

默认值与限制

获取与安全默认值已调整，以确保行为可预测。

设置值
跟随重定向已启用
最大重定向次数10
超时15000 毫秒
用户代理Encode64Bot/1.0 (+https://encode64.com)
私有网络不允许

检查内容

检查围绕生产环境中最常见的故障设计：过期、主机名不匹配（SAN覆盖范围）和链完整性。跟随重定向有助于捕获仅在最终规范主机上HTTPS有效的情况。

有效的证书是强安全的必要条件，但非充分条件。请将此与HSTS和安全头审计结合使用，以实现强化部署。

命令行

使用OpenSSL和curl从您自己的终端确认证书详情，并与工具报告的内容进行比较。

macOS / Linux

显示主机的证书链（SNI）

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

适用于检查呈现的叶证书和中间链。

快速提取到期日期

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

打印notBefore / notAfter。

列出SAN

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

显示证书覆盖的主机名。

验证HTTP重定向至HTTPS

curl -I http://example.com

检查Location头及最终方案。

跟随重定向并显示最终URL

curl -IL http://example.com | sed -n '1,120p'

帮助检测重定向链和非规范端点。

在虚拟主机服务器/CDN上使用openssl s_client时，务必使用-servername参数。没有SNI，可能会获取到错误的证书。

使用场景

防止证书过期导致服务中断

识别即将到期的证书，以便在用户和机器人遇到浏览器错误之前完成续期。

  • 每周证书健康检查
  • DNS或CDN变更后审计域名

修复不完整的证书链问题

检测缺失的中间证书（常见于自定义服务器配置），这些问题会导致旧客户端和某些爬虫程序无法正常工作。

  • Nginx/Apache链包配置错误
  • 负载均衡器缺少中间证书

调试主机名/SAN不匹配问题（www与根域名）

确认证书覆盖用户访问的确切主机，包括www/非www版本和子域名。

  • 根域名正常但www版本异常
  • API子域名未包含在SAN列表中

通过重定向验证HTTPS强制实施

确保HTTP URL重定向到具有有效证书的规范HTTPS端点。

  • http→https使用301重定向
  • 非www→www规范化

❓ Frequently Asked Questions

❓为什么即使启用了HTTPS，浏览器仍可能显示“证书不受信任”？

常见原因包括：证书已过期、证书链不完整（缺少中间证书）、主机名不匹配（SAN未包含该主机），或由于SNI/虚拟主机配置错误而提供了错误的证书。

❓什么是SAN？为什么它们很重要？

SAN（主题备用名称）是证书有效的域名列表。如果您的网站可以通过example.com和www.example.com访问，证书应同时覆盖这两个域名（或者您应一致地重定向到已覆盖的主机）。

❓HTTP重定向到HTTPS可以吗？

可以——这是推荐的做法。只需确保最终的HTTPS目标提供有效的证书，并且重定向链简短且一致（规范重定向建议使用301）。

❓此工具会检查TLS版本/密码套件吗？

本工具专注于证书检查和常见配置错误。如需进行协议/密码加固（TLS 1.2/1.3、弱密码），请使用专用的TLS配置扫描工具。

❓叶子证书、中间证书和根证书有什么区别？

叶子证书是您网站的证书。中间证书将其链接到受信任的根证书颁发机构（CA）。浏览器信任根证书，因此缺少中间证书可能导致无法建立有效的信任链。

Pro Tips

Best Practice

尽早续订证书，并尽可能自动化续订流程（使用ACME协议）。

Best Practice

确保证书中的SAN（主题备用名称）涵盖所有对外提供服务的公共主机名（如www、主域名、API子域名），或通过重定向强制使用单一规范主机名。

Best Practice

始终提供完整的证书链（叶证书+中间证书）。许多故障源于迁移后证书链捆绑不完整。

Best Practice

若启用重定向，请保持最简：单次跳转至规范的https URL最为理想。

Best Practice

将有效的TLS与HSTS及安全标头结合使用，以增强实际环境中的防护能力。

Additional Resources

OpenSSL s_client 文档
Documentation
RFC 5280：互联网X.509公钥基础设施证书和CRL配置文件
Documentation
Let's Encrypt：证书基础知识
Documentation

Other Tools

TLS证书检查器 — 检查SSL证书有效性、SAN和证书链 | Encode64