GlassFish v3 and EJBCA 3.x a fair couple for mutual SSL authentication.

Please use the following articles while I am updating this entry

  1. How to have your Own CA and configure Glassfish and your clients for mutual authentication?
  2. How to have your Own CA and configure Glassfish and your clients for mutual authentication?, Part II

Please post any comment or question here so we can have one main reference for this.

How to prepare for, and install GoDaddy SSL certificate into GlassFish v3

Here are steps showing you how to prepare and install a SSL certificate purchased from Godaddy into GlassFish v3 server. To learn more about Godaddy certificates and step to buy a certificate you need to take a look at http://www.godaddy.com/ssl/ssl-certificates.aspx?app_hdr=. After you understand what Godaddy offer and whether it suites your requirement you can use the following steps to get and install the certificate into GlassFish.

  • Generate a keypair for your server using the following command. This command will generate a keypair and store it into a keystore of type JKS. later on we will submit the public key portion and other details provided during the key generation to a CA to sing it for us.
  • keytool -keysize 2048 -genkey -alias wwww.domain.com -keyalg RSA -dname "CN=wwww.domain.com,O=company,L=city,S=State,C=Countery" -keypass changeit -storepass changeit -keystore server.keystore

     

  • You may check whether you entered correct information in the key generation phase by checking the key using the following command:
  • keytool -list -v -alias wwww.domain.com -keystore server.keystore

     

  • Generate a CSR which you should submit to Godaddy to sing it for you. This CSR contains the public key which matchs the private key you generated previously.:
  •  

    keytool -certreq -alias www.domain.com -keystore server.keystore -storepass changeit -keypass changeit -file server-2048.csr

    Now, before you submit the CSR, make sure that you backed-up the server.keystore in a safe place because it contains your PK and if you lose it your certificate will be useless. Make sure that the file is in a safe place because if a malicious person gets his hands on it you will be in trouble unless you change your certificate. Using the PK included in that file anyone, with basic knowledge, can decrypt messages encrypted with your public key.

    Now that you created a backup of the server.keystore and purchased your certificate from godaddy its time to import them into designated keystores. Note that godaddy will give you a certificate named something like domain.com.crt, you will need to download godaddy CA certificates from its repository located at https://certs.godaddy.com/repository/. You will need to download the following ones:

    Now place all of the following files into a $domain.dir and fire a terminal (cmd) and execute the following commands:

  • Import the root certificate into the glassfish key store to make it possible for the secondary certificates to get validated. The keytool may tell you that the certificate already exists in the global ca cert store. If so, do not import this one:
  • keytool -import -alias root -keystore keystore.jks -trustcacerts -file valicert_class2_root.crt

     

  • import secondary CA certificates into the keystore to make it possible for the server certificate signed by godaddy to validated and accepted.
  • keytool -import -alias cross -keystore keystore.jks -trustcacerts -file gd_cross_intermediate.crt

    keytool -import -alias intermed -keystore keystore.jks -trustcacerts -file gd_intermediate.crt

  • import the server certificate into tke keystore. Make sure that the alias used for the certificate must be same as the alias used for the PK. otherwise the validation chain wont get completed and therefore the certificate won’t be imported into the keystore.

keytool -import -alias www.domain.com -keystore keystore.jks -trustcacerts -file shoptalkk.com.crt

The certificate installation is finished, the only left step is chaning the certificate nickname in your domain.xml file to the new alias name we used in the above commands.

  • Make sure that the domain is stopped using asadmin stop-domain domain_name
  • create a backup of the domain.xml
  • Open domain.xml in a text editor like gedit, kate or wordpad and replace all occurrence of s1as with www.domain.com which is the certificate alias
  • save the domain and start the domain in verbose mode using asadmin start-domain –verbose domain_name
  • Open https://server:8181/ and see whether it works properly or not. if you use the exact https://domain.com:8181/ you should get no warning and the whole thing should work properly. If you use https://localhost:8181/ you will get a warning about a misused certificate. it will explain that the certiificate is issued for www.domain.com but it is installed on localhost….

How to Secure GlassFish installation, Part II

In order to secure the application server you need to secure its communication ways with outside world, It means you will need to secure all ports and listeners.

There are 3 kind of listeners in Glassfish application server that you will need to take care of them

