在 apache 中为基于 ip 的虚拟主机配置独立加密套件，需要在每个 virtualhost 块中使用 ciphersuite 指令指定特定的密码算法列表。apache 默认继承全局 httpd.conf 或 conf.d 下的设置，但通过在每个虚拟主机的上下文中显式定义该指令，可以覆盖全局配置，从而实现不同 ip 地址使用不同的加密强度或算法组合。
如何在全局和局部配置中隔离加密套件
要实现隔离，必须确保每个虚拟主机的 CipherSuite 指令互不干扰。Apache 的配置加载顺序是：先加载全局配置，再按配置文件包含顺序加载虚拟主机配置。如果在 <virtualhost></virtualhost> 标签内定义了 CipherSuite，它将仅对该虚拟主机生效。如果未定义，则回退到全局设置。因此，关键在于为每个需要独立套件的 IP 创建独立的 <virtualhost></virtualhost> 块，并在其中明确写入 CipherSuite。
# httpd.conf 或 vhost.conf
Listen 80.0.0.1:443
Listen 80.0.0.2:443
<VirtualHost 80.0.0.1:443>
ServerName secure.example.com
SSLEngine on
SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/key.pem
# 仅允许高强度套件
CipherSuite HIGH:!aNULL:!MD5:!RC4
</VirtualHost>
<VirtualHost 80.0.0.2:443>
ServerName legacy.example.com
SSLEngine on
SSLCertificateFile /path/to/legacy_cert.pem
SSLCertificateKeyFile /path/to/legacy_key.pem
# 允许旧设备兼容的较弱套件
CipherSuite DEFAULT:!aNULL:!eNULL
</VirtualHost>
上述代码展示了两个 IP 地址分别绑定不同的加密策略。第一个 IP 使用高强度套件，禁用了 MD5 和 RC4；第二个 IP 使用默认套件，但禁用了空认证和空加密，以平衡兼容性与安全。重启 Apache 后，访问不同 IP 将触发对应的加密协商。
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
如何验证不同 IP 是否应用了预期的加密套件
配置完成后，需要验证客户端连接时实际使用的加密套件是否符合预期。可以使用 openssl s_client 命令分别连接两个 IP 地址，并检查输出中的 SSL-Session 部分。该工具会显示协商后的协议版本、密钥交换算法、认证算法、加密算法和 MAC 算法。通过对比两个 IP 的连接结果，可以确认 CipherSuite 指令是否生效。
# 测试 IP 1 (高强度) openssl s_client -connect 80.0.0.1:443 -servername secure.example.com # 观察输出中的 Cipher 字段，应匹配 HIGH 套件 # 测试 IP 2 (兼容型) openssl s_client -connect 80.0.0.2:443 -servername legacy.example.com # 观察输出中的 Cipher 字段，应匹配 DEFAULT 套件
在实际操作中，如果某个 IP 返回的加密套件与预期不符，需检查是否有其他配置文件（如 .htaccess 或额外包含的 vhost 文件）覆盖了当前设置。此外，确保 Apache 模块 mod_ssl 已正确加载，且没有在其他上下文中意外重置 CipherSuite。通过这种方式，可以精确控制每个虚拟主机的加密行为。
当客户端不支持任何共享加密套件时会发生什么
如果配置的 CipherSuite 过于严格，导致服务器提供的套件列表中没有任何一个被客户端支持，TLS 握手将失败。此时，客户端会收到一个 TLS Alert 消息，通常显示为 "handshake failure" 或 "no shared cipher"。服务器端日志（如 error.log）中会记录相应的错误信息，提示无法协商出共同的加密算法。这种情况常见于为旧设备配置了过强的加密策略，或为新设备配置了过弱的策略而客户端强制要求高安全性时。
