3 added 171 characters in body
source | link

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
  3. Reorder the priority of ciphersuitescipher suites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

EDIT: A very good explanation for two corner cases when you send SHA-2 chain and the browser still sees SHA-1: https://sslmate.com/blog/post/chrome_cached_sha1_chains

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
  3. Reorder the priority of ciphersuites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
  3. Reorder the priority of cipher suites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

EDIT: A very good explanation for two corner cases when you send SHA-2 chain and the browser still sees SHA-1: https://sslmate.com/blog/post/chrome_cached_sha1_chains

2 added 237 characters in body
source | link

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3m7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3m7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
  3. Reorder the priority of ciphersuites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3m which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3m certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Reorder the priority of ciphersuites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
  3. Reorder the priority of ciphersuites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.
1
source | link

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3m which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3m certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

  1. Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
  2. Reorder the priority of ciphersuites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.