>> Another idea was to mimic the MS certificate server. The application
>> could download a missing certificate from your website.
> Is not save when you don't where you are downloading it from (I have
> no control of what our clients are doing)
Why was it a problem? You would maintain a CA bundle certificate file that
included virtually all known, serious CA root and intermediate certificates.
The application would ship with this file and/or download it from your
website if (an update was) required.
Or if chain verification failed due to a missing CA certificate the app
would silently lookup the missing certificate and download it from your
website into the CA certificate directory.
Self-signed certificates have to be accepted/trusted once by users,
for a persistent trust add them to the certificate directory.
The CA bundle certificate file is loaded into memory once on context
initialization. The CA certificate directory however is searched on
every verification again.
>> I can imagine the trouble, however OpenSSL was choosen as the SSL
>> implementation with cross platform support in mind, I still think
>> this was a good decision.
> It still is.
> Maybe I will add the most common CA's .
> Enterprise clients usually use GlobalSign, VeriSign, ..
> Is it better to add them seperately and use RpSslContext.SslCAPath
> or combine them as CRLF separated certs in a single file using
> RpSslContext.SslCAFile ?
> If I import the certificates, the exe will grow with ~ 130kB and
> that's unacceptable for 1 application
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be