Support for client side digital certificates with SSL

RealHeavyDude

Well-Known Member
AFAIK client side digital certificates with SSL are not supported in the OpenEdge product.


Background information:

We are running OpenEdge 10.1c on WindowsXP clients and AppServers and databases on Sun Solaris 10 64Bit servers. In our portfolio we have 40+ applications out of which 1/3 is developed in Dynamics and the other ones are developed with another framework utilizing client/server technology.

In our environment ( banking / financial services ), for any Software solution that processes data which is not classified as "publicly available" to be compliant with the internal SOX control standards it is mandatory to use strong authentification. Strong authentification means that the user is authenticated with something she/he knows ( a password ) and something he/she has ( a smart card which has a personalized SSL certificate stored on it ).

Therefore, in order to be compliant, our OpenEdge GUI applications must make use of the client side SSL certificat to authenticate the users. That would be, during the SSL handshake, the client passing the certificate which is stored on the smart card on to the server ( AppServer or database ) and that server validating that certificate for a successful SSL connection.


Are there any recommendations for work arounds?Is there anybody out there which has successfully implemented a workaround?

Thanks in advance and best regards,
RealHeavyDude.
 
Thanks for that!

I am just beginning to develop an idea ...

Since the OpenEdge servers (AppServer and Database) don't support the client certificate ... if I could use the OpenSSL command line utility to try a connection to a server (WebSphere MQ for example which is used as the messaging middleware in our company) that is capable to handle the client certificate ... and determine whether the user is authenticated ... in assuming that, if the connection succeeds then the user is authenticated ...

Thanks, RealHeavyDude.
 
Release 10.2A: OpenEdge Data Management:
Database Administration
Database server SSL connection parameters

Use the parameters listed in Table 18–6 to control the use of SSL.

Table 18–6: Database server SSL parameters
Parameter
Syntax
Purpose
SSL
-ssl
Requires that all brokers and all connections use SSL
Note: SSL incurs heavy performance penalties, depending on the client, server, and network resources and load. Key Alias
-keyalias key-alias-name
Specifies the alias name of the SSL private key/digital certificate key-store entry to use
Key Alias Password
-keyaliaspasswd key-alias-password
Specifies the encrypted password to the key alias
No Session Cache
-nosessioncache
Disables the use of SSL session caching
Session Timeout
-sessiontimeout n
Specifies the length of time in seconds that an SSL session is held in the session cache
 
SSL (-ssl)



Operating system
and syntax
UNIX
Windows
-ssl
Use
with
Maximum value
Minimum value
Single-user default
Multi-user default
DBS






Use SSL (-ssl) to specify that all database and client connections use the Secure Sockets Layer (SSL) for data privacy. SSL provides an authenticated and encrypted peer-to-peer TCP/IP connection.
Note: SSL incurs heavy performance penalties, depending on the client, server, and network resources and load. For more information on SSL and the security features of OpenEdge, see OpenEdge Getting Started: Core Business Services .
 
Secure Sockets Layer (SSL)

SSL has been widely accepted on the Internet as the preferred, secure protocol to authenticate and encrypt communication between clients and servers. Where HTTPS only secures individual messages, SSL secures the points of origin and destination for any amount of data that can be transmitted between a client and server. This protocol further complements and extends the security measures available to protect the confidentiality of your communications.
The SSL protocol resides above the network protocol, as defined by Transmission Control Protocol/Internet Protocol (TCP/IP), and directly below the application protocols, such as HTTP, HTTPS, or IMAP. It uses TCP/IP on behalf of the application protocols and, in the process, enables the following activities to occur:

  • An SSL-enabled server can authenticate itself to an SSL-enabled client.
  • An SSL-enabled client can authenticate itself to an SSL-enabled server.
  • The SSL-enabled server and client can establish an encrypted connection.

OpenEdge supports SSL communications between the WebSpeed Messenger and the WebSpeed Transaction Server, as described in the next section.
SSL-enabled WebSpeed Transaction Server operation

