X509 Certificate Parsing

[RichL]

Greetings,

I am validating SSL certificates on WinCE. I am distressed to find that
the CAPI 2.0 functions, like CertCreateCertificateContext, do not exist in
PocketPC 2000, but only in PocketPC 2002. Is this really true?

If so, I am relegated to using an earlier function, SslCrackCertificate.
This, however, has some very odd memory management. It looks like it is
supposed to allocate me an X509Certificate structure. However, the public
key portion of this structure is stored in memory that was not properly
allocated. How am I supposed to use this function?

I would appreciate any other hints or suggestions.

Sincerely,
Rich Letsinger
Bellevue, WA

[Rob]

Hi Rich,

I used the same SslCrackCertificate() function but I then used the
SslFreeCertificate() to free it. I didn't use the public key as the
validation of the key is already done upon entering the certificate
validation callback. All I need to do in the callback is check the dates,
and the domain name. Does this help with your problem?

I have a problem, which you may run into as well. I am using blocking
sockets, and I also use a select() call to test if the socket is readable.
This way I can have a timeout. Problem is is that the select call blocks
sometimes, even if the socket is actually readable. This can cause it to
hang on the last chunk of data sent over the SSL pipe. What I believe is
happening is that the data is decrypted into an intermediate buffer. The
recv() call is aware of this buffer, but the select call is not. The only
fix I can think of at the moment is to not call select() and just call recv.
However, this can cause the app to block.

Any ideas on the above issue?

Cheers,

Rob

"RichL" <rl...@hotmail.com> wrote in message
news:8998b601.02042...@posting.google.com...

[RichL]

Rob,

Thanks for your response and sorry it's taken me so long to get
back to your question. Yes, we've run into the same limitations
with select(). After much poking around, we determined that it
just wouldn't work to use select with blocking sockets. Our
first try was to spin doing a sleep(0) every time around to
release the timeslice. We do a non-blocking recv() ever time
around the loop to check for data. UGLY!

We've now gone the other way to use SSPI. This is undocumented
on CE but does seem to work. This way we make all our own calls
to encrypt() and decrypt() and the send() and recv() calls work
just like non-secure blocking sockets. Certificate validation
is more of a problem, however, because the trust checking, done
by the system as you mentioned, is up to us. I'm still working
on that one...

Best of luck,
Rich

"Rob" <emai...@yahoo.com> wrote in message news:<MQpz8.21$I_4.19...@newssvr14.news.prodigy.com>...