Paul wrote:
>> 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. 

Arno Garrels

>> 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
> Paul
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to