1TCP-like Client Procedures

Connect to the host given by hostname, on the port given by
port-no. This connection will be encrypted using SSL. The
return values are as for tcp-connect: an input port and an
output port.

The optional client-protocol argument determines which
encryption protocol is used, whether the server’s certificate is
checked, etc. The argument can be either a client context created by
ssl-make-client-context, or one of the following symbols:
'sslv2-or-v3 (the default), 'sslv2, 'sslv3,
or 'tls; see ssl-make-client-context for further
details (including the meanings of the protocol symbols).

Closing the resulting output port does not send a shutdown message to
the server. See also ports->ssl-ports.

Creates a context to be supplied to ssl-connect. The context
identifies a communication protocol (as selected by
protocol), and also holds certificate information (i.e., the
client’s identity, its trusted certificate authorities, etc.). See the
section Context Procedures below for more information on
certificates.

Like tcp-listen, but the result is an SSL listener (which is
a synchronizable value; see sync). The extra optional
server-protocol is as for ssl-connect, except that a
context must be a server context instead of a client context.

Call ssl-load-certificate-chain! and
ssl-load-private-key! to avoid a no shared cipher
error on accepting connections. The file "test.pem" in the
"openssl" collection is a suitable argument for both calls
when testing. Since "test.pem" is public, however, such a
test configuration obviously provides no security.

Returns two values – an input port and an output port – that
implement the SSL protocol over the given input and output port. (The
given ports should be connected to another process that runs the SSL
protocol.)

The mode argument can be 'connect or
'accept. The mode determines how the SSL protocol is
initialized over the ports, either as a client or as a server. As with
ssl-listen, in 'accept mode, supply a
context that has been initialized with
ssl-load-certificate-chain! and
ssl-load-private-key! to avoid a no shared cipher
error.

The context argument should be a client context for
'connect mode or a server context for 'accept
mode. If it is not supplied, a context is created using the protocol
specified by a protocol argument.

If the protocol argument is not supplied, it defaults to
'sslv2-or-v3. See ssl-make-client-context for
further details (including all options and the meanings of the
protocol symbols). This argument is ignored if a context
argument is supplied.

If close-original? is true, then when both SSL ports are
closed, the given input and output ports are automatically closed.

If shutdown-on-close? is true, then when the output SSL port
is closed, it sends a shutdown message to the other end of the SSL
connection. When shutdown is enabled, closing the
output port can fail if the given output port becomes unwritable
(e.g., because the other end of the given port has been closed by
another process).

This chain is used to identify the client or server when it connects
or accepts connections. Loading a chain overwrites the old chain. Also
call ssl-load-private-key! to load the certificate’s
corresponding key.

You can use the file "test.pem" of the "openssl"
collection for testing purposes. Since "test.pem" is public,
such a test configuration obviously provides no security.

Loads a PEM-format file containing certificates that are used by a
server. The certificate list is sent to a client when the server
requests a certificate as an indication of which certificates the
server trusts.

Loading the suggested certificates does not imply trust, however; any
certificate presented by the client will be checked using the trusted
roots loaded by ssl-load-verify-root-certificates!.

You can use the file "test.pem" of the "openssl"
collection for testing purposes where the peer identifies itself using
"test.pem".

5Implementation Notes

For Windows, openssl relies on "libeay32.dll"
and "ssleay32.dll", where the DLLs are located in the same
place as "libmzsch‹vers›.dll" (where ‹vers›
is either xxxxxxx or a mangling of PLT Scheme’s version
number). The DLLs are distributed as part of PLT Scheme.

For Unix variants, openssl relies on
"libcryto.so" and "libssl.so", which must be
installed in a standard library location, or in a directory listed by
LD_LIBRARY_PATH.

For Mac OS X, openssl relies on
"libssl.dylib" and "libcryto.dylib", which are part
of the OS distribution for Mac OS X 10.2 and later.