Table of Contents
By default, WebtoB supports both authentication and SSL (Secure Socket Layer) which are popular web security features that protect client information and prevent data leakage. They are required features of e-commerce websites and are supported by most web servers.
Authentication method is quite simple. A client sends a user name and password to a web server. The web server verifies the user name and password exist in an encrypted password file. If the user name and password found in the encrypted file match, the user is authenticated.
Authentication can be done individually or in user groups. Configuring the authentication for all users is also possible. Browser and server interaction is as follows.
First, a user connects to a server and requests a document. The classified document can only be accessed by users with permission. The server responds back to user with the "Authentication Required [HTTP 401]" alert. The user inputs its user name and password, which the web server authenticates. Because user name and password are sent to the server via Internet, there is a risk of information leakage. Thus, the user name and password are encrypted when sent to the server.
WebtoB supports SSL (Secure Socket Layer), a popular security measure among e-commerce websites. This section describes SSL and then describes how to use SSL in WebtoB. SSL is provided by most web servers, making it convenient to use it.
SSL uses X.509 certificates to authenticate communication between server and client. SSL varies in terms of key length: 40 bit and 128 bit. Because 40 bit key SSL is not reliably secure, 128 bit key SSL is recommended. The current SSL version is 3.0.
SSL is a layer based protocol. A message in each layer can contain a length, description, and content fields. When a message is sent through SSL, SSL divides the message into manageable sized blocks and selectively compresses the data. SSL then adds MAC (Message Authentication Codes) to the compressed data and transmits the resulting data. When the data arrives, the data is decrypted and the MAC is authenticated. SSL then decompresses the data to its original form. Afterwards, SSL rearranges blocks and sends the resulting message to the upper level.
To connect to a web server that supports SSL, instead of using the ubiquitous URL expression "http://*", "https://*" must be used. "http" uses Port 80, whereas SSL based "https" uses Port 443, allowing a single web browser to use both of "http://*" and "https://*" at a same time.
Before SSL is fully working, groundwork is performed at the "handshake" stage.
The groundwork is as follows.
Client and server exchange their certificates. The signature and expiration date of each certificate is then checked.
The client generates a private key that is used for encryption and MAC generation. The key is then encrypted with the server's public key and sent to the server.
When receiving services, the client specifies the encryption algorithm and hash function type to be used. During this process, the client offers the server a list of encryption algorithms that can be supported. The server chooses an algorithm from the list.
SHTTP is a protocol developed by EIT (Enterprise Integration Technology). In SHTTP, headers are added to existing HTTP protocols for security functions. Whereas SSL receives encryption and authentication in units of services, SHTTP receives encryption and authentication in units of messages.
Similar to SSL, encryption and the encryption level can be selected among various encryptions while the client makes a connection to the server using SHTTP.
Characteristics of SHTTP encryptions and algorithms supported by SHTTP are as follows.
Uses RSA, Diffie-Hellman or Kerberos authentication.
Public key certificate: X.509 or PKCS-6
Digital signature algorithm: RSA or DSA(Digital Signature Algorithm).
Encryption must be done in either 40 bit or 128 bit key length encoding. The longer the key length, the more secure the encryption. Web servers generally support internal 128 bit encoding. In order to support 128 bit encryption, both the server and client must support it.
A cipher is an algorithm used in encryption. In general when a cipher encrypts data, the more bits that are used, the harder the data becomes to decrypt. In any bilateral encryption process, both parts must use the same cipher. Many kinds of ciphers exist and a server must support the most popular. If a client tries a SSL connection to a server, the client notifies the server of its preferred cipher.
WBSSL currently supports the following ciphers:
Cipher suite Protocols KeyExch. Authen. Encryption Mac ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH RSA AESGCM(256) AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 ECDH ECDSA AESGCM(256) AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH RSA AES(256) SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 ECDH ECDSA AES(256) SHA384 ECDHE-RSA-AES256-SHA SSLv3 ECDH RSA AES(256) SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 ECDH ECDSA AES(256) SHA1 SRP-DSS-AES-256-CBC-SHA SSLv3 SRP DSS AES(256) SHA1 SRP-RSA-AES-256-CBC-SHA SSLv3 SRP RSA AES(256) SHA1 SRP-AES-256-CBC-SHA SSLv3 SRP SRP AES(256) SHA1 DH-DSS-AES256-GCM-SHA384 TLSv1.2 DH/DSS DH AESGCM(256) AEAD DHE-DSS-AES256-GCM-SHA384 TLSv1.2 DH DSS AESGCM(256) AEAD DH-RSA-AES256-GCM-SHA384 TLSv1.2 DH/RSA DH AESGCM(256) AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH RSA AESGCM(256) AEAD DHE-RSA-AES256-SHA256 TLSv1.2 DH RSA AES(256) SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 DH DSS AES(256) SHA256 DH-RSA-AES256-SHA256 TLSv1.2 DH/RSA DH AES(256) SHA256 DH-DSS-AES256-SHA256 TLSv1.2 DH/DSS DH AES(256) SHA256 DHE-RSA-AES256-SHA SSLv3 DH RSA AES(256) SHA1 DHE-DSS-AES256-SHA SSLv3 DH DSS AES(256) SHA1 DH-RSA-AES256-SHA SSLv3 DH/RSA DH AES(256) SHA1 DH-DSS-AES256-SHA SSLv3 DH/DSS DH AES(256) SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 DH RSA Camellia(256) SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 DH DSS Camellia(256) SHA1 DH-RSA-CAMELLIA256-SHA SSLv3 DH/RSA DH Camellia(256) SHA1 DH-DSS-CAMELLIA256-SHA SSLv3 DH/DSS DH Camellia(256) SHA1 GOST2001-GOST89-GOST89 SSLv3 GOST GOST01 GOST89(256) GOST89 GOST94-GOST89-GOST89 SSLv3 GOST GOST94 GOST89(256) GOST89 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH/RSA ECDH AESGCM(256) AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 ECDH/ECDSA ECDH AESGCM(256) AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 ECDH/RSA ECDH AES(256) SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 ECDH/ECDSA ECDH AES(256) SHA384 ECDH-RSA-AES256-SHA SSLv3 ECDH/RSA ECDH AES(256) SHA1 ECDH-ECDSA-AES256-SHA SSLv3 ECDH/ECDSA ECDH AES(256) SHA1 AES256-GCM-SHA384 TLSv1.2 RSA RSA AESGCM(256) AEAD AES256-SHA256 TLSv1.2 RSA RSA AES(256) SHA256 AES256-SHA SSLv3 RSA RSA AES(256) SHA1 CAMELLIA256-SHA SSLv3 RSA RSA Camellia(256) SHA1 PSK-AES256-CBC-SHA SSLv3 PSK PSK AES(256) SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH RSA AESGCM(128) AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 ECDH ECDSA AESGCM(128) AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH RSA AES(128) SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 ECDH ECDSA AES(128) SHA256 ECDHE-RSA-AES128-SHA SSLv3 ECDH RSA AES(128) SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 ECDH ECDSA AES(128) SHA1 SRP-DSS-AES-128-CBC-SHA SSLv3 SRP DSS AES(128) SHA1 SRP-RSA-AES-128-CBC-SHA SSLv3 SRP RSA AES(128) SHA1 SRP-AES-128-CBC-SHA SSLv3 SRP SRP AES(128) SHA1 DH-DSS-AES128-GCM-SHA256 TLSv1.2 DH/DSS DH AESGCM(128) AEAD DHE-DSS-AES128-GCM-SHA256 TLSv1.2 DH DSS AESGCM(128) AEAD DH-RSA-AES128-GCM-SHA256 TLSv1.2 DH/RSA DH AESGCM(128) AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH RSA AESGCM(128) AEAD DHE-RSA-AES128-SHA256 TLSv1.2 DH RSA AES(128) SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 DH DSS AES(128) SHA256 DH-RSA-AES128-SHA256 TLSv1.2 DH/RSA DH AES(128) SHA256 DH-DSS-AES128-SHA256 TLSv1.2 DH/DSS DH AES(128) SHA256 DHE-RSA-AES128-SHA SSLv3 DH RSA AES(128) SHA1 DHE-DSS-AES128-SHA SSLv3 DH DSS AES(128) SHA1 DH-RSA-AES128-SHA SSLv3 DH/RSA DH AES(128) SHA1 DH-DSS-AES128-SHA SSLv3 DH/DSS DH AES(128) SHA1 DHE-RSA-SEED-SHA SSLv3 DH RSA SEED(128) SHA1 DHE-DSS-SEED-SHA SSLv3 DH DSS SEED(128) SHA1 DH-RSA-SEED-SHA SSLv3 DH/RSA DH SEED(128) SHA1 DH-DSS-SEED-SHA SSLv3 DH/DSS DH SEED(128) SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 DH RSA Camellia(128) SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 DH DSS Camellia(128) SHA1 DH-RSA-CAMELLIA128-SHA SSLv3 DH/RSA DH Camellia(128) SHA1 DH-DSS-CAMELLIA128-SHA SSLv3 DH/DSS DH Camellia(128) SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH/RSA ECDH AESGCM(128) AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 ECDH/ECDSA ECDH AESGCM(128) AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 ECDH/RSA ECDH AES(128) SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 ECDH/ECDSA ECDH AES(128) SHA256 ECDH-RSA-AES128-SHA SSLv3 ECDH/RSA ECDH AES(128) SHA1 ECDH-ECDSA-AES128-SHA SSLv3 ECDH/ECDSA ECDH AES(128) SHA1 AES128-GCM-SHA256 TLSv1.2 RSA RSA AESGCM(128) AEAD AES128-SHA256 TLSv1.2 RSA RSA AES(128) SHA256 AES128-SHA SSLv3 RSA RSA AES(128) SHA1 SEED-SHA SSLv3 RSA RSA SEED(128) SHA1 CAMELLIA128-SHA SSLv3 RSA RSA Camellia(128) SHA1 IDEA-CBC-SHA SSLv3 RSA RSA IDEA(128) SHA1 PSK-AES128-CBC-SHA SSLv3 PSK PSK AES(128) SHA1 ECDHE-RSA-RC4-SHA SSLv3 ECDH RSA RC4(128) SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 ECDH ECDSA RC4(128) SHA1 ECDH-RSA-RC4-SHA SSLv3 ECDH/RSA ECDH RC4(128) SHA1 ECDH-ECDSA-RC4-SHA SSLv3 ECDH/ECDSA ECDH RC4(128) SHA1 RC4-SHA SSLv3 RSA RSA RC4(128) SHA1 RC4-MD5 SSLv3 RSA RSA RC4(128) MD5 PSK-RC4-SHA SSLv3 PSK PSK RC4(128) SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 ECDH RSA 3DES(168) SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 ECDH ECDSA 3DES(168) SHA1 SRP-DSS-3DES-EDE-CBC-SHA SSLv3 SRP DSS 3DES(168) SHA1 SRP-RSA-3DES-EDE-CBC-SHA SSLv3 SRP RSA 3DES(168) SHA1 SRP-3DES-EDE-CBC-SHA SSLv3 SRP SRP 3DES(168) SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 DH RSA 3DES(168) SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 DH DSS 3DES(168) SHA1 DH-RSA-DES-CBC3-SHA SSLv3 DH/RSA DH 3DES(168) SHA1 DH-DSS-DES-CBC3-SHA SSLv3 DH/DSS DH 3DES(168) SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 ECDH/RSA ECDH 3DES(168) SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 ECDH/ECDSA ECDH 3DES(168) SHA1 DES-CBC3-SHA SSLv3 RSA RSA 3DES(168) SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 PSK PSK 3DES(168) SHA1
In an open network, the encryption of user data and user identification can be performed using a public key encryption algorithm. The core of this algorithm is composed of an encryption key and a decryption key.
A private key is the decryption key which is held private by the decrypting party. The public key is publicly available so that other people can send message to the private key holder by using the matching public key. Verifying that the public key is owned by the actual user is a potential problem. Certification Authority, CA is the institute that validates public keys.
Certification Authority is a third party trusted by both message sender and receiver. A certificate from Certification Authority is exchanged between sender and receiver. The certificate is validated before the sender and receiver are authenticated and then the message is encrypted. Three types of certificates can be issued from CA: CA Root Certificate, Web Server Certificate, and User Certificate.
Certificate is a widely recognized guarantee of the identity of a software, organization, or person. A certificate helps a user to verify a server is trustworthy. Likewise, a server needs to know whether a user is trustworthy or not.
Both server and client certificates exist. A certificate contains its certification authority and where the certificate can be validated. A certificate is generally used to validate a user and to secure user data. A certificate used as a digital signature has legal significance in some countries.
An online certificate is a document that contains information about its certification object. An online certificate can be created personally, or by a certification authority. Online certificates follow the ITU (International Telecommunication Union) X.509 format or the RSA Data Security PKCS-6 and PEM format. Online certificates often have the filename "cert.crt". Generally, this file excludes a private key and holds just a public key.
The following is an example of PKCS-6.
Certificate: Data: Version: 0 (0x0) Serial Number: 02:41:00:00:01 --------------------------- ① Signature Algorithm: MD2 digest with RSA Encryption ----- ② Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority ---------------- ③ Validity: Not Before: Wed Nov 9 15:54:17 1994 Not After: Fri Dec 31 15:54:17 1999 --------------------- ④ Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject Public Key Info: Public Key Algorithm: RSA Encryption Public Key: Modulus: 00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25: 01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03: e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86: 37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9: 4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07: 65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48: b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49: dd:2d:d6:c8:1e:7b Exponent: 65537 (0x10001) Signature Algorithm: MD2 digest with RSA Encryption Signature: 88:d1:d1:79:21:ce:e2:8b:e8:f8:c1:7d:34:53:3f:61:83:d: b6:0b:38:17:b6:e8:be:21:8d:8f:00:b8:8b:53:7e:44:67:1: 22:bd:97:27:e0:9c:85:cc:4a:f6:85:3b:b2:e2:be:92:d3:e: 0d:e9:af:5c:0e:0c:46:95:ff:a1:1c:5e:3e:e8:36:58:7a:7: a6:0a:f8:22:11:6b:c3:09:38:7e:26:bb:73:ef:00:bd:02:a: f3:14:0d:30:3f:61:70:7b:20:fe:32:a3:9f:b3:f4:67:52:d: b4:ee:84:8c:96:36:20:de:81:08:83:71:21:8a:0f:9e:a9
In the sample certificate,
① is the certificate serial number.
② indicates the certificate uses the RSA encryption algorithm and the MD2 (Message Digest 2) message compression algorithm.
③ displays information about the certificate authority: C (country), O (organization), and OU (organization unit).
| Category | Description |
|---|---|
| C | country |
| O | Organization |
| OU | Organization Unit |
④ shows that this certificate is valid from November 9, 1994 15:54:17 to December 31, 1999 15:54:17. CA, or Certificate Authority, is a server of the organization that issues certificates.
Secure communication requires a certificate for both client and server. The certificate is a guarantee to a client that the server will provide the right service. The certificate guarantees to a server that the client is the actual requester. The server is obligated to issue a certificate and may request a certificate from a client based on the certificate issuing policy.
In general, there are four types of certificate issuing policies.
No certificate required.
Client can optionally provide a valid certificate. If a certificate is provided, it should be verified by the CA (Certification Authority) and match the certificate held by the server.
Client must provide a valid certificate
Client can optionally provide a valid certificate. If a certificate is provided, it does not need to be verified by the CA (Certification Authority) and match the certificate held by the server.
Generally, websites that require a user ID and password do not require a certificate (certificate issuing policy 0), where secure communication is based on the server certificate. On more secure websites, such as online banking sites, certificate issuing policy type 1 is used. In order to use this service, click on [Submit Certificate] to submit the certificate to the website. (Generally, a browser can provide the certificate without direct user action.) An electronic bankbook is executed, the server is issued a certificate, and mutual authentication is acquired. Using a certificate is safer than type 0, which only requires a password.
Certificate issuing policy type 1 is similar to how ATM machines are used. An ATM machine takes a card issued from the bank and a password to complete transactions. The card issued from bank is similar to a certificate.
Verisign is the most famous private certificate authority in the world. SSL Server Certificates can be purchased from the Verisign homepage (www.verisign.com). An SSL Certificate can be either purchased or a trial certificate can be downloaded. Purchasing a certificate, however, requires additional steps.
A certificate is a guarantee from the certifying organization. Hence, when purchasing a certificate, Verisign requests a business license. If the business is registered in D&B Business Database (Dun & Bradstreet), this step can be very simple. Most of the registered businesses currently are U.S companies.
This section describes how to use SSL, and the commands used in authentication.
Setting up authentication in WebtoB is covered in the AUTHEN section in the environment configuration. Refer to "3.15. AUTHENT Section" for more information.
Besides using the WebtoB configuration to authenticate, a valid user name and password are required. Use the wsmkpw executable file to create a user name and password. wsmkpw is located under the "bin/" directory, where WebtoB is installed.
The following are wsmkpw usage and descriptions of options.
$ wsmkpw [-d] [-p passwd] [-r realm] <file_path> <username>
Item
| Item | Description |
|---|---|
| file_path | Full path to the certificate file |
| user_name | User name to be used for authentication |
Option
| Option | Description |
|---|---|
| [-d] | Creates a password to authenticate as Digest. |
| [-p passwd] | The password is entered as an option of a command. If this option is used, the password is exposed in the terminal and may be recorded in a log. |
| [-r realm] | Configures the realm for Digest authentication. |
The following is an example of creating a file named passwd in the directory "/data1/gloria/webtob/auth" and saving a new user named "newuser". The password is encrypted and stored internally. WebtoB uses this file for authentication.
wsmkpw /data1/gloria/webtob/auth/passwd newuser New Password: ***** Retype Password: *****
If the passwd file is specified in the UserFile item of the AUTHENT section in the WebtoB environment configuration, WebtoB uses this file for authentication.
After registering the user name and password by using wsmkpw, add the user name and password to the desired item. Whenever a user requests the item, WebtoB executes the authentication process.
This type of authentication was at one point very popular for its simplicity. However, because the encryption algorithm is simple and easy to decrypt, this authentication process is poor for e-commerce websites. Moreover, in some cases user passwords were leaked onto the internet and decrypted by hackers, resulting in a demand for a more secure authentication and encryption method. In response to this problem, Netscape developed Secure Socket Layer.
To enable authentication and SSL in WebtoB, the environment file must be modified.
The AUTHENT section, which defines the authentication security in WebtoB, must first be defined. In addition, the items defined in the AUTHENT section must also be defined in each server group. Authentication can be configured in each server group unit.
If a user requires authentication for CGI, define the authentication name in the AUTHENT section of the server group where CGI is defined. Refer to "3.15.1. Configuration Items" for more information.
The following shows how to configure the AUTHENT section.
*AUTHENT
AUTHENT name Type,
UserFile
| Item | Description |
|---|---|
| AUTHENT name | Specifies the name. |
| Type | Specifies the encryption method. Commonly used encryption methods are Basic, Digest, MD5, and RSA. WebtoB supports Basic and Digest. |
| UserFile | Specifies the password file created by wsmkpw. Because the password file is used by the AUTHENT section, the file position must be written. The password file must be created before being used. |
The following is an example of the AUTHENT section configuration.
*AUTHENT
authent1 Type = Basic,
UserFile = "/usr/local/webtob/bin/pwfile"
Once the environment file is configured as the example shown previously, authentication is ready for use. The final step is to connect the items defined in the AUTHENT section. The WebtoB configuration item used by the user is 'AUTHENT name'. The 'AUTHENT name' item is used to implement the authentication method defined in the AUTHENT section. Refer to "3.15. AUTHENT Section" for more information on configuration.
The following is an example of configuring authentication for CGI. (authent1 is configured in the previous example.)
*SVRGROUP
cgig NodeName = webmain, SvrType = CGI,
AuthentName = authent1
In the previous example, WebtoB executes authentication whenever a client requests a CGI service. Note that this authentication is performed in the server group unit. Therefore, if CGI group is configured, all corresponding servers execute authentication. For a single, specific CGI to execute authentication, two server groups must be configured.
The following is an example.
*SVRGROUP
cgig NodeName = webmain, SvrType = CGI
cgig_authent NodeName = webmain, SvrType = CGI,
AuthentName = authent1
*SERVER
cgi1 SvgName = cgig
cgi2 SvgName = cgig_authent
*URI
uri1 Uri = "/cgi-bin/", SvrType = CGI,
SvrName = cgi1
uri2 Uri = "/cgi/", SvrType = CGI,
SvrName = cgi2
*ALIAS
alias1 Uri = "/cgi-bin/",
Realpath = "${WEBTOBDIR}/cgi-bin/"
alias2 Uri = "/cgi/",
Realpath = "${WEBTOBDIR}/cgi/"
After configuring the two groups as shown in the previous example, configure the server group cgig_authent for authentication and configure other servers using cgig. This configuration is applied to all that can be specified in the SVRGROUP section.
WebtoB requires additional configurations for SSL. Similar to authentication and logging, SSL is configured in its own dedicated section. Refer to "3.17. SSL Section" for more information.
In order for WebtoB to use SSL, SslFlag must be configured in the NODE section or in the VHOST section where the Virtual Host will use SSL. By default, WebtoB is not set to use SSL.
SslFlag item is a boolean value. 'SslFlag = Y' triggers the use of SSL. Because the WebtoB is set to not use SSL by default, setting SslFlag to 'N' is unnecessary.
The following is an example of using the SslFlag item.
SslFlag = Y
After setting SslFlag to Y, SSL must be configured.
The following is the format of SSL section.
*SSL
SSL NAME Certificatefile, CertificateKeyFile,
CACertificatePath, CACertificateFile,
VerifyDepth, VerifyClient, RandomFile,
...
The previous example is the basic format for SSL configuration. Each SSL should be configured similarly to the AUTHENT section configuration. For the SSL configuration, SSLNAME item is used. Specify the SSLNAME item the same as the SSL section configuration.
Be careful, authentication must be set in the SVRGROUP section and the SSL section must be set in the NODE section or the VHOST section where SSL is used.
The following is an example of specifying the SslName item.
SslName = "ssl1"
Define the ssl1 item in the SSL section. The following is an example of SSL section configuration.
*SSL
ssl1 CertificateFile = "/user/webtob/ssl/newcert.pem",
CertificateKeyFile = "/user/webtob/ssl/newcert.pem",
RandomFile = "/user/webtob/bin/.rnd, 2048",
RandomFilePerConnection = "/user/webtob/bin/.rnd, 512",
VerifyClient = 0,
VerifyDepth = 10,
FakeBasicAuth = Y
The following is an example of applying SSL. In order to use SSL in the NODE section, configure the SslFlag and SslName item.
*NODE
test WebtoBDir = "/user/webtob",
SHMKEY = 69000,
HTH = 1,
Port = "80",
SslFlag = Y,
SslName = "ssl1",
...
In the example, the NODE is set to service SSL using "ssl1", which is configured in the SSL section.