I can't get my head around why the certificate itself has one signature algorithm, but the same certificate's public and private keys have a different signature algorithm.
A certificate is a document signed by an issuer (the certificate authority or "CA"), that contains a public key used to verify signatures by a subject (the "owner" of the certificate so to speak). The issuer and subject's choices of signing algorithm are independent. What's going on here is that the certificate contains a signing key with one algorithm, and the issuer signed it with a different algorithm. A very silly analogy:
- Issuer is a notary
- Subject is notary's client
- Keys are pens
- Algorithms are ink colors
- Notary and client can use pens with different ink colors
x509Certificate.SignatureAlgorithm field in your question seems to correspond to section 188.8.131.52 ("signatureAlgorithm") of RFC 5280:
signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate.
The key word there is "CA"—the issuer of the certificate.
Certificates in the proper sense of the term don't include private keys, so the
x509Certificate.PrivateKey property that you describe must be related to the software library that you're using. The certificate proper however, under
SubjectPublicKeyInfo records that specify algorithms used by the subject keys, as explained in section 184.108.40.206 ("Subject Public Key Info"):
This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in Section 220.127.116.11.
And this, again, is independent of the other field, because one is for the issuer and the other is for the subject.
Does it matter that the former is sha256 and the latter are sha1?
It's not a problem that the algorithms are different, but it is one to have SHA-1 in the latter, since SHA-1 should no longer be used for public-key signatures.