http://bugs.winehq.org/show_bug.cgi?id=60498 Bug ID: 60498 Summary: crypt32: CryptQueryObject() reports some BER-encoded PFX files as CERT_QUERY_CONTENT_PKCS7_SIGNED Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs@list.winehq.org Reporter: mailtomendoza@gmail.com Target Milestone: --- Distribution: --- CryptQueryObject(CERT_QUERY_OBJECT_BLOB, ..., CERT_QUERY_CONTENT_FLAG_ALL, ...) returns CERT_QUERY_CONTENT_PKCS7_SIGNED (8) instead of CERT_QUERY_CONTENT_PFX (12) for some PKCS#12 files that use indefinite-length BER encoding, as written by BouncyCastle (C#, Pkcs12Store.Save()). .NET Framework's X509Certificate2 picks the import path from the CryptQueryObject() result, so the PFX import never runs for such a file and loading the certificate with its key fails. Seen with SALTO ProAccess Space 6.14, which loads such PFX files (EC keys) under .NET Framework 4.8. Cause: when CRYPT_QuerySignedMessage() fails to decode the blob as a ContentInfo-wrapped message, it falls back to decoding it as a bare SignedData (CryptMsgOpenToDecode(CMSG_SIGNED)). A PFX is SEQUENCE { INTEGER 3, SEQUENCE authSafe (ContentInfo), SEQUENCE macData }, and for some files the lenient SignedData decoder accepts that; a +crypt trace shows CryptDecodeObjectEx for the signed info returning 1 for the PFX. Whether it happens depends on the data: of two PFX files written by the same code, the 951-byte EC one is misdetected, the 2378-byte RSA one is not. Reproducer (attached): bc-ec.pfx (throwaway EC P-256 test certificate, CN=Test CA, empty password) and pfxcheck.c from bug 60497: wine pfxcheck.exe bc-ec.pfx Wine 11.19: CryptQueryObject content type: 8 with the patch: CryptQueryObject content type: 12 (The import of this particular file additionally needs the patches from bug 60497 and, for the EC key, bug 60486.) A suggested patch is attached (tested on Wine 11.19, applies to master too): only use the bare-SignedData fallback when the outer SEQUENCE starts with an INTEGER followed by a SET, as SignedData does (version, digestAlgorithms); a PFX has a SEQUENCE in that position. 32- and 64-bit tested; crypt32 conformance tests unchanged. This is a heuristic precheck; making the SignedData decoder itself stricter would arguably be the better fix. Not done yet: a conformance test with such a PFX blob in tests/object.c. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.