谷歌浏览器将在以下情况下开始警告用户他们的SSL连接不安全 ：
因此，我正在尝试编写一个方法来确定证书是否受到影响。 下面是我维护的另一台服务器上的SHA1证书示例，该证书在“安全”时间范围内到期：
$ curl -v --silent https://example.com/ 2>&1 | grep "expire\|SSL connection using" * SSL connection using DHE-RSA-AES256-GCM-SHA384 * expire date: 2015-07-20 00:00:00 GMT 我怎么能确定这个证书是来自stringDHE-RSA-AES256-GCM-SHA384 SHA1？ 256中的string使它看起来像是使用256位algorithm，即使我知道这不是因为我自己用$ openssl req -new -newkey rsa:2048 -nodes做了证书请求。 Googlesearch我发现这个资源或支持密码，但我不知道如何才能确定该文件的密码强度。
我怎么能通过curl来确定密码的强度，以便我可以编写它？
我怎么能确定这个证书是stringDHE-RSA-AES256-GCM-SHA384
你不能。 该string只是描述了用于encryption的密码套件，并且与证书本身无关。 你必须看看证书，而不是像这样：
openssl s_client -connect example.com:443 | \ openssl x509 -text -noout |\ grep 'Signature Algorithm\|Not After'
请注意，validation证书包含SHA-2签名是不够的。 您需要检查直到根的链中的中间证书都没有使用SHA-1进行签名。
NSS具有环境variablesNSS_HASH_ALG_SUPPORT ，可用于控制哈希algorithm可用于使用库的程序。 这个环境variables将被包括Firefox在内的许多程序所尊重，如果使用NSS支持编译（如在Red Hat Enterprise Linux和Fedora上），则通过curl 。
curl -V | fgrep NSS/ env NSS_HASH_ALG_SUPPORT=-SHA-1 curl -v --head https://www.google.com/
如果使用NSS支持编译curl ，并且正在使用SHA-1证书，则输出将如下所示：
curl 7.40.0 (x86_64-redhat-linux-gnu) libcurl/7.40.0 NSS/3.18 Basic ECC zlib/1.2.8 libidn/1.29 libssh2/1.5.0 * Trying 64.233.166.104... * Connected to www.google.com (64.233.166.104) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=www.google.com,O=Google Inc,L=Mountain View,ST=California,C=US * start date: Jun 03 09:26:01 2015 GMT * expire date: Sep 01 00:00:00 2015 GMT * common name: www.google.com * issuer: CN=Google Internet Authority G2,O=Google Inc,C=US * NSS error -8016 (SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED) * The certificate was signed using a signature algorithm that is disabled because it is not secure. * Closing connection 0 curl: (60) The certificate was signed using a signature algorithm that is disabled because it is not secure. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Exit 60