sslscan 连不上常见因目标未开443端口或未启用tls；其仅探测指定端口的密码套件协商结果，不验证证书链、ocsp装订或安全性，需配合openssl或testssl.sh深入检测。
sslscan 命令连不上目标，提示 “Connection refused” 或超时
常见原因是目标没开 443 端口，或 Web 服务没启用 TLS（比如只监听 HTTP）。sslscan 默认只连 443，不自动降级或探测其他端口。
- 先用
curl -I https://example.com或openssl s_client -connect example.com:443 -servername example.com确认服务可达且响应 TLS 握手 - 若服务跑在非标端口（如
8443），必须显式指定：sslscan example.com:8443 - 某些 CDN（如 Cloudflare）会拦截或限制扫描行为，返回空响应或重定向到 HTTP，此时
sslscan可能卡住或报错 —— 换成直连源站 IP 测试更可靠
sslscan 输出里 “Accepted” 和 “Rejected” 密码套件含义不清
sslscan 列出的每条密码套件前标有 Accepted 或 Rejected，这不是“是否支持”，而是“该套件能否在当前握手流程中成功协商”。它反映的是服务端实际配置 + 协议版本组合下的真实行为。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
Accepted SSLv2几乎总该被禁用 —— 若出现，说明服务仍启用了严重过时协议，应立即关掉 -
TLSv1.2下大量Accepted但全是EXPORT、NULL、RC4套件，代表加密强度极低，存在已知可利用漏洞 -
TLSv1.3的输出不同：它不列传统套件，只显示Supported Protocols和Server Key Exchange类型（如secp256r1），重点看是否禁用SHA-1签名和弱曲线
为什么 sslscan 不显示证书链完整性或 OCSP 装订状态
sslscan 核心定位是协议与密码套件探测，不是证书验证工具。它不会主动请求 OCSP 响应，也不校验中间证书是否完整下发。
- 证书链问题需另用
openssl s_client -connect example.com:443 -showcerts观察Verify return code（非零即异常） - OCSP 装订（stapling）状态得加
-status参数：openssl s_client -connect example.com:443 -status，看输出里有没有OCSP response:块 - 别指望
sslscan --no-colour --no-failed这类参数能补全证书细节 —— 它压根不解析证书字段
替代方案：当 sslscan 结果不准或太慢时换什么
sslscan 在较新 OpenSSL 版本下对 TLSv1.3 支持有限，且无法模拟客户端限制（比如只允许 ECDHE）。真要测算法强度，testssl.sh 更全面，但体积大；轻量替代是直接用 openssl s_client 配合 -cipher 手动枚举。
- 快速筛弱套件：
openssl s_client -connect example.com:443 -cipher "EXPORT:NULL:LOW:MD5:DES:RC4" -servername example.com 2>/dev/null | grep "Cipher is" - 确认强算法是否可用：
openssl s_client -connect example.com:443 -cipher "ECDHE-ECDSA-AES256-GCM-SHA384" -tls1_2 -servername example.com -
testssl.sh虽好，但默认会发大量连接，内网或限流环境容易被拒绝 —— 加--fast或限定协议范围（如--protocols tls1_2）更稳妥
sslscan 的检测范围内。它只回答“哪些密码套件能通”，不回答“通了之后安不安全”。
