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.
To initialize the context to perform server authentication only:
Call RWSecureSocketContext::setIdentity() on the server's context.
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.
To perform client authentication in addition to server authentication:
Call RWSecureSocketContext's member functions setIdentity() and prepareToAuthenticate() from the client.
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.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.