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] from the
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
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.