First of all make sure that you secured the administration listener, make sure that you have enabled Security for administrator listener and set an specific IP address for it to listen on. Usually we are not going to use administration console from outside of the internal network, so let it listen only on interfaces that you need it to listen perhaps the interface that connect the server to your LAN. In order to do this, open administration console and navigate to:

 Configuration> HTTP Service> HTTP Listeners> admin-listener 

Change the Network Address as appropriated, check the Security check box, and in the SSL Tab enable Client Authentication, in order to find out how you should use Client Certificate, take a look at my previous posts about SSL and securing GlassFish Application Server. You have two other Http listeners to take care of, so make sure that you change their Network Address and enable the Security facilities if required

There is another listener which you need to take care of, It is your IIOP listener. IIOP listener let you create a context to lookup into your JNDI, etc. In order to configure the IIOP listeners you should navigate to:

 Configuration> ORB> IIOP Listeners 

Here you can see that there are 3 different listeners already created and configure for different purposes. You should not allow the first non-secure listener (orb-listener-1) to listen over a public network as there is no authentication or transfer layer security for this listener, but the second one (SSL) have transport layer security and the third one (SSL_MUTUALAUTH) has mutual authentication which guarantee that listener will only process request come after a client cert authentication. make sure that you configure the listeners to listen on correct Network address and remove or disable the listeners those that you do not need. You can disable a listener by looking at listener details page which provides a check box for it.

Another listener which you need to take care of is your JMX connector listener, You can view and edit its configuration by navigating to:

 Configuration> Admin Service> system 

Here you are able to change the realm that this listener use to authenticate the users that are trying to connect to JMX listener, you can change the realm to an specific realm which you have made only for JMX users or let it use you administration realm. You can change the Network Address that this listener is using along with enabling the SSL and Client Cert Authentication in order to secure the data transfer and guarantee that only users with correct digital certification can use your JMX connector to control the application server

PS: All of the listeners that you can configure in your administration console allows you to have Mutual Authentication (Client Cert Authentication) which ensure that both parties have verify-able certifications. This certifications can come from well known providers like VeriSign or your own CA. on the other hand all listeners allows you to specify an specific alias for them, which means that each listener mutual authentication can be configured completely independent from other listeners, for example you can have two alias one for administration console and one for JMX connector in order to prevent JMX users to connect to administration console.

For more information you can take a look at my older posts related to this matter:

 

How to Secure GlassFish installation.

It is some days that I saw some posts about securing Glassfish in production environment, so I thought I write some of my experience here to let other secure the glassfish easier. There are some basic items that you will need to relay on in order to have a secure Glassfish installation.

 

  1. secure access to administration console, both web based and CLI.
  2. secure all ports and listeners that application server uses to interact with outside applications.
  3. secure your environment from GlassFish; Yes, glassfish can be evil if you have buggy software installed on you application server.
  4. secure your application server from the environment that it is operating on it.
  5. secure glassfish directories in order to prevent any accidental changes, use, etc in glassfish configuration files.
  6. Take care of all logging if you are not going to secure Glassfish on the file system.
  7. tips and tricks which are not mentioned in the above sections.
  8. firewalls, network security, clustered environment tips and tricks

 

But how you can do these, I will explain each item in as much details as I can begin with securing your administration console. As you know administration console is the main interaction point with an application server, however must of application servers let you perform all changes from a CLI or direct editing of server.xml, domain.xml and so on. But Web based administration console is the most open to access part of application server, So let’s see how we can secure it:

You will need to change administration password from the default one, do it by using the following command in CLI when your application server is running.

 change-admin-password 

 

Using this command you can change your administration password both for CLI and Web based console. The output of the command may differ from version or profile to another version and profile but it will asks you to enter old and new password, in case that it asks to accept a certificate accept it, you will change it later.

Second thing that you should change is master-password, make sure that you stop your application server before issuing the command as it will not work when the as is running. Following command in asadmin console will do it for you. Default master password value is “changeit”

 change-master-password 

 

Now you are sure that your administration console and keystore files are protected using a new password which you know.

Its time to take a closer look at application server web based console protection, you need to make sure that you have most possible protection over your administration console by limiting access to it using firewalls and after that you can add another level of protection and transmission integrity by using a mutual authentication using Digital Certificate.

By changing the administration http listener to use an a digital certificate specific for administration console and changing its setting to use client-cert authentication or mutual authentication you can ensure that your administration console will only opens in a browser which has a digital certificate signed by a CA known to your administration listener.

