4.5 Creating the Secure Socket Context
RWSecureSocketContext is the central data structure in the Secure Sockets package. It contains default information for all secure sockets and portals that you create with it, including:
*default cipher list
*session ID cache
*default certificate and private key
*default location of trusted certificates
*default certificate verification mode and verification callback
All of these defaults can be overridden for each socket or portal.
Normally, your application sets the default certificate and private key for servers and the default location of trusted certificates for clients. This information can be set using the member functions setIdentity() and prepareToAuthenticate().
By default, the constructor for the context calls setOptions(SSL_OP_ALL) to enable compatibility with other SSL/TLS implementations. For more information, see the reference page for RWSecureSocketContext.
4.5.1 Initializing the Context to Perform Server Authentication Only
To initialize the context to perform server authentication only:
1. Call RWSecureSocketContext::setIdentity() on the server’s context.
2. Call RWSecureSocketContext::prepareToAuthenticate() on the client’s context.
Be sure to replace trustedcerts.pem with the path and file name of your own trusted certificates file.
The examples in Section 4.1, “Getting Started with Secure Sockets,” show server authentication only. For an example of a client application that reads a secure Web page from a server, see the example in examples\secsock\httpsget.cpp.
Most TLS/SSL authentications that occur on the World Wide Web are server authentications only. This means that clients verify the identity of servers, but not vice versa.
For example, if you buy a book from Amazon.com, your Web browser is the client, and Amazon.com is the server. To ensure that your credit card information is sent only to Amazon.com, your Web browser performs a server authentication. Amazon.com’s server does not care if someone else is pretending to be you because Amazon.com verifies its clients by checking their credit card information.
If Amazon.com wanted to perform client verification, every potential customer would need a personal certificate. For this reason, most Web stores omit TLS/SSL client verification, and use their client’s credit cards to verify identity.
4.5.2 Initializing the Context to Perform Both Client and Server Authentication
To perform client authentication in addition to server authentication:
1. Call RWSecureSocketContext’s member functions setIdentity() and prepareToAuthenticate() from the client.
2. Call RWSecureSocketContext’s member functions setIdentity() and prepareToAuthenticate() from the server.
See the example client and server in Section 4.7, “Checking the Validity of a Certificate.”
Client and server authentication is normally used when an application can easily require that all clients have certificates, such as when a company creates internal-use products.