Certificate Signature Algorithm differs from Signature Algorithm Negotiated for Connection With the upcoming sunsetting of SHA-1 by browsers I was checking signature algorithms for sites I visit. I'm using Firefox 43.0.2 on Windows.

I noticed something interesting when I visited the site Origin Energy site: https://online.originenergy.com.au.

The site's (leaf) certificate uses the SHA-2/SHA-256 signature algorithm. See certificate details dialog screenshot.


Where as the connection cipher suite appears to use SHA-1. See page info dialog screenshot.


I have a few questions:

Q1. Are the Certificate Signature Algorithm and signature algorithm in the negotiated connection cipher suite used for different purposes?

If these signature algorithms are used for different purposes.

Q2. Does the upcoming sunset for SHA-1 relate to the Certificate Signature Algorithm and signature algorithm in the connection cipher suite?

and

Q3. The SSL Labs scan for the site shows the web service cipher suite lists supports SHA-2 and SHA-1 algorithms.

If I'm using the latest version of Firefox why does the server/client negotiation not use the preferred SHA-2 algorithm for the connection?
Are the Certificate Signature Algorithm and signature algorithm in the
  negotiated connection cipher suite used for different purposes?


Yes they are.
The hash negotiated in the cipher suite is completely irrelevant to the certificate. The verification of the certificate and the signatures in the TLS handshake use the hash / signature pair negotiated in the signature_algorithms extension. The hash from the cipher suite is called the Pseudorandom Function (PRF) which is used for authentication (in HMAC-mode) for CBC cipher suites and to derive the [master_secret][4] from the pre_master_secret.


  Does the upcoming sunset for SHA-1 relate to the Certificate Signature
  Algorithm and signature algorithm in the connection cipher suite?


The sunset of SHA-1 only affects the use of SHA-1 in certificates. The SHA-1 based cipher suites will still be available as HMAC-SHA-1 isn't broken by collisions on SHA-1.


  If I'm using the latest version of Firefox why does the server/client
  negotiation not use the preferred SHA-2 algorithm for the connection?


Usually the server picks the cipher suites himself, i.e. the server picks the cipher suite it considers strongest and unfortunately most clients (including Firefox) don't support AES-256-GCM but AES-256-CBC so AES-256-CBC gets picked. As for why it picks SHA-1 over SHA-2 then, it's again the support question. Firefox only supports CBC with SHA-1 but not with SHA-2 so SHA-1 gets picked because of the stronger key size.

In your case the server prefers DHE_RSA_* over everything else. It prefers DHE_RSA_AES_*_GCM_* first, but Firefox doesn't support them (Firefox only supports GCM with ECDHE_*) so it picks the next suite in the list which is DHE_RSA_WITH_AES_256_CBC_SHA.

From the comments:


  [D]oes it alert on intermediate certs as SHA-1 may impact on the clients
  ability to validate the trust chain?


Yes, the browser automatically trusts intermediate certificates signed by a trusted root CA. Thus it may not have seen the exact certificate before, meaning if somebody could find a colliding certificate and somehow make the root CA sign it, you're trusting a malicious certificate (this is the same with leaf certificates).


  Also why not alert on the root cert?


The browser or the OS have a so-called "certificate store" where they store trusted root certificates. There are three reasons why it collisions on SHA-1 don't matter for root certificates.


If the root certificate is sent by the server, the browser may just compare this one byte-by-byte to the local copy and thus any change would cause the alert, but the SHA-1 hash isn't verified explicitely.
If the root certificate is sent by the server, the browser may just compute the hash of the received certificate and compare with the hash of the stored certificate. You'd need a second-preimage on SHA-1 to break this which is considered infeasible as of now.
Usually the root certificate isn't sent by the server. In this case the browser looks at the issuer of the intermediate certificate and check if this one is in the trust store and accepts it if it is in there.