Certificate Authentication

Authentication is the process of determining if a remote host can be trusted. To establish its trustworthiness, the remote host must provide an acceptable authentication certificate.

Remote hosts establish their trustworthiness by obtaining a certificate from a Certification Authority (CA). The CA may, in turn, have certification from a higher authority, and so on, creating a chain of trust. To determine whether a certificate is trustworthy, an application must determine the identity of the root CA, and then determine if it is trustworthy.

Windows CE maintains a database of trusted CAs. When a secure connection is attempted by an application, Windows CE extracts the root certificate from the certification chain and checks it against the CA database. It delivers the root certificate to the application through a certificate validation callback function, along with the results of the comparison against the CA database.

Applications bear ultimate responsibility for verifying that a certificate is acceptable. Applications can accept or reject any certificate. If a certificate is rejected, the connection is not completed. At a minimum, a certificate should meet two requirements: The certificate is current, and the identity contained in the certificate matches the root CA identity.

The following root certificate authorities are included in the Windows CE 2.1x Schannel Certificate Authority database:

• VeriSign/RSA Commercial
• VeriSign/RSA Secure Server
• VeriSign Class 2 Public Primary CA
• VeriSign Class 3 Public Primary CA
• VeriSign Class 4 Public Primary CA
• Keywitness Canada, Inc.
• GTE Cybertrust ROOT
• Thawte Server CA
• Thawte Premium Server CA
• Thawte Personal Basic CA
• Thawte Personal Freemail CA
• Thawte Personal Premium CA
• Microsoft Root Authority
• Root SGC Authority

    To add certificates to the CA database through the registry:

1. Create the key HKLM\Comm\SecurityProviders\SCHANNEL\CAs if one does not already exist.
2. Create a subkey with the name of the certificate, for example My Certificate.
3. Create the following values under the My Certificate key.

       DWORD:Enabled = 1
       DWORD:Type = 1
       BINARY:CACert = X509 certificate bytes

Schannel will pick up the root certificate next time it is loaded.

The certificate validation callback function must be implemented by all client applications that use secure sockets. The value it returns determines if the connection will be completed by Winsock. It must have the following syntax:

int SslValidate (
         DWORD      dwType
         LPVOID     pvArg
         DWORD      dwChainLen
         LPBLOB     pCertChain
         DWORD      dwFlags
);

The parameters contain the following data:

• The dwType parameter specifies the data type pointed to by pCertChain. This must be SSL_CERT_X.509, specifying that pCertChain is a pointer to an X.509 style certificate.
• The pvArg parameter is the application-defined context, passed by the SSLVALIDATECERTHOOK structure.
• The dwChainLen parameter is the number of certificates pointed to by pCertChain. It will always be equal to one.
• The pCertChain parameter is a pointer to the root certificate. The BLOB struct is defined in Sslsock.h in the SDK. The pBlobData field points to a X.509 certificate (ISO standard). The certificate is not the root certificate but the server certificate. The caller must parse the certificate to extract the pertinent data like the subject and issuer names.
• If the root issuer of the certificate could not be found in the CA database, the dwFlags parameter will contain SSL_CERT_FLAG_ISSUER_UNKNOWN. The application can either attempt to verify the issuer itself, or return SSL_ERR_CERT_UNKNOWN.

The following table shows values returned by the callback function.