Back to Contents
Deploying a Client and a Server for HTTPS
- Create the Root Authority's Certificate Signing Request and private key:
$ openssl req -new -out MyCompanyCA.csr -keyout MyCompanyCA.pem
- Create the Root Certificate Authority for a period of validity of 2 years:
$ openssl x509 -trustout -in MyCompanyCA.csr -out MyCompanyCA.crt -req -signkey MyCompanyCA.pem -days 730
Notes:
- The private key file (MyCompanyCA.pem) of a Root Certificate Authority must be handled with care.
This file is responsible for the validity of all other certificates it has signed.
As a result, it must not be accessible by other users.
Return to top
- Create the server's Certificate Signing Request and private key:
$ openssl req -new -out MyServer.csr
Note: By default, openssl outputs the private key in the privkey.pem file.
- Remove the password from the private key:
$ openssl rsa -in privkey.pem -out MyServer.pem
Note: The key is also renamed in MyServer.pem.
- Create the server's Certificate trusted by the Root Certificate Authority:
$ openssl x509 -in MyServer.csr -out MyServer.crt -req -signkey MyServer.pem -CA MyCompanyCA.crt -CAkey MyCompanyCA.pem
Notes:
- The purpose of the server's Certificate is to identify the server to any client
that connects to it. Therefore, the subject of that server's certificate must match the hostname of the server as it is known on the network; otherwise the client will be suspicious about the server's identity and stop the communication. For instance, if the URL of the server is
https:///www.MyServer.com/cgi-bin/fglccgi.exe/ws/r/MyWebService, the subject must be
www.MyServer.com.
Return to top
- Create the client's Certificate Signing Request and private key:
$ openssl req -new -out MyClient.csr
Note: openssl by default, outputs the private key in the privkey.pem file.
- Remove the password from the private key:
$ openssl rsa -in privkey.pem -out MyClient.pem
Note: The key is also renamed in MyClient.pem.
- Create the client's Certificate trusted by the Root Certificate Authority:
$ openssl x509 -in MyClient.csr -out MyClient.crt -req -signkey MyClient.pem -CA MyCompanyCA.crt -CAkey MyCompanyCA.pem
Notes:
- The purpose of the client's Certificate is to identify the client to any
server; therefore the subject of the certificate must correspond to the client's identity as it is known by the servers.
Return to top
- Create the server's Certificate Authority List:
$ openssl x509 -in MyCompanyCA.crt -text >> ServerCAList.pem
Notes:
- As the server trusts only the Root Certificate Authority, the list contains only that one certificate authority; all other certificates that were trusted by the Root Certificate Authority will also be considered as trusted by the server.
Return to top
- Create the client's Certificate Authority List:
$ openssl x509 -in MyCompanyCA.crt -text >> ClientCAList.pem
Notes:
- As the client trusts only the Root Certificate Authority, the list contains only that one certificate authority; all other certificates that were trusted by the Root Certificate Authority will also be considered as trusted by the client.
Return to top
The global certificate authority list entry defines the file containing the certificate authority list that the Genero Web Services client will use to validate all certificates coming from the different servers it will connect to. The certificate authority list entry must be defined as follows:
security.global.ca = "ClientCAList.pem"
Return to top
The client security entry defines the certificate and the associated private key that the Genero Web Services client will use during a communication with a HTTPS server. The security entry must be defined with an unique identifier (id1 in our case).
security.id1.certificate = "MyClient.crt"
security.id1.privatekey = "MyClient.pem"
Notes:
- If the private key is protected with a password, you must remove it or create a script that returns the password on demand.
Return to top
As our server supports HTTP authentication (See RFC 2617 for more details) , it is necessary to define the client login and password with the same value as registered on the server side. The following two entries must be defined with an unique identifier (id2 in our case).
authenticate.id2.login = "fourjs"
authenticate.id2.password = "mypassword"
Return to top
Due to security leaks, it is not recommended that you have a password in clear text. The Genero Web Services package provides
the tool fglpass. This tool encrypts a password with a certificate
that is readable only with the associated private key. To encrypt the HTTP authentication password, do the following:
- Encrypt the clear text password with fglpass using the client certificate:
$ fglpass -c MyClient.crt
Enter password :mypassword
Note: fglpass outputs the encrypted password on the console but can be redirected to a file.
- Modify the HTTP authentication password entry by specifying the security configuration to use to decrypt it (id1 in our case)
authenticate.id2.password.id1="HWTFu8QE2t3e5D4joy7js8mB95oOGTzLmcAor9j5DS+CloiliGCwZvZ9eWpfmIWSON9IwoiJheYxfnu20uaGGmmiUGiHxT6341ePXNSicu32NtlVp9t6RcS0wN/p9a6D4XtiD9iHW7iQvXhqC9uamd3gI9Q3GhHwXOMMlY//c8Y="
Notes:
- The size of the encrypted password depends on the size of the public key, and can change according to the certificate used to encrypt it.
Return to top
The Genero Web Services client needs a set of configuration entries to specify the security configuration
and the HTTP authentication (id1 and id2,
respectively) to use when accessing our server. The following entries must be defined with a unique identifier (myserver in our case):
ws.myserver.url = "https://www.MyServer.com/cgi-bin/fglccgi.exe/ws/r/MyWebService"
ws.myserver.security = "id1"
ws.myserver.authenticate = "id2"
Notes:
- The unique identifier myserver can be used in the 4GL client code instead of the real URL.
Return to top
As the Web Server is in charge of the complete HTTPS protocol with all the
clients, there is no additional GAS configuration needed to add security. Simply register the 4GL server to the list of Web Services of the GAS.
For more information, refer to the Genero Application Server Manual
documentation.
Return to top
You must configure Apache to support HTTPS by adding the required modules. Please refer to the Apache
Web server documentation for more information.
Once the Apache Web server supports HTTPS, you must change or add the following directives to the apache configuration file:
- Set the Apache Web server Certificate Authority List directive created in
Step 4:
SSLCACertificateFile D:/Apache-Server/conf/ssl/ServerCAList.pem
- Set the Apache Web server Certificate and associated private key directives created in
Step 2:
SSLCertificateFile D:/Apache-Server/conf/ssl/MyServer.crt
SSLCertificateKeyFile D:/Apache-Server/conf/ssl/MyServer.pem
- Require the Apache Web server to verify the validity of all client certificates:
SSLVerifyClient require
Notes:
- The Apache Web server must be started on a machine where the host is the same as the one defined in the subject of the server's certificate (www.MyServer.com in our case).
Return to top
You must configure Apache to support HTTP basic authentication by adding the
required modules.
Please refer to the Apache Web server documentation for more information.
Once the Apache Web server supports HTTP basic authentication, you must:
-
Add an user to the Apache Web server basic authentication file with the same login and password as defined in
Step 8.
Apache provides the tool htpasswd that you can use to create the file
and add the user. To add the user fourjs with the password mypassword to a new file called myusers:
$ htpasswd -c myusers fourjs mypassword
Note: to add additional users, remove the option '-c'.
-
Add an Apache Web server location directive that enables you to group several directives for one URL. (In our case, the URL is /cgi-bin/fglccgi.exe/ws/r/MyWebService).
The following example (based on Apache 2.0) defines the HTTP authentication type (Basic), with a user file (user-basic) containing the login and password of those who are allowed to access the service.
<Location /cgi-bin/fglccgi.exe/ws/r/MyWebService>
AllowOverride None
Order allow,deny
Allow from all
#
# Basic HTTP authenticate configuration
#
AuthName "Top secret"
AuthType Basic
AuthUserFile "D:/Apache-Server/conf/authenticate/myusers"
Require valid-user # Means any user in the password file
</Location>For more information about Apache Web server directives, refer to the
Apache Web Server manual.
Return to top