SciSslSocketConfiguration Protocols
Represents a particular configuration composed of an SSL version, certificate filename, and private key filename. This configuration is then used as a key into a Context Registry that stores SciSslContext objects. These objects can be reused by multiple connections between a given client and server.
Instance Methods
caFile
Answers the CA file for the SciSslSocketConfiguration instance. The Certificate Authority (CA) file is a trusted certificate used for verification purposes.
caFile: aCertificateAuthorityFile
Sets the CA file for the SciSslSocketConfiguration instance.
caPath
Answers the path to the directory containing CA certificate files
caPath: aCAPath
Sets the path to the directory containing CA certificate files.
certificate
Answers the X509 certificate (could be nil) in the same format as provided by the setter. This could be a filename <String> or a certificate object <SciSslX509Certificate>
certificate: aStringOrSciSslX509Certificate
Sets the certificate to be used for the SciSslSocketConfiguration instance. This could be a filename <String> or a certificate object <SciSslX509Certificate>
certificateChainFilename
Answers the certificate chain file being used by the configuration for verification.
certificateChainFilename: aPemCertificateChainFilename
Sets the certificate chain file to be used by the configuration for verification.
certificateFilename
Answers the certificate filename for the SciSslSocketConfiguration instance.
certificateFilename: aCertificateFilename
Sets the certificate filename for the SciSslSocketConfiguration instance.
cipherList
Answers the implementation defined format of the cipherList. For OpenSSL, this is a <String>
cipherList: anObject
Sets the cipherList, an implementation defined format which specifies an ordered SSL cipher preference. In OpenSSL, this is a <String>.
getSciSslContext
Answers the context associated with this instance of SciSslSocketConfiguration stored in the ContextRegistry. If none exists, it creates a new context, stores it in the ContextRegistry with this SciSslSocketConfiguration as its key, and answers the newly created instance of SciSslContext.
hostname
Answers the <String> hostname used for Server Name Identification (SNI)
hostname: aString
Set @aString hostname to be used for Server Name Identification (SNI)
minProtocol
Answers the minimum protocol version allowed for the context
minProtocol: anObject
Set @anObject which defines the minimum protocol version allowed for the context
maxProtocol: anObject
Answers the maximum protocol version allowed for the context
maxProtocol: anObject
Set @anObject which defines the maximum protocol version allowed for the context
privateKey
Answers the private key (could be nil) in the same format as provided by the setter. This could be a filename <String> or a private key object <SciSslPrivateKey>
privateKey: aStringOrSciSslPrivateKey
Sets the private key to be used for the SciSslSocketConfiguration instance. This could be a filename <String> or a private key object <SciSslPrivateKey>.
privateKeyFilename
Answers the name of the private key file for this configuration.
privateKeyFilename: aFilename
Sets the private key filename for this configuration to aFilename.
securityLevel
Answer the <Object> which defines the security level for the context
securityLevel: anObject
Set the <Object> which defines the security level of the context.
sessionTimeout
Answer an <Integer> which defines the timeout of newly created sessions in seconds
sessionTimeout: anInteger
Set the @anInteger <Integer> which defines the session timeout in seconds.
This will defined how long sessions can be reused before they are considered expired.
setContextCipherList
Sets the list of supported ciphers for this configuration. By default, this function sets the cipher list to include all ciphers supported by the OpenSSL implementation.
sslVersion
Answers the SSL version protocol of this configuration: DEFAULT, SSLV23, TLS, TLSv1, TLSv1_2. See the setter for specific options.
sslVersion: anSslMethodObject
Sets the SSL version protocol to use for this configuration. For backwards compatibility, this setter accepts a few different object types to include <String>, <PlatformFunction> and implementation specific objects like OSSslSSLMethod from the OpenSSL implementation. It is recommended that the developer supply a <String>. The following options are provided below. If supplied as a string, it will be case-insensitive. Strings support constrains as well, so if the developer wanted to only support all versions of TLS with no fallback to any SSL protocols, they would supply the following version string: 'TLS:!SSLv2:!SSLv3'. This syntax is influenced by OpenSSL and says "Use the TLS protocol, don't allow a fallback to SSLv2, don't allow a fallback to SSLv3".
•DEFAULT - Specifying 'DEFAULT' will provide the preferred default ssl version protocol of the SSL Interface Implementation. Usually, this will be a TLS based version protocol.
•TLS, TLS_server, TLS_client - A TLS/SSL connection established with these methods may understand the SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
•If extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3.
•A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. This is the best choice when compatibility is a concern.
•TLSv1, TLSv1_server, TLSv1_client - A TLS/SSL connection established with these methods will only understand the TLSv1 protocol
•A client will send out TLSv1 client hello messages and will indicate that it only understands TLSv1.
•A server will only understand TLSv1 client hello messages.
•TLSv1_1, TLSv1_1_server, TLSv1_1_client - A TLS/SSL connection established with these methods will only understand the TLSv1.1 protocol
•A client will send out TLSv1.1 client hello messages and will indicate that it only understands TLSv1.1.
•A server will only understand TLSv1.1 client hello messages.
•TLSv1_2, TLSv1_2_server, TLSv1_2_client - A TLS/SSL connection established with these methods will only understand the TLSv1.2 protocol
•A client will send out TLSv1.2 client hello messages and will indicate that it only understands TLSv1.2.
•A server will only understand TLSv1.2 client hello messages.
•SSLv2, SSLv2_server, SSLv2_client - A TLS/SSL connection established with these methods will only understand the SSLv2 protocol.
•DEPRECATED - MAY NOT BE AVAILABLE IN MORE CURRENT SSL/TLS IMPLEMENTATIONS.
•A client will send out SSLv2 client hello messages and will indicate that it only understands SSLv2.
•A server will only understand SSLv2 client hello messages.
•SSLv3, SSLv3_server, SSLv3_client - A TLS/SSL connection established with these methods will only understand the SSLv3 protocol.
•DEPRECATED - MAY NOT BE AVAILABLE IN MORE CURRENT SSL/TLS IMPLEMENTATIONS.
•A client will send out SSLv3 client hello messages and will indicate that it only understands SSLv3.
•A server will only understand SSLv3 client hello messages.
•SSLv23, SSLv23_server, SSLv23_client - A TLS/SSL connection established with these methods may understand the SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
•IDENTICAL TO TLS, TLS_server, TLS_client IN MORE CURRENT SSL/TLS IMPLEMENTATIONS.
•If extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3.
•A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. This is the best choice when compatibility is a concern.
verify
Answer the verification mode for the SSL configuration.
verify: verifyMode
Set the verification mode for the SSL configuration. Valid modes of operation are...
•SSL_VERIFY_NONE -
Server - the server will not send a client certificate request to the client, so the client will not send a certificate.
Client - if anonymous ciphers are not in use (by default disabled), the server will send a certificate which will be checked. The result of the certificate verification process can be checked after the TLS/SSL handshake using the sslVerifyCertificate method. The handshake will be continued regardless of the verification result.
•SSL_VERIFY_PEER -
Server - the server sends a client certificate request to the client. The certificate returned (if any) is checked. If the verification process fails, the TLS/SSL handshake is immediately terminated with an alert message containing the reason for the verification failure. The behavior can be controlled by or-ing the additional SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
Client - the server certificate is verified. If the verification process fails, the TLS/SSL handshake is immediately terminated with an alert message containing the reason for the verification failure. If no server certificate is sent, because an anonymous cipher is used, SSL_VERIFY_PEER is ignored.
•SSL_VERIFY_FAIL_IF_NO_PEER_CERT -
Server - if the client did not return a certificate, the TLS/SSL handshake is immediately terminated with a handshake failure alert. This flag must be used together with SSL_VERIFY_PEER.
Client - ignored
•SSL_VERIFY_CLIENT_ONCE -
Server - only request a client certificate on the initial TLS/SSL handshake. Do not ask for a client certificate again in case of a renegotiation. This flag must be used together with SSL_VERIFY_PEER.
Client - ignored
Note:
Exactly one of the mode flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be set at any time. Verification failure will lead to a termination of the TLS/SSL handshake with an alert message, if SSL_VERIFY_PEER is set.
verifyDepth
Answer the maximum depth to which the certificate chain will be verified.
verifyDepth: anInteger
Set the maximum depth to which the certificate chain will be verified to anInteger. This depth is only used if #verify: has previously been set to include SSL_VERIFY_PEER.