In addition to username/password-based authentication, VisiSecure also supports public-key encryption. In public-key encryption, each user holds two keys: a public key and a private key. A user makes the public key widely available, but keeps the private key secret.
Data that has not been encrypted is often referred to as clear-text, while data that has been encrypted is called cipher-text. When a public key and a private key are used with the public-key encryption algorithm, they perform inverse functions of one another, as shown in the following diagram.
When you distribute your public key, the recipients of that key need some sort of assurance that you are indeed who you claim to be. The ISO X.509 standard defines a mechanism called a certificate, which contains a user's public key that has been digitally signed by a trusted entity called a Certificate Authority (CA). When a client application receives a certificate from a server, or vice-versa, the CA that issued the certificate can be used to verify that it did indeed issue the certificate. The CA acts like a notary and a certificate is like a notarized document.
A distinguished name represents the name of a user or the CA that issued the user's certificate. When you submit a certificate request, it includes a distinguished name for the user that is made up of the components listed in the following table.
|
2
|
Since the Acme CA is not in Joe's certificate chain, Joe obtains the issuer of the certificate for CA_2.
|
|
3
|
Because CA_2 is not a trusted CA, the server decides whether to accept or reject the connection.
|
|
•
|
A VisiBroker server using the MFCryptLib/OpenSSL security provider never trusts a peer certificate as a trustpoint (see vbroker.security. trustpointsRepository for details) if there is no valid CA intermediate/root certificate provided for it.
|
VisiSecure uses Java Secure Sockets Extension (JSSE) to perform SSL communication. VisiSecure SPI Secure Socket Provider class provides access to the underlying SSL implementation. Any appropriate implementation following Java Secure Socket Extension (JSSE) framework can be easily plugged in, independent of other provider mechanisms. The only necessary step is mapping the interfaces (or, in other words, callback methods) defined to the corresponding JSSE implementation. For more information on the SPI Secure Socket Provider class, see VisiSecure SPI for Java and “Security SPI for C++”.
Segments of the name of the cipher indicate what the cipher suite does or does not provide. The general format for TLSv1.3 cipher suite names is:
|
•
|
Refer to OpenSSL (https://www.openssl.org/) for a list of supported ciphers at the current OpenSSL version. The specific version of OpenSSL included in your release is specified in its Release Notes.
The list of supported cipher suites for VisiSecure is determined by the underlying security implementation. For VisiSecure for Java, this is the JSSE package used, which in turn depends on the version and manufacturer of the JDK used. For VisiSecure for C++, you can find the list of supported ciphers in the <install_dir>/include/csstring.h file, or by using the ssl::CipherSuiteInfoList* listAvailableCipherSuites() API.
VisiBroker supports ECDHE cipher suites. To enable these cipher suites a private key and certificate chain must be provided that conform to the following requirements. For ECDHE, certificates must contain an identity key from one of the supported DH Groups (see the VisiBroker 8.5.7 Release Notes). The supported cipher suites are:
OpenSSL supports many pre-defined ECC curves (also known as 'named curves' or ‘elliptic curves’), used in ECDH and ECDHE ciphers. A complete list of the supported named curves can be obtained by executing the following command, using the openssl utility (in this example, for RedHat Linux):
VisiBroker for C++ supports the well-known TLS elliptic curves as defined in the following IANA RFC:
If no DH Group identity is detected, the ECDHE cipher suites require that a DH Group is chosen to create the ECDHE temporary keys that will be used in the session. The DH Group will be selected automatically. However, you can also configure a prioritized set of DH Groups that will be used in the TLS handshake to negotiate a DH Group to be used with the peer (see the options vbroker.security.server.socket.TLSCipherGroups and vbroker.security.client.socket.TLSCipherGroups).
The vbroker.security.server. socket.ecdheCurve property is now deprecated. It is, however, still supported in this release in order to maintain existing configurations. Its value is treated in the same way as vbroker.security.server.socket.TLSCipherGroups.
This is because a previous ANSI X9.62 standard, Public Key Cryptography For The Financial Services Industry, defined some of the same curves as the IANA list, but with different names. Where this occurs either name can be used in the VisiBroker configuration.
ORB and all its C++ services use a special Logger instance (the ‘Default Logger’ with the name “default”), which is created automatically the first time the ORB logs a message. For more information, refer to the chapter on ‘VisiBroker logging’ in the VisiBroker for C++ Developer’s Guide.
SimpleLogger class is a mechanism to log information of various levels. Currently, it supports four different levels: LEVEL_WARNING, LEVEL_NOTICE, LEVEL_INFO, and LEVEL_DEBUG, with increasingly detailed information. There is only one logger in the whole security service. For information on the SimpleLogger class, see “vbsec::SimpleLogger”.
The default value is "debug".
The default value is "debug".
|
•
|
An applet using IIOP/HTTPS cannot use the X509Certificate[] class to set or examine identities. All certificate and private key administration is handled by the browser. Furthermore, when the ORBalwaysTunnel parameter in the applet tag is set to true, the ORB cannot resolve SSLCurrent objects.
|
|
•
|
To enable an applet to use only IIOP/HTTPS, set ORBalwaysTunnel to true in the HTML page. If ORBalwaysTunnel is set to false (or unspecified) the ORB first tries to use IIOP/SSL, which requires the SSL classes and native SSL library to be installed locally.
|
|
•
|
GateKeeper, by default, does not ask for the client identity. You can enable this function by setting ssl_request_client_certificate to true in the GateKeeper configuration file.
|
|
•
|
GateKeeper, by default, does not ask for the client identity. Although you can enable this function by setting ssl_request_client_certificate=true in the GateKeeper configuration file, you cannot use IIOP/HTTPS because the browser asks for permission before responding with the user's credentials.
|
Internet Explorer optionally requires the Common Name field within the server certificate to be the same as the host name of the server. From the View > Internet Options menu, select the Advanced tab and scroll to the Security section. Make sure the box next to Warn about invalid site certificates is not checked to use a server certificate that does not contain the host name of the server.