cloudnetes: SSL

18 April 2017

SHA2 on Oracle Http Server

OHS has Limitation to work with SHA2 certificates and supports from 11.1.1.9 onwards

Here are the steps to configure SHA2 certificate over OHS server


1 generate a private key
$ openssl genrsa -des3 -out private.key 2048
(give password )

2 generate CSR
$ openssl req -new -sha256 -key private.key -out abc.csr

3 Create openssl wallet
$ openssl pkcs12 –export –out ewallet/ewallet.p12 –inkey priv_key_location \ 
  –in server_cert_location –certfile root_cert_location

  verify It using below command. You will see ‘User and trusted certificate’ 
  as shown in green below(if above command used correctly)
$ orapki wallet display -wallet ewallet/
**
User Certificates:
Subject:    CN=www.abc.com,O=GOOGLE INC,L=London,ST=London,C=GB
Trusted Certificates:
Subject:    CN=VeriSign Universal Root Certification Authority,OU=(c) 2008 VeriSign\,
            Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
**

4 Extract user.crt  from the wallet created in previous step
$ orapki wallet export -wallet /opt/software/wt/ohs_instance/config/OHS/ohs1/keystores/ewallet/ \
  -dn "CN=www.abc.com,O=GOOGLE INC,L=London,ST=London,C=GB" -cert user.crt -pwd ********

Extract the intermediate and root certificate in base 64 format from certificate received by CA.
(from windows machine)

5 Create chain certificates ( copy certificates into single file chain.crt)
user --> Intermendiate --> root

6 Create a wallet using openssl
$ openssl pkcs12 –export –out /ohs_instance/config/OHS/ohs1/keystores/openssl/ewallet.p12 \
  –inkey private.key –in user.crt –certfile chain.crt

7 Convert openssl wallet to JKS
$ orapki wallet pkcs12_to_jks -wallet /ohs_instance/config/OHS/ohs1/keystores/openssl \ 
  -pwd ******** -jksKeyStoreLoc /ohs_instance/config/OHS/ohs1/keystores/punit.jks -jksKeyStorepwd welcome1 

8 Create an auto login wallet using orapki
$ orapki wallet create -wallet /ohs_instance/config/OHS/ohs1/keystores/abc -auto_login -pwd welcome1

9 Convert jks to wallet
$ orapki wallet jks_to_pkcs12 -wallet /ohs_instance/config/OHS/ohs1/keystores/dslcheck -pwd welcome1 \ 
  -keystore /opt/software/wt/ohs_instance/config/OHS/ohs1/keystores/punit.jks -jkspwd welcome1 

10 verify  wallet
 $ orapki wallet display -wallet /ohs_instance/config/OHS/ohs1/keystores/abc/

this should show below result and include all the certificates

**
User Certificates:
Subject:    CN=www.abc.com,O=GOOGLE INC,L=London,ST=London,C=GB
Trusted Certificates:
Subject:    CN=www.abc.com,O=GOOGLE INC,L=London,ST=London,C=GB
Subject:    CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US
Subject:    CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) 2006 VeriSign\, 
            Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
**

Refer the wallet path into ssl.conf & httpd.conf as

SSLWallet "/opt/software/wt/ohs_instance/config/OHS/ohs1/keystores/abc"

Restart the instance.

Refer this to check your installed certificate

https://www.sslshopper.com/ssl-checker.html#hostname=abc.com

12 September 2016

SSLv3 to TLS1.*

What is the POODLE Vulnerability? (Padding Oracle On Downgraded Legacy Encryption)

The POODLE vulnerability is a weakness in version 3 of the SSL protocol that allows an attacker in a man-in-the-middle context to decipher the plain text content of an SSLv3 encrypted message.

Who is affected by this Vulnerability?

This vulnerability affects every piece of software that can be coerced into communicating with SSLv3. This means that any software that implements a fallback mechanism that includes SSLv3 support is vulnerable and can be exploited.

Some common pieces of software that may be affected are web browsers, web servers, VPN servers, mail servers, etc.

How Can I Protect Myself?

Servers and clients should take steps to disable SSLv3 support completely. Many applications use better encryption by default, but implement SSLv3 support as a fallback option. This should be disabled, as a malicious user can force SSLv3 communication if both participants allow it as an acceptable method.

Steps to disable SSLv3 protocol on JBoss and Weblogic and WebSphere:

Steps to disable SSLv3 protocol on JBoss:

1. While enabling/configuring the https connection in standalone-full.xml file at location \standalone\configuration, specify the ssl protocol

