Wednesday, 7 October 2015

Five reasons to be excited about IBM Operational Decision Manager v8.8

I saw this on Twitter: -


The ability to handle change within operational systems is a critical competency as businesses digitize their workflows, focus on their customer experience and reinvent their businesses.  IBM's Smarter Process portfolio has been at the forefront of helping our customers with this mission and today we're excited to share some new developments within our portfolio.  We've made our flagship, industry-leading decision management platform, IBM Operational Decision Manager – IBM ODM  – even better with the release of IBM ODM v8.8, announced on 6th October 2015.
at No comments:

Tuesday, 6 October 2015

Java Development - Where are my HttpServlet and HttpServletRequest types ?

I saw a huge batch of exceptions, including: -

HttpServlet cannot be resolved to a type
HttpServletRequest cannot be resolved to a type
HttpServletRequest cannot be resolved to a type
HttpServletResponse cannot be resolved to a type
HttpServletResponse cannot be resolved to a type
ServletException cannot be resolved to a type
ServletException cannot be resolved to a type
The import javax.servlet cannot be resolved
The import javax.servlet cannot be resolved
The import javax.servlet cannot be resolved
The import javax.servlet cannot be resolved
The import javax.servlet cannot be resolved
WebServlet cannot be resolved to a type

when I attempted to compile a new Java servlet using Eclipse, either Luna or Mars.

In both cases, I had the requisite Java EE version of the IDE, and yet .....

This: -


amongst other things made me realise what I was missing.

Whilst I had the Eclipse IDE, I didn't have a target runtime :-)

I'd downloaded the latest Eclipse Mars from IBM Bluemix here: -


but I was missing a runtime ( this is on my Mac running OS X10.10.5 ).

I downloaded WebSphere Liberty Profile ( WAS Liberty with Java EE 7 Full Platform ) from here: -


and expanded it: -

unzip ~/Downloads/wlp-javaee7-8.5.5.7.zip 

Once I configured Eclipse to use Liberty and, more importantly, changed my JEE project to use Liberty as a Targeted Runtime: -


all the nasty errors went away :-)

at No comments:

Monday, 5 October 2015

IBM HTTP Server - Fun with Transport Layer Security

I've been experimenting with encryption in the context of IBM HTTP Server (IHS), specifically in terms of enforcing Transport Layer Security (TLS) 1.2 and a tight set of ciphers.

Firstly, I generated a signer certificate using the IBM Global Security Toolkit (GSK) with a key length of 2048 bits using the Secure Hashing Algorithm (SHA) as the signature algorithm and Rivest-Shamir-Adleman (RSA) as the encryption algorithm.

This is how I did it: -

/opt/ibm/HTTPServer/bin/gskcapicmd -cert -create -db /opt/ibm/HTTPServer/ssl/keystore.kdb -pw passw0rd -size 2048 -dn "cn=wasdemo.uk.ibm.com,dc=uk,dc=ibm,dc=com" -label "wasdemo.uk.ibm.com" -default_cert yes -sigalg SHA256WithRSA  

Having done this, and validated it: -

/opt/ibm/HTTPServer/bin/gskcapicmd -cert -details -db /opt/ibm/HTTPServer/ssl/keystore.kdb -pw passw0rd -label "wasdemo.uk.ibm.com"

...
Key Size : 2048
Version : X509 V3
...
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 : 
    41 BB 35 E5 6B 21 01 01 4E B4 5E 4B FC 09 BE B5
    B2 FD 7B A2
Fingerprint : MD5 : 
    AC D8 C2 E0 2B E1 23 24 3A DF E8 4A 5E 74 CC CA
Fingerprint : SHA256 : 
    4D 6D A5 5F 72 6E 35 32 AC DA DE AD 65 E9 6A A1
    F8 3B AB A3 B3 08 DC 43 4D 15 4C 3E 78 23 F5 A6
...
Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
...

I then reconfigured the IHS configuration - httpd.conf - for TLS: -

