Back to Contents 

Deploying a Client and a Server for HTTPS

       
         Creation of all X.509 certificates
 

       
         Client Configuration

       
         Server Configuration

  

    Step 1:  Create the Root Certificate Authority

    Step 2:  Create the server's certificate and private key

    Step 3:  Create the client's certificate and private key

    Step 4:  Create the server's certificate authority list

    Step 5:  Create the client's certificate authority list

  

    Step 6:  Define the global certificate authority list

    Step 7:  Define the client security configuration

    Step 8:  Define the HTTP authentication configuration

    Step 9:  Encrypt the HTTP authentication password

    Step 10:  Configure the client to access the server

   

  

    Step 11:  Register the server as a Web Service in the GAS

    Step 12:  Configure apache for HTTPS

    Step 13:  Configure apache for HTTP basic authentication

Step 1 : Create the Root Certificate Authority

Notes:
  1. 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.

Back to the top

Step 2 : Create the server's certificate and private key

Notes:
  1. 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.

Back to the top

Step 3 : Create the client's certificate and private key

Notes:
  1. 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.

Back to the top

Step 4 : Create the server's certificate authority list

Notes:
  1. 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.

Back to the top

Step 5 : Create the client's certificate authority list

Notes:
  1. 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.

Back to the top

Step 6 : Define the global certificate authority list

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"

Back to the top

Step 7 : Define the client security configuration

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:
  1. If the private key is protected with a password, you must remove it or create a script that returns the password on demand.

Back to the top

Step 8 : Define the HTTP authentication configuration

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     = "mylogin"
authenticate.id2.password  = "mypassword"

Back to the top

Step 9 : Encrypt the HTTP authentication password

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:

authenticate.id2.password.id1="HWTFu8QE2t3e5D4joy7js8mB95oOGTzLmcAor9j5DS+CloiliGCwZvZ9eWpfmIWSON9IwoiJheYxfnu20uaGGmmiUGiHxT6341ePXNSicu32NtlVp9t6RcS0wN/p9a6D4XtiD9iHW7iQvXhqC9uamd3gI9Q3GhHwXOMMlY//c8Y="
Notes:
  1. 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.

Back to the top

Step 10 : Configure the client to access the server

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:
  1. The unique identifier myserver can be used in the 4GL client code instead of the real URL.

Back to the top

Step 11 : Register the server as a Web Service in the GAS

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.

Back to the top

Step 12 : Configure apache for HTTPS

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:

Notes:
  1. 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).

Back to the top

Step 13 : Configure apache for HTTP basic authentication

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:

  1. 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 mylogin with the password mypassword to a new file called myusers:
    $ htpasswd -c myusers mylogin mypassword
    Note: to add additional users, remove the option '-c'.

  2. 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.

Back to the top