![]() |
|
Pramati Server provides support for Secure Sockets Layer (SSL) 3.0. SSL may be used for providing Secure Communications and for Authenticating. Pramati Server SSL provides two key functionalities:
Securing the Server involves ensuring that all communication with the server happens on a secure, encrypted channel. The most common mechanism to trigger the SSL access is using HTTPS.
Pramati Server can be secured using a digital certificate with a public key as Public key cryptography uses certificates to prevent impersonation over a public domain network. Server provides this feature through the standard implementation of Java Secure Sockets Extension 1.0.2 (JSSE). This standard enables you to utilize secure, encrypted communication channels in the applications, which, in turn, simplifies application development by serving as a building block that you can integrate directly into the applications.
JSSE 1.0.2 provides Secure Sockets Layer (SSL) version 3.0, and Transport Layer Security (TLS) version 1.0 support to the Java 2 platform.
In certain critical application installations, there may be a need to ensure that strictly only authorized clients access the server instance and the application. This may be needed over and above the standard J2EE authentication (login) and Authorization mechanisms available to applications.
In Pramati Server, this mode is enabled by requiring a two-way SSL. Two-way SSL requires that both Server and the Client possess valid certificates. A certificate is valid if it is signed by a trusted Certifying Authority (CA). For the Server to trust the Client, the CA signing the client certificate must be registered with the server. In such a case, the Server accepts communication requests from clients posting certificates issued by one of the registered CAs.
For the client to trust the server, the CA signing the client certificate must be registered with the client.
For more details about SSL concepts, read Working with SSL on Pramati Server.
server-config.xml. For both the Standalone Server and Cluster, the file is at <install_dir>/server/nodes/<node_name>/config/.services tag:
<service name="WebContainer" enabled="true" class-name="com.pramati.web.WebServer"> <property name="https-port" value="443"/> </service>
is set as 443. Set this value to the required HTTPS port.web-config.xml. For both the Standalone Server and Cluster, the file is at: <install_dir>/server/nodes/<node_name>/config/.web-container tag: <protocol http-enabled="true" ssl-enabled="false"/><protocol http-enabled="true" ssl-enabled="false"/>. Set ssl-enabled to true as <protocol http-enabled="true" ssl-enabled="true"/>.client-auth-require tag to true. This implies that the Server and the client should trust and authenticate each other's certificates before communication can begin. If you have enabled SSL and disabled client authentication, the Server accepts SSL connections but will not enforce SSL client authentication. Server uses the Trusted CA Certifications keystore to authenticate the client certificate. The client refers to its own trusted keystore to authenticate the Server.client-auth-require tag is present under the <ssl _moz-userdefined=""> tag in web-config.xml.To enable RMI over SSL communication:
server-config.xml. For both the Standalone Server and Cluster, the file is at <install_dir>/server/nodes/<node_name>/config/.ssl-protocol-enabled attribute, present under the rmi-properties tag under the server-node tag is set as false. Set the tag to true.
<server> <server-node name="default" type="J2EE"> <default-login-info username="root" password="pramati" realm="system"/> <rmi-properties socket-time-out="10" export-port="0" ssl-export-port="0" ssl-protocol-enabled="true"/> <class-file-server port="5020"/> <server-node>
needMutualAuthentication property to true. This implies that server and client should trust each other's certificates and authenticate each other before communication begins. Server uses Trusted CA Certifications keystore to authenticate the client certificate. The client refers to its trusted keystore for authenticating the server. This property is optional.needMutualAuthentication property is present under the init-options tag, under the rmi-ssl tag, in the security-config.xml. For both the Standalone Server and Cluster, the file is at <install_dir>/server/nodes/<node_name>/config/.needMutualAuthentication property to true as:
<rmi-ssl>
<other tags>
<init-options>
<entry>
<name>needMutualAuthentication<name>
<value>true<value>
<entry>
<init-options>
<other tags>
<rmi-ssl>
Any communication between server and client now proceeds smoothly.
These certificates are stored in the following two keystores:
servercerts to store the Server Certificates.trustedcacerts to store trusted certificates signed by a Certifying Authority (CA).Both these keystores can be protected with different passwords. The default password is pramati. It is a good practice to change the password periodically. For both the Standalone Server and File-based Clusters, the keystore is located at <install_dir>/server/nodes/<node_name>/config/.
Administrators need a public and private key and a certificate signed from a CA. Pramati Server provides support from the Console for generating server-side certificates. These are self-signed certificates. To make this a trusted certificate, a Certificate Signing Request (CSR) can be generated and sent to a CA, like Verisign, for signing. The signed certificate is imported into the Server keystore.
Table 1: Server certificates
| Fields | Description |
|---|---|
| Alias | An alias name for the Server certificate. |
| Issued By | Name of the issuer of the certificate. |
| Issued To | Name of the requestor the certificate was issued to. |
| Validity | Date upto which the issued certificate is valid. |
| Add | Use this to add a new Server certificate. |
| Delete | Use this to delete a Server certificate. |
| Change keystore Password | Use this to make changes to the keystore password. Read the section ‘Changing the keystore password’ below. |
Table 2: Certification Authority Certified Certificates
| Fields | Description |
|---|---|
| Alias | Alias names for the Certification Authorities trusted by Server. |
| Issued By | Name of the issuer of the certificate. |
| Issued To | Name of the requestor the certificate was issued to. |
| Validity | Date upto which the issued certificate is valid. |
| Add | Use this to add a new Certification Authority certified Certificate. |
| Delete | Use this to delete a Certification Authority certified Certificate. |
| Change keystore Password | Use this to make changes to the keystore password. Read the section Changing the keystore password below. |
Note: You can add certificates to the keystore of the server configuration during runtime using the Console. However, these will take effect only after you restart the server because the SSLSocketFactories are not refreshed.
These certificates assist in:
The Server Certificate is generated. It is stored in the keystore (ServerCerts) and added to the table of server certificates.
Note: Popular browsers Netscape and IE expect the Server certificates to be RSA based. DSA based certificates are not accepted by these browsers. For more information, refer http://java.sun.com/products/jsse/doc/guide/API_users_guide.html.
Once the CSR is generated, the CSR file has to be mailed as an attachment to the CA. The CA adds a public key to the public key sent by you and a chain of certificates is generated.
In the Certificate Signing Request Reply section, select the downloaded file using the browse option. Click Import to import the signed certificate into the Server keystore.
The public key combination is associated with the relevant private key and stored as .cer file in the configuration directory of the Server node. The certificate is now certified.
To export a certificate so that it can be placed in the clients Trusted CA store:
Deploying beans in the secure mode can be applied selectively for individual beans using Deploy Tool. To deploy individual beans in the secure mode:
transport-guarantee tag in the web.xml file. This file is stored in the application’s war file. The transport-guarantee element defines the communication between client and server and can take three values:
If you specify Integral or Confidential, it implies that SSL is required for transmission. For example:
<security-constraint> ....<other tags> <user-data-constraint> <description>No Description<description> <transport-guarantee>Integral<transport-guarantee> </user-data-constraint> <security-constraint>
https://<host on which the server is running>:<port number on which the secured list is started>/<context root>/.
A certificate is sent by Server to the client. This must be accepted by the client for transmission to proceed.
If you do not specify a port number in the URL, the default port 443 is assumed. However, you can configure the port number to any value in the server-config.xml file. For both Standalone Server and cluster, this file is located at <install_dir>/server/nodes/<node_name>/config/.
To configure the HTTPS port:
server-config.xml. The file is located at <install_dir>/server/nodes/<node_name>/config/.services tag:
<service name="WebContainer" enabled="true" class-name="com.pramati.web.WebServer"> <property name="https-port" value="443"/> </service>
is set as 443. Set this value to the required HTTPS port.To access beans deployed using SSL, the Java client must store the Server’s public key in the following key store in the default directory under Java home: java home\jre\lib\cacerts
To perform a secure look up using SSL, the client must set ssl in the security protocol as:
Properties props = new Properties(); props.put(Context.PROVIDER_URL, "rmi://"+Host+":"+details.port); props.put(Context.INITIAL_CONTEXT_FACTORY, "com.pramati.naming.client.PramatiClientContextFactory"); props.put(context.SECURITY_PROTOCOL,"ssl");
Note: Using SSL may slow down the speed of access, hence it is advisable to authenticate specific beans that need to be provided the maximum security.
Client-side certificates are typically generated outside the Server, and signed through a CA that is trusted by the Server. The Console provides the tool to register trusted CAs. The information on trusted CAs is placed in the Trusted CA keystore.
To import a Certificate Certified by the Certification Authority:
web.xmlEnabling two-way SSL
In web-config.xml, under web-container tag, change client-auth-require to true as:
<ssl> <client-auth-require>true</client-auth-require> </ssl>Set up the Trusted CAs in the Server. Add the CA certificate whom the server should trust. The certificates issued to the clients must be from this CA.
Setting up application's web.xml
Application can define a set of pages which can be transported only over HTTPS using web.xml. You can add security-constraint tag in the web.xml to specify the set of URL patterns, which will use HTTPS. Given below is a snippet from web.xml:
<security-constraint> <web-resource-collection> <web-resource-name>txPages<web-resource-name> <description>No Description<description> <url-pattern>/bank/*<url-pattern> <http-method>GET<http-method> <web-resource-collection> <auth-constraint> <description>No Description<description> <auth-constraint> <user-data-constraint> <description>No Description<description> <transport-guarantee>INTEGRAL<transport-guarantee> </user-data-constraint> </security-constraint>
In the above snippet, all the pages which satisfy the given URL pattern will be secured according to user-data-constraint. If the transport-guarantee is INTEGRAL or CONFIDENTIAL, the communication will use HTTPS, else it will be over HTTP.
Enabling two-way SSL
In security-config.xml, under init-options under rmi-ssl define an entry for needMutualAuthentication and set its value to true.
<rmi-ssl> <server-socket-factory> com.pramati.util.socket.DefaultRMISSLServerSocketFactory </server-socket-factory> <client-socket-factory> com.pramati.util.socket.DefaultRMISSLClientSocketFactory </client-socket-factory> <init-options> <entry> <name>needMutualAuthentication<name> <value>true<value> <entry> <init-options> <rmi-ssl>
Setting up VM Properties using Java Client
The Java Client, which is participating in RMI-SSL, must set these properties to VM:
KeyStoreFilePath - Path of the client's certificate store.KeyStorePassword - the password of the key store where client's certificate has been stored.To get the key certified by a third party CA like Verisign, send the certificate signing request to the CA.
CA.sh and sign.sh, are not available in the OpenSSL directory, create the scripts as produced below.ca.key using the command openssl genrsa -des3 -out ca.key 1024ca.crt using the command openssl req -new -x509 -days 365 -key ca.key -out ca.crtThe certificate is stored in X509 format and exported as a .cer file.
sh CA.sh -newreq. This prompts for the information on the client for whom the certificate is generated.
sh sign.sh newreq.pemopenssl rsa newkey.pem openssl pkcs12 -export -in newreq.crt -inkey newkey.pem -out client.p12 openssl pkcs12 -export -in ca.crt -inkey ca.pem -out ca.p12client.p12) to the client machine.client.p12) and click Import.
| © Pramati Technologies 2007 | Runs on Pramati Server | Feedback | Legal |