SSL Archive

How to check for SSL POODLE / SSLv3 bug on WebLogic? How to fix

Details of the SSL POODLE bug can be found here

We can address it in the following way.

1) Disable SSL 3.0 support in the client.


2) Disable SSL 3.0 support in the server.

We can start WebLogic server with the following JVM option

Ref :-
Disable support for CBC-based cipher suites when using SSL 3.0 (in either client or server).

You can do it by editing you config.xml


<server-private-key-alias>xxxxxxx </server-private-key-alias>


This article explains the attack in details.

Mutual Authentication with Weblogic Server

Mutual authentication is a process in which the Server sends its certificate to the client ( thin client / fat client) and the client validates the certificates, then the server requests for a certificate from the client and validates it.

In this example we have created a .pfx certificate which contains the public and the private keys. We installed the pfx certificate in the browser.




Then we exported the public key and imported it into the trust store of Weblogic Server.

C:\bea103\wlserver_10.3\server\lib>keytool -v -import -keystore DemoTrust.jks -f
ile Fabrizio.cer -alias fabrizio -storepass DemoTrustKeyStorePassPhrase
Owner: CN=Fabrizio
Issuer: CN=Fabrizio
Serial number: 0
Valid from: Fri May 15 20:02:49 IST 2009 until: Mon May 13 20:02:49 IST 2019
Certificate fingerprints:
MD5: 6B:45:89:C2:F0:4A:35:EB:8C:54:06:9F:5C:F1:D4:DB
SHA1: CE:2F:81:25:73:E0:52:77:C2:48:0E:70:FC:52:AE:3E:66:C6:33:9B
Signature algorithm name: MD5withRSA
Version: 1
Trust this certificate? [no]: yes
Certificate was added to keystore
[Storing DemoTrust.jks]

Created a user Fabrizio in the Default Authenticator


Configured the DefaultIdentityAsserter to process X509 Tokens

Home >Summary of Security Realms >myrealm >Providers >DefaultIdentityAsserter

Active Types: X.509


Provider Specific
Trusted Client Principals: Fabrizio
Default User Name Mapper Attribute Type: CN
Use Default User Name Mapper : Checked


Enabled SSL Port


Configured the Server to request for Client Certificates.

AdminServer > SSL > Advanced

Hostname Verification: None
Two Way Client Cert Behavior: Client Certs Requested and Enforced


Deployed an application that uses CLIENT-CERT authentication and accessed it. Will cover the details of such an application in another post.

access the protected application

Once we select the appropriate certificate we were able to access the application.

Please let us know if you have any queries related to the configuration or require additional details.

Wonders Team

Converting certificate formats

Converting Certificate from JKS to P12 Format

keytool -importkeystore -srckeystore Fabrizio.jks -destkeystore Fabrizio.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass weblogic1 -deststorepass weblogic1 -srcalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -destalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -srckeypass weblogic1 -destkeypass weblogic1

Converting certificate from PFX to JKS Format

java -classpath ./jetty-6.1.1.jar Fabrizio.pfx Fabrizio.jks

Converting certificate from P12 to PFX Format

1. Import the certificate in the browser using certificate import wiward by double clicking on the p12 certificate.
2. Go to Internet Options > Content > Certificates > Personal
3. Choose your certificate and click export.
4. Select Yes Export the Private Key
5. Select Personal Information Exchange Format and provide the password.
6. Store the file as .pfx.

Certificate Management in WebSphere Application Server

Before, trying to understand about the certificate management, installation of certificates inside the WebSphere application server we should first understand why we need ssl communication and what is the impact of not installing the certificates.

During the olden days whenever we want to make any banking transaction (e.g.: depositing the money, with draw money, transfer money, etc), make a reservation for Air travel, etc… we used to visit the branches, stand in the queue and wait for our turn and complete the transaction. But, in present day with time constraint, busy world none of us wants to waste time being in queue. Thanks to the internet based applications which made every work possible with a finger click. But, always a question remains how about the security to these transactions on the internet??.

The JSSE (JAVA Secured Socket Extension) is a set of packages that enable secure Internet communications. It implements a Java technology version of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It includes functionality for data encryption, server authentication, message integrity & optional client authentication.


SSL configuration:  SSL configuration help us in making secured communication between the application deployed inside the websphere and external client (browser) by encapsulating the data as required by JSSE. These certificates inside the websphere are mainly of 2 different types. They are as follows:-

(a)     Self Signed certificates ( or Internal or Default Certificates)

(b)     Signer Certificates (or Digital Certificates)


Self Signed Certificates: From websphere application server 6.1 onwards the self signed certificates are created automatically during the profile creation .i.e., whenever the profile is federated to cell self signed certificated are created automatically. The management of these self signed certificates is automatically taken care. The expiration of these certificates is monitored on a pre-defined schedule with notifications sent to system logs and email-sending capabilities. The certificates will be automatically replaced before expiration, by default, and, there will of course be a warning prior to the certificate replacement.


Signer Certificates: A signer certificate represents certificate and public key associated with some personal certificate. The signer certificate explicitly trusts connections made to or by the owner of the associated personal certificate. The signer certificate is typically made completely public by the owner of the personal certificate, but it’s up to the receiving entity to determine if it is a trusted signer prior to adding it to the trust store.

