我已经搜索和测试了几天，但已经没什么可尝试的了。这是我的问题。我有一个 Apache Lounge 2.4.18 (Win32) VC14 Web 服务器，运行在 Microsoft Windows 2008 R2 服务器上，使用 OpenSSL 1.0.2g。我们的公司安全团队扫描了我的服务器，发现正在使用 RC4。（他们使用了 Rapid7 的 Nexpose）。他们建议配置服务器以禁用对 RC4 密码的支持，并建议使用下面显示的密码配置。他们还建议不要使用 TLSv1，只使用 TLSv1.1 和 TLSv1.2。我还运行了 SSLScan 来复制结果，可以看到“TLSv1 128 位 RC4-SHA”被接受了。
我想没问题，然后按照下面方法更改了我的 httpd.conf 文件，然后重新启动了 Apache2.4 服务。然后我让他们重新扫描服务器，得到了相同的结果。我搜索了整个服务器，寻找包含“SSLCipherSuite”或“SSLProtocol”的文件，并删除或重命名了除 \Apache24\conf\httpd.conf 之外的所有文件。我确实有一个 \Apache24\conf\openssl.cnf 文件，但我认为它没有任何作用，因为它仍然是 Apache 自带的默认文件。我还进行了大规模清理，删除了所有旧版本的 Apache、OpenSSL 和 PHP。大约 3 周前，我将 Apache 和 OpenSSL 从 Apache 2.2 和 OpenSSL 0.9.x 升级，运行起来没有问题。error.log 或 Windows 事件查看器中没有任何启动错误。
Apache/OpenSSL 是否在其他地方确定协议或密码套件？
是否存在默认位置可以忽略我的 SSL 相关指令？
我的 httpd.conf 文件的内容（“MYDOMAIN”显然不是我的实际域名）：
<VirtualHost *:80>
DocumentRoot "C:/Apache24/htdocs"
ServerName www.MYDOMAIN.com
</VirtualHost>
<VirtualHost *:443>
DocumentRoot "C:/Apache24/htdocs_apps"
ServerName apps.MYDOMAIN.com
SSLEngine on
SSLCertificateFile "C:/Apache24/certs/233afff052190aeb.crt"
SSLCertificateKeyFile "C:/Apache24/certs/star_MYDOMAIN_com.key"
# SSLCertificateChainFile "C:/Apache24/certs/gd_bundle-g2-g1.crt"
SSLProtocol -ALL +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSAAES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSAAES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
<Location / >
Options -ExecCGI -FollowSymLinks -Indexes
Require all granted
</Location>
</VirtualHost>
任何帮助是极大的赞赏。
答案1
至于 openssl.conf，它是否有 SSLCipherSuite 指令？如果有，它是否被注释掉了？可能存在“合并”问题。
查看您的 SSLCipherSuite 指令，我发现以下问题（可能是也可能不是此处问题的一部分）：
拼写错误：
- ECDHE-ECDSAAES256-GCM-SHA384 可能应该是 ECDHE-ECDSA-AES256-GCM-SHA384
- 尽管 TLSv1.0，DHE-RSAAES256-SHA 可能应该是 DHE-RSA-AES256-SHA
TLSv1.0 协议：
- DHE-RSA-AES128-SHA 是 TLSv1.0
- DHE-DSS-AES256-SHA 是 TLSv1.0
无论如何，我使用：
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
和
SSLProtocol all -SSLv2 -SSLv3
并获得 Qualys SSL Labs 的 A+ 评级SSL 服务器测试（包括无 RC4 的验证）。
注意：尽管有些人正在放弃 TLSv1.0，但你可能会在相当多的浏览器上遇到问题，可能包括 Android 5.0.0 及以前版本、Win 7 上的 IE 8-10、Win Phone 8.0 上的 IE 10、OS X 10.6.8 上的 Safari 5.1.9 和 OS X 10.8.4 上的 Safari 6.0.4
答案2
啊哈，成功了！原来我们的网络使用“F5”设备，它建立 SSL 连接，然后将连接代理回我的服务器。看来他们需要研究他们的密码！多亏了这个小练习，我的服务器现在更加安全了。我还使用 CloudFlare，因此连接使用 TLSv1.1 和 TLSv1.2 依次为 Cloudflare->F5->OpenSSL。
午餐时间到了。我想知道我们是否还保留着那 2 杯饮料的午餐政策……
答案3
听起来 F5 设置可能是“入站企业”而不是“入站 SSL 直通”。看起来区别在于，前者从用户到 F5 的流量通过 F5 SSL 设置加密，然后在 F5 解密，最后使用您的 SSL 设置重新加密，仅用于 F5 和您的服务器之间的通信，而后者用户和您的服务器之间的流量完全使用您的 SSL 设置加密（并且只是由 F5 传递，没有解密/重新加密）。如果是这种情况，您的流量可能仅在您和 F5 之间是“安全的”（没有 RC4），并且在公共网络上时取决于 F5 设置。在假设您有一个安全设置之前，至少值得向您的网络人员询问一些问题。