...
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 8443
<VirtualHost *:8443>
SSLFIPSEnable
SSLProtocolEnable TLSv12
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLCipherSpec TLSv12 TLS_RSA_WITH_AES_256_CBC_SHA256SSLEnable
</VirtualHost>
KeyFile /opt/ibm/HTTPServer/ssl/keystore.kdb
SSLCacheErrorLog /opt/ibm/HTTPServer/logs/sidd_log
SSLCachePortFilename /opt/ibm/HTTPServer/logs/siddport
ScriptSock logs/cgisock
SSLDisable
...

I've highlighted the four pertinent lines, one of which enforces a specific cipher - TLS_RSA_WITH_AES_256_CBC_SHA256.

I then validated the SSL/TLS configuration: -

 /opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name: wasdemo.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/ibm/HTTPServer/conf/httpd.conf:858
Server name: wasdemo.uk.ibm.com:8443
SSL enabled: YES
FIPS enabled: 1
Keyfile: /opt/ibm/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)
Ciphers for TLSv12: TLS_RSA_WITH_AES_256_CBC_SHA256(3D)

Syntax OK

which looked A-OK.

I then started IHS: -

/opt/ibm/HTTPServer/bin/apachectl -k start -f /opt/ibm/HTTPServer/conf/httpd.conf

I then monitored the error log: -

tail -f /opt/ibm/HTTPServer/logs/error_log 

[Mon Oct 05 13:55:36 2015] [notice] Using GSKit version 8.0.50.34
[Mon Oct 05 13:55:36 2015] [notice] WebSphere Plugins loaded.
[Mon Oct 05 13:55:36 2015] [notice] Bld version: 8.5.5
[Mon Oct 05 13:55:36 2015] [notice] Bld date: Oct 30 2014, 11:39:36
[Mon Oct 05 13:55:36 2015] [notice] Webserver: IBM_HTTP_Server
[Mon Oct 05 13:55:36 2015] [notice] Using config file /opt/ibm/HTTPServer/conf/httpd.conf 
[Mon Oct 05 13:55:36 2015] [notice] IBM_HTTP_Server/8.5.5.4 (Unix) configured -- resuming normal operations
[Mon Oct 05 13:55:36 2015] [notice] Core file limit is 0; core dumps will be not be written for server crashes

and tested IHS using a variety of browsers ( on my Mac, whilst IHS runs on Linux ): -


Interestingly, I got a variety of responses, none of them good: -

Firefox 41.0.1

An error occurred during a connection to wasdemo.uk.ibm.com:8443. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) 

Chrome 45.0.2454.101
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Opera 32.0

This webpage is not available

A secure connection cannot be established because this site uses an unsupported protocol.

Interestingly, Apple Safari had a completely different result: -

Safari Version 9.0 (10601.1.56.2)

It just worked :-)

I checked the IHS error log, and saw: -

[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9780028d0] [123070] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51689 -> 192.168.1.80:8443] [13:58:41.000261206] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9800028d0] [123106] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51690 -> 192.168.1.80:8443] [13:58:41.000268287] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd97c0008c0] [123070] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51691 -> 192.168.1.80:8443] [13:58:41.000611417] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9840008c0] [123106] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51692 -> 192.168.1.80:8443] [13:58:41.000632584] 0ms
After some digging, consideration and further digging, I concluded that it's all my fault :-)

In essence, I've chosen a cipher that the three "failing" browsers do not support, and I've "told" IHS to only use that one cipher.

There were a few mitigations: -

(1) Amend httpd.conf and relax the need to only use that one cipher: -

SSLCipherSpec TLSv12 +TLS_RSA_WITH_AES_256_CBC_SHA256

( in other words, I added a single plus + character to the beginning of the cipher name )

This is validated thusly: -

/opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name: wasdemo.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/ibm/HTTPServer/conf/httpd.conf:858
Server name: wasdemo.uk.ibm.com:8443
SSL enabled: YES
FIPS enabled: 1
Keyfile: /opt/ibm/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)
Ciphers for TLSv12: TLS_RSA_WITH_AES_128_GCM_SHA256(9C),TLS_RSA_WITH_AES_256_GCM_SHA384(9D),TLS_RSA_WITH_AES_128_CBC_SHA256(3C),TLS_RSA_WITH_AES_128_CBC_SHA(2F),TLS_RSA_WITH_AES_256_CBC_SHA(35b),SSL_RSA_WITH_3DES_EDE_CBC_SHA(3A),TLS_RSA_WITH_AES_256_CBC_SHA256(3D)

Syntax OK

(2) Choose another cipher IF I wish to only offer one up: -

SSLCipherSpec TLSv12 TLS_RSA_WITH_AES_256_CBC_SHA

Note how similar that is to the one that I had previously chosen: -

Old / non-working TLS_RSA_WITH_AES_256_CBC_SHA256
Working TLS_RSA_WITH_AES_256_CBC_SHA

/opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name: wasdemo.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/ibm/HTTPServer/conf/httpd.conf:858
Server name: wasdemo.uk.ibm.com:8443
SSL enabled: YES
FIPS enabled: 1
Keyfile: /opt/ibm/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)
Ciphers for TLSv12: TLS_RSA_WITH_AES_256_CBC_SHA(35b)

Syntax OK

My conclusion is four-fold: -

(i) Obviously Firefox, Chrome and Opera don't support TLS_RSA_WITH_AES_256_CBC_SHA256 whereas TLS_RSA_WITH_AES_256_CBC_SHA is OK
(ii) Do I really need to only expose a single cipher ? What happens if a client pitches up who just can not support that ?
(iii) If not (ii), then the use of the + symbol allows the browser to negotiate an agreed cipher within a fairly limited range
(iv)  Safari rocks :-)

Interestingly, there was obviously nothing wrong with TLS_RSA_WITH_AES_256_CBC_SHA256 as I was able to successfully validate the configuration: -

/opt/ibm/HTTPServer/bin/apachectl configtest 

Syntax OK

However, once I moved to a single AND supported/working cipher - - the browsers were all happy: -

Opera


Chrome

Firefox



Safari

So I couldn't find a way to get Safari to display a padlock for certain sites, including this one :-(

And Finally

For the record, I also validated the secure connection using openssl from the Red Hat CLI, as follows: -

openssl s_client -connect wasdemo.uk.ibm.com:8443

CONNECTED(00000003)
depth=0 DC = com, DC = ibm, DC = uk, CN = wasdemo.uk.ibm.com
verify error:num=18:self signed certificate
verify return:1
depth=0 DC = com, DC = ibm, DC = uk, CN = wasdemo.uk.ibm.com
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
   i:/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfjCCAmagAwIBAgIIWz28JlZ2dN4wDQYJKoZIhvcNAQELBQAwXTETMBEGCgmS
