Utilizzo di un certificato X509 in .Net Compact Framework per l'autenticazione client HTTPRequest

Question

Sto lavorando su Windows Mobile 6 e vorrei avere l'autenticazione del client quando si parla con un server web Apache. Ho un certificato nel mio locale di certificati e dovrebbe essere piuttosto semplice:

X509Store myStore = new X509Store("MY", StoreLocation.CurrentUser); 
myStore.Open(OpenFlags.ReadOnly); 
X509Certificate2Collection certificates = myStore.Certificates; 
X509Certificate2 clientcertificate; 
foreach (X509Certificate 2certificate in certificates) { 
    clientcertificate = certificate; //omitted code to validate certificate 
} 
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(webPage); 
req.AllowWriteStreamBuffering = true; 
req.AllowAutoRedirect = false; 
req.Method = "POST"; 
req.ContentType = "text/xml"; 
req.Accept = "text/xml"; 
req.ClientCertificates.Add(clientcertificate); 
Stream stream = req.GetRequestStream(); 
stream.Write(buffer, 0, buffer.Length); 
stream.Close(); 

segmento Questo codice funziona finché rimuovo "req.ClientCertificates.Add (ClientCertificate)" linea.

Una volta inserito, viene visualizzato il messaggio "Impossibile stabilire un canale protetto per SSL/TLS". Stranamente, quando uso questo codice esatto nel normale .Net Framework, trasmette perfettamente il certificato.

Qualcuno sa se questo è possibile in Compact Framework? Se non riesco a presentare il certificato X509 per l'autenticazione client, quali altri modi devo perseguire per garantire che l'autenticazione sia corretta (dovrei avere accesso a CAPI o altri moduli crittografici Microsoft)

Grazie.

Answer 1

Buone notizie: ho risolto. Si è scoperto non avere a che fare con .Net Compact Framework. In 3.5 CF, HTTPWebRequest.ClientCertificates è supportato finché è possibile accedere al certificato X509.

Il motivo per cui l'handshake SSL non è riuscito a causa di un problema di affidabilità con il certificato lato server. I nostri certificati server erano autofirmati e abbiamo utilizzato certificati firmati per l'URL sbagliato, quindi l'applicazione non si sarebbe fidata del certificato del server fornito. A scopo di test, mettiamo in atto una politica di Trust All Certificates, che verrà rimossa per la produzione.

sealed class AcceptAllCertificatePolicy : ICertificatePolicy 
{ 
    private const uint CERT_E_UNTRUSTEDROOT = 0x800B0109; 

    public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate 
    certificate, WebRequest request, int certificateProblem) 
    { 
     // Just accept. 
     return true; 
    } 
    /*public bool CheckValidationResult(ServicePoint sp, 
    X509Certificate cert, WebRequest req, int problem) 
    { 
     return true; 
    }*/ 
} 

di riferimento a destra prima del HttpWebRequest

System.Net.ServicePointManager.CertificatePolicy = new AcceptAllCertificatePolicy(); 

E questo risolve il nostro problema con l'SSL/TLS canale sicuro.

Answer 2

Potrebbe essere che il server Apache non supporti connessioni protette.

Ad esempio, ho alcuni siti Web su domini ospitati che costano poco o nulla. Io uso questi siti web per testare il codice tutto il tempo.

Ma, per ottenere le funzionalità SSL, devo sborsare come $ 50 al mese. Quindi, non posso testare quelli sui miei siti.

A prova: Se il server Apache supporta SSL, si dovrebbe essere in grado di sostituire l'URL con l'equivalente SSL: http://www.stackoverflow.com con https://www.stackoverflow.com