{"author":"Joel Depooter","author_email":"joel.depooter@safe.com","author_time":1742857584,"commit_time":1744752460,"committer":"Daniel Stenberg","committer_email":"daniel@haxx.se","hash":"fe9898d26e54edc197570b971be86c15ccb67935","message":"schannel: handle pkcs12 client certificates which contain CA certificates\n\nThe SChannel code uses the CertFindCertificateInStore function to\nretrieve the client certificate from a pkcs12 certificate store.\nHowever, when called with the CERT_FIND_ANY flag, this function does not\nprovide any guarantees on the order in which certificates are retrieved.\nIf a pkcs12 file contains an entire certificate chain instead of a\nsingle client certificate, the CertFindCertificateInStore function may\nreturn the CA or an intermediate certificate instead of the desired\nclient certificate. Since there is no associated private key for such a\ncertificate, the TLS handshake fails.\n\nWith this change, we now pass the CERT_FIND_HAS_PRIVATE_KEY flag. This\nensures that the CertFindCertificateInStore function will return a\ncertificate which has a corresponding private key. This will stop the CA\nand intermediate certificates from being selected. I don't think there\nwould be much use in a client certificate which has no associated\nprivate key, so this should ensure the client certificate is selected. I\nsuppose it may be possible for a pkcs12 file to contain multiple\ncertificates with private keys and the new behaviour may not guarantee\nwhich is selected. However, this is no worse that the previous behaviour\nin which any certificate may been selected.\n\nThe CERT_FIND_HAS_PRIVATE_KEY is only available in Windows 8 / Server\n2012 (aka Windows NT6.2). For older versions, we will fall back to using\nthe CERT_FIND_ANY flag.\n\nCloses #16825\n","parents":["fbdb1e1dbe824a72f41a104fa26e555cb0b6b45a"],"tree_hash":"c4c18e22d3dcf2f4b120df46bd05595b26c103f3"}