JomT8ixkARkTA2NvbTETMBEGCgmSJomT8ixkARkTA2libTESMBAGCgmSJomT8ixk
ARkTAnVrMR0wGwYDVQQDExRuZW1kZW1vLm5ic25ldC5jby51azAeFw0xNTEwMDIw
NTU4MDlaFw0xNjEwMDIwNTU4MDlaMF0xEzARBgoJkiaJk/IsZAEZEwNjb20xEzAR
BgoJkiaJk/IsZAEZEwNpYm0xEjAQBgoJkiaJk/IsZAEZEwJ1azEdMBsGA1UEAxMU
bmVtZGVtby5uYnNuZXQuY28udWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDDYlZ/rqMSk8VYTSc0SjaReE75vK5wE+Bn7UAk4tU4VOGV760Gb66norBt
YK/RaoSqfrpxXFapNwXl6w1N37a4tECbtN+hn/6cS312DD4fXVR/bTBJwbxb9Jy3
N2SUlfzEgCfWyopTtNa0BID7M4aWS3F5/D52eCRMVszfJhpm/NCDF1FWCSk+UN1I
dbHnv91tMAGLGVrZ79YMhQH9wyU8Wpujr3/mGU3JuejCDFAXLhtxe7/59FvRLsWw
DGbIrEGbwp9tiGpKUBQT7xt3tr4j/DhZNLz1seS+I3jgFcuF416u3HsVj6Iv4C1j
OAEaC7Jvnkv0p++ceNGW/7ipkBWNAgMBAAGjQjBAMB0GA1UdDgQWBBS+o2rAAIZl
ydjc3Tvr2GssMllXdDAfBgNVHSMEGDAWgBS+o2rAAIZlydjc3Tvr2GssMllXdDAN
BgkqhkiG9w0BAQsFAAOCAQEAaSa8+jdSnp6YaMqjtRtJmRBKkXgFRnvM+/CBEZGg
EP26wmg7QJHmcou8neL9sQoE+73JuBiW4WlUfb2Ah/So5RJIGJJT4dXemj0DFaSN
7FtZBIIeeQosBYkddqR7Hs5AvKtUK3m0l9axlLRPRIMcgzGrtw81A9BhJjTo+2J6
YmFF6aSOHIoYbFLfjxdswGVxR//nomikQCIp+MEBvMKC9yvj/mIR6MN0ajJhspNc
nS9+9M1pPJoakxaEwJvH7J2m78PaCelZKmJIT/tuYQyvFkkY7wPa5wKhEM3ygyCK
wCYU3gndC/O649huI6PqvNeXIaYZW4UNTerMK+yN+RjUuA==
-----END CERTIFICATE-----
subject=/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
issuer=/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
---
No client certificate CA names sent
---
SSL handshake has read 1073 bytes and written 591 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA    Session-ID: E3E101009910CB491F45C7B8645FBE55D98F6B0258585858AC87125600000042
    Session-ID-ctx: 
    Master-Key: DFB1AE0092F7EE2A0815C803E0BF80DC9520E9657B4670F8311DAF40B79170F5D91D4D8B4C389BE110CED221F090FB7E
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1444054956
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

*UPDATE 6 October 2015*

This section of the IBM Knowledge Center: -

SSL cipher specifications

was also extremely useful.

*UPDATE 6 October 2015*

at 1 comment:

Friday, 2 October 2015

Mac OS X - Finder - Open in Terminal

I love the internet, I really really love the internet.

I have a requirement, I go to Google, I search for a solution, and I find ... a solution :-)

The context ....

I was looking for a script ( federateIHS.sh ) on a Red Hat VM, running within VMware Fusion.

The script wasn't on the VM, but was available within a folder on the host Mac.

I found the script using Spotlight ( via [CMD][Space] ) and was then trying to work out how to quickly get it from OS X to Linux.

I know I could open Terminal, navigate to the folder ( /Users/davehay/Documents/Docs.ISSW/WebSphere/MTA2015 ) and then send it to Linux ( scp federateIHS.sh wasadmin@bpmdemo:~ ).

How could I do it more simply ?

In Windows, I'd have leveraged the functionality built into the shell, and opened a command prompt ( aka the DOS box ).

So I went to Google and typed .... finder open command prompt here

and found this: -


This talked me through creating a Service within the Terminal application.

Once I followed this, I was able to do this: -


which is nice.

I'm now looking for an equivalent to New Terminal at File but that'll do for now :-)

at No comments:

Thursday, 1 October 2015

WASX7023E: Error creating "SOAP" connection to host "localhost" after enabling TLS 1.2

On the back of my earlier post: -


having changed my WAS cell to only support TLS 1.2, I then realised that the WSAdmin client would no longer work.

/opt/ibm/ODM/WebSphereProfiles/ODMCell1Dmgr01/bin/wsadmin.sh -lang jython -hostname `hostname`.uk.ibm.com -port 13503