Following are the steps involved for installing the SSL signer certificates:-

1)      **Invoke the ikeyman from the profiles bin directory.

2)      In the IBM Key Management Utility, click on Key Database File and then New

3)    Choose Key database type and select JKS. Give any name to keystore like Test_key.jks.

4)      Click the Browse button and give location where we want to store keystore file.

5)      Click OK. Enter a password and click OK.

6)      Click Create then New Certificate Request to bring up the Create New Key and Certificate Request window.

7)      Type a Key Label, Common Name, Organization, Locality, State, and select a Country. Select 1024 for Key Size.


8)      Click on Key Database File and then Open. Locate the keystore file that you created when you generated the CSR. Type the password and click OK.

9)      Select Signer Certificates from the pull-down list.

10)   Click the button to Add…

11)   Login to WAS console with the valid credentials and Expand “Security” link at left hand side pane.

12)  Click on “SSL certificate and key management”.

13)  Click on “SSL configurations” link.

14)   Click on “Key stores and certificates” link.

15)  Select the scope by clicking on CellDefaultTrustStore (or NodeDefaultTrustStore) link from the list.

16)   Click on “Signer certificates” link.

17)   Click on Add button.

18)   Give alias name as “Test_Cert”.

19)  Give filename as complete path of “Test_Cert.cer” on server.

20)  Click apply and then OK and restart all the WAS server instances.



Weblogic-wonders Team

Weblogic SSL configuration with Custom Identity and Custom Trust

These days the enterprise applications have grown more complex and boast a great deal of sensitive and critical data online. Cyber security has become more than important these days to secure the data.

Secure Sockets Layer plays a pivotal role in how a sensitive data can be protected, accessed over a network.

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection to authenticate the other’s identity and by encrypting the data exchanged between the applications. Authentication allows a server and optionally a client to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.

It provides transport level security by usage of the SSL certificates which are provided by the Industry standard Certificate Authorities like Verisign, GeoTrust, GoDaddy etc.

WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs protocol in the connection URL, for example, https://myserver:7002.

The below post describes the complete procedure about procuring the certificate, installing and configuring the certificate to the WebLogic Server. (WebLogic SSL Configuration).

1: Generating and procuring the certificate:

a: Open a command prompt and set the environment by running the setDomainEnv script.

b: Generate the private – public key pair. For demonstration we would use keytool java utility to do so. However we can use other utilities like openssl etc.

keytool -genkey -alias client -keyalg  RSA -keysize 2048  -keystore identity.jks -storepass password -keypass password

c: Generate a Certificate Signing Request (CSR) and send it to Certifying Authority.

keytool -certreq -keyalg RSA -keysize 2048 -alias client -file certreq.csr -keystore identity.jks -storepass password

The CA would return with the certificate reply and the RootCA and sometimes an intermediateCA certificate.

d:  Import the certificates into the keystore, this can be done in two ways either by importing the certificates in an order of RootCA, intermediateCA and then Certificate reply. Or we can create a certificate chain clubbing them in an order into a .pem file.

For demo, we would create a certificate chain file CertChain.pem and import it into the identity keystore overriding the private key alias which is client in this example.

keytool -import  -file CertChain.pem -alias client -keystore  identity.jks -storepass password

e: Create a trust keystore, this can be done my importing your RootCA certificate into another keystore that constitutes the trust.

keytool -import  -file rootCA.cer -alias RootCA -keystore trust.jks -storepass password

To verify the contents of the keystore, you can use the below command,

Keytool –list –v –keystore <keystore-name> -storepass  <keystore-password>


2: Configuring the keystore on the WebLogic Server.

a: Log into the Admin Console, select the server on which you want to configure the SSL certificate.

Server  –>  Click on the Keystore tab. By default it points to the Demo Certificates.

From the dropdown list select the “Custom Identity and  Custom Trust” option.

Enter the identity and trust keystore details.

b: Configure the identity of the server:

Click on the SSL tab and enter the alias of the private key i.e. client in this case and the keypass password.

NOTE: If you enable the SSL for a WebLogic Server, by default it would be One Way SSL. If you want to change to Two Way SSL, you would require to select  the two way SSL behavior from the Advanced option list.

c: Configure the SSL port.

By default it would be 7002.

Go to server –> General tab –> Specify  and enable SSL port.

You can see the below messages in the server logs which indicate that the certificates are loaded.

<Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias client from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\identityVerisign.jks.>

<Notice> <Security> <BEA-090169> <Loading trustedcertificates from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\trustVerisign.jks.>


3: Test the setup:

You can test the setup by accessing the admin console (if SSL is configured for Admin Server) or any application deployed on the server by accessing it on https protocol.


Now verify whether the right certificate is configured or not.

Click on the certificate details and you would find the details about the identity and the RootCA along with the certificate chain.


NOTE: For a production environment make sure that CN (Common Name) of the certificate matches with the server host name.

You can also use self signed certificates or trial certificates for testing purpose. However is it not recommended to use them in production environment.

You can get the Verisign trail certificates from the below link.

For further reading :


Wonders Team 🙂