sslProtocol = "TLS" key-alias="jbosskey" certificate-key-file="../standalone/configuration/server.keystore"/>

2. If you don't specify the sslprotocol attribute in tag, by default it takes SSLv3 for Jboss. We need to explicitly point it to another protocol other than SSlv3

Steps to disable SSLv3 protocol on Weblogic:

1. The weblogic.security.SSL.protocolVersion command-line argument lets you specify which protocol is used for SSL connections.

2. After enabling/configuring the SSL for weblogic server, append the following option to the JAVA_OPTIONS variable

-Dweblogic.security.SSL.protocolVersion=TLS1

NOTE: If you don’t specify the above property, by default it takes SSLv3.

 Execute below command to check what all protocol   components are working

 openssl s_client -connect -ssl3 
 openssl s_client -connect -tls1 
 openssl s_client -connect -tls1_1 
 openssl s_client -connect -tls1_2

-----------------------------------------------

Web Services and Client Applications (Outbound Connections)
You may also have applications running as a client, (e.g. web services, scripts, or command line) for an outbound ssl connection. Within a Fusion Middleware environment there are also internal processes running where an ssl connection is made, (e.g. OPMN, DMS, EM/FMW Control). To control the outbound connections the following system property is available:
-Djdk.tls.client.protocols=TLSv1.0,TLSv1.1,TLSv1.2

(Example shown to allow all TLS protocols)

Notes:
• TLSv1.1 and TLSv1.2 protocol versions are supported but were not enabled by default when using earlier versions of JDK 6 and 7. You need to explicitly set them (like above example), else only TLS 1.0 will be used. The JDK 8 default allows both TLS 1.1 and 1.2 by default. You may also set a minimum by removing the older versions, but it is important to consider the external servers the application is connecting to. The protocol will always be negotiated to the highest supported level between the client and server. If you see ssl handshake failures when all components are set to use only TLS 1.2, then look at what the other side supports.
• The jdk.tls.client.protocols system property is available since 7u95 and 6u121 to be able to set this. All versions of JDK 8 support this. In other words, older JDK versions only support TLS 1.0 for outbound client connections.
-----------------------------------------------

Steps to disable SSLv3 protocol on WebSphere:

1. Go to Security > SSL certificate and key management > SSL configurations

2. The collection of all SSL configurations is listed. For each SSL configuration in the list the SSL protocol will need to be modified to use TLS.

3. Select an SSL Configuration then click Quality of protection (QoP) settings under Additional Properties on the right.

4. On the Quality of protection (QoP) settings panel, select TLS form the pull down list in the box labeled Protocol.

5. Apply/Save.

6. Restart application server

How to check if SSLv3 is disabled:

