Crypt32.dll is where most of the CryptoAPI is implemented. It supports encryption, decryption, and manipulation of certificates and related data structures. The actual encryption and decryption routines are implemented by a Cryptographic Service Provider, or CSP. The RSA enhanced provider was added by MichaelJung. JuanLang is implementing the certificate stores.
Currently crypt32 supports encoding and decoding of certificates and certificate revocation lists (CRLs) in DER format, and a reasonable subset of certificate stores and cryptographic messages.
Features of Crypt32
PFX is documented, sort of, in PKCS #12, and is implemented by the PFX functions in crypt32, e.g. PFXImportCertStore and PFXExportCertStore. These are used by native cryptui and by the importpfx tool (see bug 11070).
The Wine version of CertGetCertificateChain only builds simple chains. Complex chains depend on CTLs. CTLs are a Microsoft-proprietary cryptographic message. Perhaps because they're a Microsoft invention rather than a standard, they aren't much used in practice. (The only app I've seen call any of the CTL APIs is MSN Messenger, aka Windows Live Messenger, during installation.)
It also doesn't support all the extensions it should. In particular, it doesn't check the certificate policies extension. This is needed at least by bug 19517, XenCenter is unable to contact anything on the network.
RFC 5280 is the reference for certificate usage on the Internet. Mozilla also published a good guide to how Netscape did certificate validation.
Wine currently is able to check the revocation status certificates with a CRL distribution points extension. These allow Wine to download a CRL for the certificate and check whether it's been revoked. Most modern browsers, including Internet Explorer 7 and higher, also support OCSP, and Wine should too.