WASX7023E: Error creating "SOAP" connection to host "localhost"; exception information: com.ibm.websphere.management.exception.ConnectorNotAvailableException: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error parsing HTTP status line &quot;&quot;: java.util.NoSuchElementException; targetException=java.lang.IllegalArgumentException: Error parsing HTTP status line "": java.util.NoSuchElementException]

WASX7213I: This scripting client is not connected to a server process; please refer to the log file /opt/ibm/ODM/WebSphereProfiles/ODMCell1Dmgr01/logs/wsadmin.traceout for additional information.

WASX8011W: AdminTask object is not available.

WASX7411W: Ignoring the following provided option: [-hostname, wasdemo.uk.ibm.com]

WASX7031I: For help, enter: "print Help.help()"
This time I knew where to look, and what to change.

Sure enough, I checked out: -

/opt/ibm/ODM/WebSphereProfiles/ODMCell1Dmgr01/properties/ssl.client.props

and found: -

com.ibm.ssl.protocol=SSL_TLS

where I should've seen: -

com.ibm.ssl.protocol=TLSv1.2

Once I amended the file, all was well.

I'm guessing, but haven't yet checked, that I could've simply overridden the property file with a command-line parameter such as -D com.ibm.ssl.protocol=TLSv1.2 

Something to check here: -



at No comments:

JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security

How does the song go ? "Oops, I did it again" ?

I'd previously blogged about this problem a few months back: -


Well, yesterday I went through the process of enabling Transport Layer Security (TLS) 1.2 as the default SSL/TLS protocol within a WAS 8.5.5 cell ( hosting IBM ODM Advanced 8.7 for the record ).

This is the command that I ran: -

AdminTask.modifySSLConfig('[-alias CellDefaultSSLSettings -scopeName (cell):odm87Cell1 -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):odm87Cell1 -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):odm87Cell1 -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers ]')

 I then saved and synced the cell: -

AdminConfig.save()
AdminNodeManagement.syncActiveNodes()

( The Deployment Manager and two Node Agents were already running )

I then found that the nodes failed to connect to the Deployment Manager, and I saw: -

[30/09/15 15:42:21:934 BST] 000000c7 ORBRas        E com.ibm.ws.security.orbssl.WSSSLClientSocketFactoryImpl createSSLSocket ProcessDiscovery : 0 JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security.  Reason: Server chose TLSv1, but that protocol version is not enabled or not supported by the client. javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.

Using my prior experience, I immediately checked the security.xml file at the node level i.e. on each of the two nodes: -

/opt/ibm/WebSphereProfiles/ODMCell1AppSrv01/config/cells/odm87Cell1/security.xml

Lo and behold, I saw: -

>     <setting xmi:id="SecureSocketLayer_1" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1" trustStore="KeyStore_2" trustManager="TrustManager_2" keyManager="KeyManager_1">

whereas I should've seen: -

<     <setting xmi:id="SecureSocketLayer_1" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="TLSv1.2" keyStore="KeyStore_1" trustStore="KeyStore_2" trustManager="TrustManager_2" keyManager="KeyManager_1">

I manually edited the file on each of the two nodes, and restarted the Node Agent on each.

Once done, the nodes started happily, connected to the Deployment Manager without problems, and allowed me to perform a FULL synchronisation of the entire cell.

The moral of the story ?

When I ran the AdminTask.modifySSLConfig command, I should've run the command to perform a FULL synch. of the cell.

Guess what I'll do next time ?

at 2 comments:

IBM BPM Advanced 8.5.6 - Cumulative Fix 1

I almost missed this yesterday: -


Definitely worth a look ....
at No comments:
Subscribe to: Posts (Atom)

Note to self - Firefox and local connections

 Whilst trying to hit my NAS from Firefox on my Mac, I kept seeing errors such as:- Unable to connect Firefox can’t establish a connection t...