You have the option of configuring any WebSpeed Transaction Server instance to require Secure Sockets Layer (SSL) client connections. You can maintain both SSL-enabled and non-SSL Transaction Server instances, but a given instance supports only one type of connection, either secure or non-secure.
Security derives from the client authentication of the server's identity via a Public Key Infrastructure (PKI) and a symmetric data encryption system. To configure a Transaction Server instance for SSL operation, you must:

  • Obtain and install a server private key and a public key certificate. OpenEdge provides built-in keys and certificates that are suitable for use on development or demonstration servers; for production machines, you should obtain server certificates from an internal or public Certificate Authority (CA).
  • Specify an alias and password for access to the private key/digital certificate.
  • Disable session caching, or enable it with a specified timeout.

To connect to an SSL-enabled WebSpeed Transaction Server, a WebSpeed Messenger must have access to a digital (public key) certificate (often called a CA Root Certificate) that can authenticate with the digital certificate used by the server, and the Messenger must be configured to send SSL requests.
To perform these configuration tasks, you can use the Progress Explorer (in Windows only) or manually edit the ubroker.properties file, as explained in the next section.
SSL configuration for WebSpeed components

To enable SSL communications, you must configure both the WebSpeed Messenger and the WebSpeed Transaction Server. Configure the Messenger as follows:

  • The Messenger must be SSL-enabled, meaning that it sends SSL data to the Transaction Server that is to process the client requests. To configure the Messenger to send SSL requests, you set the property sslEnable=1. You set this property by checking the Enable SSL AppServer connections box in the SSL properties category in the Progress Explorer, or by manually editing the ubroker.properties file. In addition, you must obtain and install public key certificates for the Messenger host machine.
  • Determine whether you want the Messenger to verify the host name for the WebSpeed Transaction Server by comparing it with the Common Name specified in the server digital certificate, and raise an error if they do not match (the default behavior). You can disable this verification by setting the property noHostVerify=1. To do so, check the Disable Client Verification of SSL Host Name box in the Progress Explorer, or manually edit the ubroker.properties file.
  • Determine whether you want the Messenger to request reuse of the session ID for successive connections to the same Transaction Server (the default behavior). If not, set the property noSessionReuse=1, either by checking the Disable SSL Session Reuse box in the Progress Explorer or by editing the ubroker.properties file. (The default behavior does not guarantee that session IDs can be reused, because the server might disallow session reuse.)

Configure the Transaction Server as follows:

  • The Transaction Server must be SSL-enabled, meaning that it accepts SSL requests from the Messenger. You set the property sslEnable=1 by checking the Enable SSL Client Connections box in the SSL General properties category in the Progress Explorer, or by manually editing the ubroker.properties file. You must also obtain and install a server private key and public key certificate, unless you are using the defaults provided with OpenEdge.
  • In the SSL General properties category in the Progress Explorer, select the alias for the private key/digital certificate entry (in the OpenEdge keystore) that you want to secure connections for this Transaction Server. Also enter and confirm the password for this private key and digital certificate. You need not enter a password if you choose to use the default_server certificate and its default password. (Note: The password is encrypted in the ubroker.properties file; if manually editing the file, you must use the genpassword utility to encrypt the password. The properties appear in the file as keyAlias= and keyAliasPasswd=.)
  • In the SSL Advanced Features properties category in the Progress Explorer, you can enter a timeout value that specifies the length of time (in seconds) that a disconnected session is held in the cache. During this specified interval, a connected client can resume its session. To disable session caching, check the box, or edit the ubroker.properties file and set the property noSessionCache=0. The timeout value appears in the file as sessionTimeout=n.

For more information on setting properties for WebSpeed Messengers and Transaction Servers and other Unified Broker products, see the Progress Explorer help or the OpenEdge-Install-Directory\properties\ubroker.properties.README file.
 
Thanks.

We already use SSL connection to AppServers and the Databases with our own server certificates. AFAIK, this is "standard" SSL - the server provides the client with its certificate to prove its identity. No we must implement the client proofing its identity to server in using the client side certificate - which is not supported by any Progress product out now ...

Thanks and best regards,
RealHeavyDude.
 
Back
Top