This way you can be sure that only the guys with that specific digital certificate will have access to your admin console and the administrator will not fool by anyone to connect to a mock server. On the other hand you have full protection of SSL over your transmitted data. To learn how you can setup your own CA and add keys to glassfish keystore take a look at some older entry of my weblog. however those entry shows how you can use digital certificate when your AS uses jks files ant certDB files.

How to have your Own CA and configure Glassfish and your clients for mutual authentication?, Part II

In the second part of the series, you can see how we can utilize EJBCA to create certification for a client side application which will communicate with Glassfish server when Client cert authentication (Mutual Authentication) is enabled whether by changing the listener attributes or by describing it in the web-config.xml.

In order to create client certification we will need to perform following steps as described in 4 sections:

Section 1: Creating clients certification profile:

  • Go to https://localhost:8080/ejbca/ and select Administration.
  • Select Edit Certification profiles from the left side menu.
  • Enter a name for the profile and press add button. I choose Clients as the name.
  • From the list select Clients Item and press Edit button.
  • Now profile edit page will open change the attribute as follow:
    • for Key Usage  you should select at least Digital Signature and Key Encypherment.
    • From  Extended Key Usage select Client Authentication
  • press save button.
Section 2: Create servers end entities profile:

Now you have create a profile which in next sections you can create certifications which will comply with it. Now we will need to create an End Entity Profile so follow these steps to create it.

  • From the left side menu click on  edit end entities profile .
  • Enter ClientsProfile as profile name and press add button.
  • From the list select ClientsProfile and press Edit End Entity Profile button.
  • Enter a user name and a password for the profile, I choose cAdmin/ cAdminAdmin.
  • Enter the common name
  • From the list of Available Certificate Profiles  select Clients which we made in last step.
  • select JKS as default token.
  • click Save

Now we are reaching an step in which we will create the real certificate that client will use to prove its identity and initiate SSL enabled session. To create the certificate perform following steps:

Section 3: Create Client certification

  • From the left side menu select add end entity link.
  • Select ClientsProfile as End Entity Profile.
  • Enter all information as you like.
  • Select JKS as Token.
  • press add end entity button
Section 4: Use the certification in Client Application.

You are done, the certification is ready to be downloaded and used.

  • Go to https://localhost:8080/ejbca/  and select Certification Enrollment.
  • Select Manually for a Server
  • Enter user name and password which you have entered for end entity in previous step.
  • Click OK.

By pressing OK a JKS file will download to your computer.

Create two copies of the file and Rename them  to keystore.JKS and cacerts.jks. In order to create a SSL enabled client, either web service client or any type of socket client which need to use SSL you can follow one of the following path:

  • When you want to run your java application pass following parameter to JVM, it will ask JVM to use your cacerts.jks and keystore.jks during initialing SSL communication and authentication.
-Djavax.net.ssl.trustStore="Truststore_Location"    -Djavax.net.ssl.trustStorePassword="Truststore_Password"   -Djavax.net.ssl.keyStore ="Keystore_Location" -Djavax.net.ssl.keyStorePassword="Keystore_Password"

  • Second way is adding the same parameter to your JVM during execution of your application code. using this way you are not forced to pass parameter and disclose your key stores passwords.
 System.getProperties.put("javax.net.ssl.trustStore","Truststore_Location"); System.getProperties.put("javax.net.ssl.trustStorePassword","Truststore_Password"); System.getProperties.put("javax.net.ssl.keyStore","Keystore_Location");  System.getProperties.put("javax.net.ssl.keyStorePassword","Keystore_Password"); 

Make sure that you are using correct location and password for your files, passwords are same as one you used to download the JKS files.

I should say again that you can explore and perhaps learn more about jks files, keys and certification by exploreing your stores, you can use jks file editor located at http://members.aon.at/bhuber14/nbm.html. Also if you are may find more cool key store editor in NetBeans Module Portal

For more information or maybe to find some of your questions answered you may take a look at:

 

How to have your Own CA and configure Glassfish and your clients for mutual authentication?

One of the most repeated question in GlassFish mailing list is SSL, Certification, Mutual Authentication,…. In this Entry I will try to address some of this questions by giving an step by step guide for using EJBCA to issue certificate, use them in both glassfish and clients which connect to glassfish in some manner. clients like web browser, standalone java applications,…