1. Install Openssl on windows machine (http://gnuwin32.sourceforge.net/packages/openssl.htm)

2. In command prompt run the below commands

openssl s_client -connect : -ssl3

3. You will see some error something like below

Loading 'screen' into random state - done

CONNECTED(00000170)

7468:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake

failure:./ssl/s3_pkt.c:530:

4. If SSLv3 is enabled, and you run the same command. You will see an output something like below

Loading 'screen' into random state - done

CONNECTED(00000170)

Server certificate

br,

Punit

25 June 2015

SSL Cheatsheet

ORACLE-JRE


# to create a keystore.jks file (pair of keys)
$ keytool -genkey -keyalg RSA -alias benefits -keystore keystore.jks \ 
  -storepass 123456 -keysize 2048

# to export/store a certificate in a file 
$ keytool -export -alias benefits -file root.cer -keystore identity.jks -storepass mypass

# to import a certificate into keystore
$ keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias" 

# to create a csr request in form of myapp.csr file
$ keytool -certreq -alias benefits -keystore keystore.jks -file myapp.csr

# to generate the certificate as myapp.crt
$ keytool -exportcert -alias benefits -keystore keystore.jks -v -file myapp.crt

# command to convert .pfx to .jks
$ keytool -importkeystore -srckeystore abc.com.pfx \ 
  -destkeystore servercertstore.jks -srcstoretype PKCS12 \ 
  -deststoretype JKS -srcstorepass w3bl0g1c -deststorepass pa55w0rd -noprompt

# command to change alias name
$ keytool -changealias -alias "oldAlias" -destalias "newAlias" -keypass w3bl0g1c \ 
  -keystore servercertstore.jks -storepass pa55word

# command to delete a certificate from Keystore
$ keytool -delete -noprompt -alias ${cert.alias}  -keystore ${keystore.file}  -storepass ${keystore.pass}

IBM-JRE


 # to create jks type DB
 $ ikeycmd -keydb -create -db keystore.jks -pw password -type jks -expire 365

 # request for CSR
 $ ikeycmd -certreq -create -db keystore.jks -label mylabel \

   -dn "CN=mysite.com,O=cloudnetes,OU=IT,C=IN" -size 2048  -sig_alg SHA256_WITH_RSA -file mysite.com.csr

 # import certficates into DB
 $ ikeycmd -cert -add -db keystore.jks -label ca_intermediate -file ca-inter.crt
 $ ikeycmd -cert -add -db keystore.jks -label ca_root -file ca-root.crt

 # validate personal/end-entity cert
 $ ikeycmd -cert -receive -file mysite-identity.crt -db keystore.jks

IBM-MQ


  # add a cert in cert-key DB
 $ runmqakm -cert -add -db keystore.kdb -stashed -label ca_root -file ca_root.crt

 # check all certs
 $ runmqakm -cert -list -db keystore.kdb -stashed

 # delete a cert
 $ runmqakm -cert  -delete  -label mylabel -db keystore.kdb -stashed

 # check cert expiry
 $ runmqakm -cert -details -db keystore.kdb -stashed  -label mylabel | grep -i "Not After"

CERTUTIL


# to view certificate installed on sunone instance
$ certutil -d -P https-pricer-pfix-wxvrw99a0016- -L -n Server-Cert

# to list certificate installed on sunone instance with alias name
$ certutil -d /opt/sunone617/suitespot/alias \ 
  -P https-saXXXit2.abc.com-wsszw2057- -L -n Server-Cert

# listing the details of Server-Cert
$ certutil -L -n Server-Cert -d /instance-name/ -P instance-name

# Generating a CSR & output it to the file serverCert.req
$ certutil -R -s "CN=abc.com,OU=IT, O=CTS, l=Bangalore, st=karnataka, c=IN" -o serverCert.req -a -d /instance_path/P instance -g 2048

# Deleting the existing cert with name Server-Cert
$ certutil -D -n Server-Cert -d /Instance-Name/ -P instance-name-

# Import the cert
$ certutil -A -n Server-Cert -t "u,u,u" -i /instance-path/instance.pem -d /instance-name -P https-instance

OPENSSL


# Decode a CSR
$ openssl req -in mycsr.csr -noout -text

# Decode a certificate
$ openssl x509 -in certificate.crt -text -noout

# Generate a key pair: (.key)
$ openssl genrsa -des3 -out |.key file name| 2048

# Generate self-signed certificate
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt

# Generate CSR to request CA-signed certificate 
$ openssl req -new -newkey rsa:4096 -nodes -keyout server.key -out server.csr

# Create certificates: (.pem)
$ openssl x509 -in name.crt -noout -text 

$ openssl x509 -subject -dates -issuer -noout -in name.crt

# To open key file and check modules
$ openssl rsa -noout -text -in application.key -modulus

CERTIFICATE CHECK/DETAILS


$ openssl x509 -in certName.crt  -noout -text
$ openssl x509 -subject -dates -issuer -noout -in file

$ keytool -list -v -keystore keystoreName.jks

$ certutil -L -d certDbName-cert8.db

# Print available ciphers in any Linux host
$ openssl ciphers -v | awk '{print $2}' | sort | uniq

CURL WITH JAVA KEYSTORE

Curl doesn't support Java Keystore file, so the file should be converted to a PEM format(PKCS12).

It consists of the following 3/4 steps:

STEP1 - Convert keystore to p12 file

STEP2 - Convert p12 file to pem file
STEP3 - Export Private key (valid for 2 way mTLS)

STEP4 - Run curl command with pem files

1way TLS/Authentication

STEP1 - Convert keystore to p12 file

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.pk12 -srcstoretype JKS -deststoretype PKCS12

STEP2 - Convert P12 to pem file

openssl pkcs12 -in truststore.pk12 -out trusted-certs.pem

 STEP3 - Run curl command with pem files ****************

curl secret --cacert trusted-certs.pem https://localhost:8443/api/hello

2way TLS/Authentication also known as Mutual Authentication

STEP1 - Convert keystore to p12 file

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS12

STEP2 - Convert p12 file to pem file

openssl pkcs12 -in identity.p12 -nokeys -out client-cert.pem

openssl pkcs12 -in identity.p12 -nocerts -out client-key.pem

STEP3 - Export Private key

 openssl pkcs12 -in truststore.pk12  -nodes -nocerts -out client-key.pem

STEP4 - Run curl command with pem files

curl --key client-key.pem --cert client-cert.pem --cacert trusted-certs.pem https://localhost:8443/api/hello

03 June 2015

Weblogic SSL Renewal Steps

When you wish to install the security certificate on your WebLogic server, it's a 3 step procedure

STEP 1: Creating a Keystore (.jks file )

(this is the prime entity that stores your certificates)


 # Generate a public key 
 $ keytool -genkey -alias punit -keyalg RSA -keysize 2048 -keystore identity_keystore.jks -storepass weblogic1
 
 it will prompt you for following questions:

 What is your first and last name?
 [Unknown]: abc.com
 What is the name of your organizational unit?
 [Unknown]: MW
 What is the name of your organization?
 [Unknown]: CTS
 What is the name of your City or Locality?
 [Unknown]:
 What is the name of your State or Province?
 [Unknown]:
 What is the two-letter country code for this unit?
 [Unknown]: IN 

 it will prompt for confirmation so give > yes

 this will create a file named > identityKeystore.jks

STEP 2: Generating CSR (Certificate Signing Request )


 $ keytool -certreq -alias punit -file csr.txt -keystore identity_keystore.jks -storepass weblogic1

 this will create a file named > csr.txt

copy the content of csr.txt and send it to the signing authority, they will encrypt their private key into the CSR's and send three files (root.pem, interim.pem & server.pem)

STEP 3: Importing the Certificates:

open all the three certificates and copy & paste the content into certificate_chain.pem in order
server > intermediate > root
now import this certificate_chain.pem into identity keystore (identity_keystore.jks) using below command

 
 $ keytool -v -import -alias punit -file certificate_chain.pem -keystore identity_keystore.jks -storepass weblogic1
 or
 $ keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias"

(use alias & password defined by you while requesting the certificate)

it will prompt you for Yes/No > Yes

this will import the certificate chain (Root, Interim, Server) into identity_keystore.jks

if required import (Root, Interim) into trust_keystore.jks as well (optional/Depends)

(now define the ssl & keystore properties from Admin console for identity & trust keystore and bounce the servers)

**
Select keystore type as: Custom Identity and Command-Line Trust
Define attributes for the Identity keystore
Custom Identity Keystore File Name - The fully qualified path to the Identity keystore
Keystore type - The type of the keystore. Generally, this attribute is jks
Keystore PassPhrase—The password defined when creating the keystore
-Enable SSL port of server (from server SSL tab)
-click continue
-click finish
-Reboot weblogic server

NOTE: for SHA2 certs we need to enable JSSE ssl options corresponding to the servers & sometimes if required add below java_options also in server starts or in nodemanger.properties files if node manager is configured.

 
 -Dweblogic.security.SSL.enableJSSE=true    (client)

 -Dweblogic.ssl.JSSEEnabled=true            (server)

25 November 2014

Why to use SSL certificate & when to Use a Self-Signed Certificate

This video helps you to understand SSL in the simplest way!!

You should never use a self-signed certificate for any e-commerce website or any site that transfers valuable personal information like credit cards, social security numbers, etc.

An SSL certificate is necessary for more than just distributing the public key: if it is signed by a trusted third party, it verifies the identity of the server so clients know they aren’t sending their information to the wrong person.

So what is a self-signed certificate?
It is a certificate that is signed by itself rather than a trusted third party. Isn’t that bad? In most cases, yes. You will almost never want to use a self-signed certificate on a public apache server that requires anonymous visitors to connect to your site because they could easily become a victim of a man-in-the-middle attack. However, self-signed certificates have their place:

Self-signed certificates can be used on an Apache development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
Self-signed certificates can be used on an intranet. When clients only have to go through a local intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
Self-signed certificates can be used on personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connection.

Just keep in mind that visitors will see a warning in their browsers when connecting to an Apache site that uses a self-signed certificate until it is permanently stored in their certificate store.

For example:
WebLogic Server is configured by default with Demo Identity and Demo Trust. To use these, you need to enable the SSL port under the General Tab of the server and generate a demo certificate using keytool utility of weblogic, and WLS will start listening over SSL on that port.

To generate the certificates, you need to use keytool. It is a standard java keystore utility. This is included with the Java SE JDK as well as the JRockit JDK.

A keystore is a database of key material. Key material is used for a variety of purposes, including authentication and data integrity.

There are two types of keystores:

identity keystores: An identity keystore contains the server's private key and is therefore referred to as the identity. This keystore can contain more than one private key.

trust keystores: A trust keystore contains the root and intermediate certificates which are trusted by the server.

However, using these demo certificates is not recommended in a production environment because they do not provide adequate security. Instead of using the demo certificates, we can either get our certificates signed by a third-party certifying authority or use self-signed certificates (use our own root ca which we can use to sign our own certificates).

since for demonstration purpose we cannot afford a certificate signing authority to sign our certificate, we use self signed certificate.
For instance, lets try to install one on a weblogic server

Step1: create a private key/identity store:

$JAVA_HOME/keytool -genkey -alias slefcert -keyalg RSA -keypass weblogic1 -keystore identity.jks -storepass weblogic1 -validity 365

you will be asked a few questions like:
Organisation Unit=?
Organisation=?
City=?
State=?
County=?
after entering all the above details type 'yes'

Step2: being a self-signed, export the same cert into identity store (root cert)

$JAVA_HOME/keytool -export -alias mycert -file root.cer -keystore identity.jks -storepass weblogic1

Step3: import same cert into trust store which will be root.cert

$JAVA_HOME/keytool -import -alias selfcert -trustcacerts -file root.cer -keystore tust.jks -storepass weblogic1

this will list out your certificate request details
owner:
Issuer:
Serial number:
Validity:
certificate fingerprints:
Algorithms:
Version:

which will ask you to trust this certificate? : 'yes'
and it will add the certificate to your keystore

now after successful generation of certs, let weblogic know what have you generated

login to console & navigate to : servers > serverName > configuration > keystore

-custom identity keystore : path to your identity.jks
-custom identity keystore type: jks
-custom identity keypass : weblogic1
-custom identity identity store pass : weblogic1
-custom trust keystore: path to your trust.jks
-custom trust keystore type: jks
-custom trust keypass: weblogic1
-custom trust trust store pass: weblogic1

navigate to SSL tab and update following:

-private key alias: selfcert
-private key pass: weblogic1

enable SSL port by navigation to configuration > general and update the port number

restart the service for changes to take effect

now try to access the service on https://localhost:7002/console
(here I have installed cert on admin server of weblogic domain)

Apache SSL Installation Instructions

Save the primary and intermediate certificates to a folder on the server with the private key.

Open the Apache configuration file in a text editor httpd.conf In most cases the <VirtualHost> blocks will be at the bottom of this httpd.conf file. Sometimes you will find the <VirtualHost> blocks in a separate file in a directory like /etc/httpd/vhosts.d/ or /etc/httpd/sites/ or in a file called ssl.conf

If you need your site to be accessible through both secure (https) and non-secure (http) connections, you will need a virtual host for each type of connection. Make a copy of the existing non-secure virtual host and change the port from port 80 to 443.

& add below lines as


 <VirtualHost 192.168.0.1:443>

 DocumentRoot "/var/www/htdocs"
 ServerName www.domain.com
 SSLEngine on
 SSLCertificateFile "/etc/ssl/crt/primary.crt"
 SSLCertificateKeyFile "/etc/ssl/crt/private.key"
 SSLCACertificateFile "/etc/ssl/crt/intermediate.crt"
 </VirtualHost>

2. Change the names of the files and paths to match with your certificate files:

SSLCertificateFile should be your primary certificate file for your domain name.

SSLCertificateKeyFile should be the key file generated when you created the CSR.

SSLCertificateChainFile should be the intermediate certificate file (if any) that was supplied by your certificate authority
(The first directive tells Apache how to find the server certificate file, the second one where the private key is located, and the third line the location of the Trust CA Bundle.)

Save the changes and exit the text editor.
After making changes to your config file it is good practice to check the file for syntax errors using apachectl configtest. The command will return Syntax OK if there are no errors.

Restart your Apache web server using one of the following commands:


 $ /bin/apachectl startssl && /bin/apachectl restart

Note: make sure to un comment mod_ssl.so from httpd.conf

Additionally you can generate your apache self signed certificate

Once you have OpenSSL installed, just run this one command to create an Apache self signed certificate:


 $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ 
   -keyout mysitename.key -out mysitename.crt

You will be prompted to enter your organizational information and a common name. The common name should be the fully qualified domain name for the site you are securing (www.mydomain.com). You can leave the email address, challenge password, and optional company name blank.

When the command is finished running, it will create two files:

mysitename.key
mysitename.crt self signed certificate file which is valid for 365 days.

Br,
Punit