Home / server / Questions / 642464
Accepted
dotancohen
Asked: 2014-11-07 03:12:02 +0800 CST

Determining if an SSL cert is affected by SHA-1 phase-out

  • 772

Google chrome will start to warn users that their SSL connection is insecure under the following conditions:

  1. The cert uses the SHA1 hashing algorithm, and
  2. The cert expires on or after 2016-01-01 (or 2017-01-01 by different sources)

Therefore I am trying to script a method to determine if a cert is affected. Here is an example of a SHA1 cert on another server that I maintain, that expires in the 'safe' timeframe:

$ 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

How could I have determined that this cert is SHA1 from the string DHE-RSA-AES256-GCM-SHA384? That 256 in the string makes it sure look like it is using a 256 bit algorithm, even though I know it is not because I myself did the cert request with $ openssl req -new -newkey rsa:2048 -nodes. Googling around I found this resource or supported ciphers but I don't see how I could determine the cipher strength from that document.

How could I determine the cipher strength via curl, so that I could script it?

apache-2.2

2 Answers

  1. Best Answer

    How could I have determined that this cert is SHA1 from the string DHE-RSA-AES256-GCM-SHA384

    You can't. This string just describes the cipher suite used for encryption and is independent from the certificate itself. You have to take a look at the certificate instead, like this:

    openssl s_client -connect example.com:443 | \
openssl x509 -text -noout |\
grep 'Signature Algorithm\|Not After'
    • 2

  2. Note that it's insufficient to verify that the certificate contains an SHA-2 signature. You need to check that none of the intermediate certificates in the chain up to the root are signed with SHA-1.

    NSS features an environment variable, NSS_HASH_ALG_SUPPORT, which can be used to control what hashing algorithms are available to progams using the library. This environment variable will be respected by a number of programs, including Firefox, and by curl if it's compiled with NSS support (as it is on, for example, Red Hat Enterprise Linux and Fedora).

    curl -V | fgrep NSS/
env NSS_HASH_ALG_SUPPORT=-SHA-1 curl -v --head https://www.google.com/

    If curl is compiled with NSS support, and an SHA-1 certificate is in use, the output will look like:

    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
    • 1