There are several tutorial and blog entry about configuring glassfish to use some specific certification in order to perform server authentication for clients over SSL and each of those weblog is an invaluable source of information. In this blog entry and perhaps the next one I will address another concerns which some people has for their GlassFish and client security. Some times we are running an application within an enterprise and we need to have mutual authentication for every clients that connect to server so we will need to have one certification for client and another one for our glassfish server. both of this certification should be valid (issued by an already known CA within glassfish trust store and client trust store). For these two entries I assume that our client and server will just accept certification issued by our own CA which is based on EJBCA.

Before we start the main job you will need to download and install EJBCA from its web site, then you will need to install it according to its manual which you can find in documentation section. After you installed and could view EJBCA administration console then you can follow the rest of the entry.

 

In order to create server certification we will need to perform following steps as described in 4 sections:

Section 1: Creating servers certification profile:

  • Go to https://localhost:8080/ejbca/ and select Administration.
  • Select Edit Certification profiles from the left side menu.
  • Enter a name for the profile and press add button. I choose servers as the name.
  • From the list select servers Item and press Edit button.
  • Now profile edit page will open change the attribute as follow:
    • for Key Usage  you should select at least Digital Signature and Key Encypherment.
    • From  Extended Key Usage select Server Authentication
  • press save button.
Section 2: Create servers end entities profile:

Now you have create a profile which in next sections you can create certifications which will comply with it. Now we will need to create an End Entity Profile so follow these steps to create it.

  • From the left side menu click on  edit end entities profile .
  • Enter ServersProfile as profile name and press add button.
  • From the list select ServersProfile and press Edit End Entity Profile button.
  • Enter a user name and a password for the profile, I choose sAdmin/ sAdminAdmin.
  • Enter the common name
  • From the list of Available Certificate Profiles  select Servers which we made in last step.
  • select JKS as default token.
  • click Save

Now we are reaching an step in which we will create the real certificate that Glassfish will use  in its SSL enabled listener. To create the certificate perform following steps:

Section 3: Create server certification

  • From the left side menu select add end entity link.
  • Select ServersProfile as End Entity Profile.
  • Enter all information as you like but make sure that CN should be Exact and fully qualified name of your sever as will access it from clients, for example if you are going to access the serve as computer1.mydomain.com then the CN should be the same if you are going to access it as Comuter1 then the CN should be that.
  • Select JKS as Token.
  • press add end entity button
Section 4: Use the certification in Application Server.

You are done, the certification is ready to be downloaded and used.

  • Go to https://localhost:8080/ejbca/  and select Certification Enrollment.
  • Select Manually for a Server
  • enter user name and password which you have entered for end entity in previous step.
  • Click OK.

By pressing OK a JKS file will download to your computer.

  • Create two copies of the file and Rename them  to keystore.JKS and cacerts.jks.
  • Goto Glassfish/domains/domain1 (If domain 1 is the domain that you want to configure for SSL).
  • Make sure that application server is stopped by issuing the following command.
	Glassfish_home/bin/asadmin  stop-domain domain1	

  • Now we need to change the master password in order to let glassfish open our new cacert.jks and keystore.jks so perform following command.
	Glassfish_home/bin/asadmin  change-master-password  \Here you should write the password that you choosed in last step/// --savemasterpassword=true

  • Now Goto glassfish_home/domains/domain1/config and create a backup from cacert.jks and keystore.jks.
  • Copy files that we create in first step of this section to this folder (overwrite the original files).
  • Open domain.xml (it is in domain1/config folder) by a text editor and replace all s1as occurrences with CN name that you have choose in section 3.
  • Start the application server.

You are done, you application server should start normally, but you have some more steps before you complete the mutual authentication capability.

Section 5: Enabling mutual authentication for a listener.

Open application server administration console and from the left side menu select Configuration> HTTP Service> HTTP Listeners> http-listener-2, now you should check the Security check box and select SSL tab, now make sure that you have checked Client Authentication check box.

You are done, point your browser to https://computer1.mydomain.com:8181 you will see that this page will only open for the browser that you have imported EJBCA administration certification. it means that both server and client must prove their identity before they could communicate.

In next entry of this series I will demonstrate steps that you need to follow in order to create a stand alone web service client.

Make sure that you need to delete the private key of you server from cacerts.jks (it is not necessary by the way). Best way to explore you key stores is using keytool which you can find more information about it Here. Also if you are may find more cool key store editor in NetBeans Module Portal

For more information or maybe to find some of your questions answered you may take a look at: