aboutsummaryrefslogtreecommitdiffstats
path: root/trio/README
blob: 55ad1b07de875513f29d806282bc18878073d44d (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

README -- trio

Trio is a package with portable string functions. Including printf() clones
and others.

 Copyright (C) 1998-2001 by Bjorn Reese and Daniel Stenberg.

 Permission to use, copy, modify, and distribute this software for any
 purpose with or without fee is hereby granted, provided that the above
 copyright notice and this permission notice appear in all copies.

 THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
 WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
 MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE AUTHORS AND
 CONTRIBUTORS ACCEPT NO RESPONSIBILITY IN ANY CONCEIVABLE MANNER.

Trio is intended to be an integral part of another application, so we
have not done anything to create a proper installation.

Compile with 'make' (edit the Makefile if you want a release build)

Test the package with 'make test'

Install by copying trio.h, triop.h, and libtrio.a (and man/man?/* if
you want documentation) to the appropriate directories.

Catch some usage examples in example.c

Send feedback and patches to the mailing list, subscription and other
information is found here:

        http://lists.sourceforge.net/lists/listinfo/ctrio-talk

Enjoy!

Trio web page

        http://daniel.haxx.se/trio/
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-05 12:49:34 +0000
vious. 2. Provide the *full* certificate chain Many SSL documents tell you to install the server certificate, silently assuming that it were directly signed by a trusted root certification authority (CA). If your server certificate is not directly signed by the root certification authority (root CA), then you are using intermediate CA. In this case, you *MUST* (as per the TLS standard) provide *ALL* intermediate certificates. If you fail to provide intermediate certificates, clients can only connect if the end user overrides/disables security warnings in his/her software, and this disables the detection of eavesdroppers. The intermediate CA certificates must be issued after the server's certificate in proper order, that is: first the intermediate CA cert that signed the servers' certificate, then the intermedate CA cert that signed the previous intermediate CA, and all the way back to the root CA cert (which you should omit). You can optionally add the root CA certificate, but this is redundant, as the client needs to have that installed anyways (see 3 below) in its store of trusted root certification authorities in order to verify certificates that this root CA has signed. For software that does not offer "chain certificate" options, but that supports reading certificates in PEM format, it is usually sufficient to concatenate all the certs in proper order (again, from server to root). 3. Provide the *root* CA's certificate separately. Provide the root CA's certificate in a place where your end users will quickly and easily find it, or provide a link to it. Depending on which mail software your clients use, it may not be pre-installed, and users require this root CA to verify your SSL server certificate, and possibly intermediate certificates. This is particularly important if you're using local self-signed certificates, as these are never preinstalled into end-users clients. Your technical support team should have the finger prints of this root CA readily available at least in MD5 and SHA1 formats and offer to clients and be ready to answer client questions as to the fingerprints (for verification) and installation in commonly used clients.
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-05 12:49:34 +0000