Tag Archives: Security

Using OWSM UsernameToken for authentication and authorisation of OSB services

With the use of Oracle Web Service Manager (OWSM) we can easily configure Oracle Service Bus (OSB) services with different message security polices. This configuration can be done from Eclipse (OEPE), OSB SBConsole or the Enterprise Manager. One of the most common WS-Security mechanismes and therefor also OWSM policies is the UsernameToken where a username and password are send along with the message.

In this blog we will:

  • part I: how to enable authentication of users against the list of all known users
  • part II: how to enable authorisation of only a specific subset of users to access a service

First we configure a proxy service in OEPE with the OWSM UsernameToken policy oracle/wss_username_token_service_policy:

And make sure we process the WS-Security header:

After deployment we call the service with a request that is missing the WS-Security to test the result.

<soapenv:Envelope xmlns:soapenv="">
         <in>I say hello ...</in>

As expected the result is an error because the OWSM policy requires a WS-Security segment in the SOAP-header which contains a username and password:

<soapenv:Envelope xmlns:soapenv="">
         <faultstring>BEA-386200: General web service security error</faultstring>
            <con:fault xmlns:con="">
               <con:reason>General web service security error</con:reason>

So to make sure we can send a UsernameToken we add 2 users to the Weblogic security realm called userA and userB.

The request to the proxy service containing the WS-Security UsernameToken for userA

<soapenv:Envelope xmlns:soapenv="">
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="">
         <wsse:UsernameToken wsu:Id="UsernameToken-4" xmlns:wsu="">
            <wsse:Password Type="">welcomeA1</wsse:Password>
         <in>I say hello ...</in>

This results in a successfull response from the proxy service:

<soapenv:Envelope xmlns:soapenv="">

So part 1 is complete, we succesfully implemented a proxy service that requires a WS-Security UsernameToken and authenticates these users against the Weblogic security realm. But in our case we have a tight security requirement and need to make sure the user is not only authenticated, but also authorized to access this specific service.

The result from part 1 means this is not the case, both userA and userB would be able to access this service. So let’s start part 2 where we will limit the access to the proxy service to only userB. For this we have to login to the sbconsole, since the OEPE does not allow you to make Message (or Transport) Access Control settings.

  • Login the sbconsole
  • Select Project Explorer
  • Select the the proxy service
  • Go to the Security Tab

  • Click on Message Access Control option (either for the whole service or just a single operation).
  • Click on Add Condition
  • Select User from predicate list
  • Type userB at the User Argument Name
  • Click on Add and Finish
  • Click on Save and Activate to finish the OSB session
Next thing we can call the service again and this time with userB and we still receive a succesfull result.
However if we call the service again with a UsernameToken containing userA we get the following SoapFault:
<soapenv:Envelope xmlns:soapenv="">
         <faultstring>BEA-386102: Message-level authorization denied</faultstring>
            <con:fault xmlns:con="">
               <con:reason>Message-level authorization denied</con:reason>

Part 2 is completed and we finished with a proxy service that has both Authentication and Authorization enabled.


  • You can also use groups and roles (rather than users) to authorize access to services.
  • If you implement and configure an external LDAP (like Oracle Internet Directory) in Weblogic you can control ACL with groups central in your company LDAP instead of in each Weblogic security realm.
  • The SOAP fault for Message Level Authorization denied (BEA-386102) contains a faultcode value of “Server” which is not correct if you look at the w3c definition. This should be the value “Client” because: “….. the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change”

Update 2011-08-10:
Added 3rd remark regarding the SOAP Fault code

Update 2012-01-13:
Using the OWSM username token policies you get some additional information on runtime in you $inbound variable. See this blogpost for more details.


Posted by on 09-08-2011 in OSB, WS-Security


Tags: , , ,

Weblogic and OSB various keystore reminders

Default Weblogic DemoIdentity and DemoTrust keystore:

I always forget the default passwords, so a quick reminder:

Location: %WL_HOME%/server/lib
File = DemoIdentity.jks

  • keystore password = DemoIdentityKeyStorePassPhrase
  • key password = DemoIdentityPassPhrase
  • keytool -list -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase

File = DemoTrust.jks

  • keystore password = DemoTrustKeyStorePassPhrase
  • 	keytool -list -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase
Generate a new private key:

Go to the security folder in your domain (the SerializedSystemIni.dat is also located here, so you already need to secure this folder):

keytool -genkey -keysize 2048 -keyalg RSA -alias myhostname01 -keystore myhostname01_identity.jks

Generate a Certificate Request:

keytool -certreq -alias myhostname01 -file myhostname01.csr -keystore myhostname01_identity.jks

Send this CSR file to your Certificate Authority

Import signed response:

keytool -importcert -trustcacerts -alias rootCA -file rootCA.cer -keystore myhostname01_identity.jks -storepass mySecretPassword
keytool -importcert -alias chaincert1 -file chaincert1.cer -keystore myhostname01_identity.jks -storepass mySecretPassword
keytool -importcert -alias myhostname01 -file myhostname01.cer -keystore myhostname01_identity.jks -storepass mySecretPassword

import P12 into JKS:

keytool -v -importkeystore -srckeystore somecert.p12 -srcstoretype PKCS12 -destkeystore mytruststore.jks -deststoretype JKS

Configure Eclipse OEPE with custom keystore:

  • Right-click OSB Configuration in Project Explorer
  • Select Oracle Service Bus Configuration
  • Configure the keystore file and the storepassword
  • You can now add a ServiceKeyProvider to your project to act as a SSL-client
Leave a comment

Posted by on 04-08-2011 in OSB, Security, Weblogic


Tags: , ,

Weblogic Security Realm WLST import and export

>This is just a reminder for myself, the code is not mine but can be found at multiple places on the web so I have no idea who the initial owner is and who to give credits.

export configuration:

java weblogic.WLST
connect('weblogic','weblogic', 't3://somedomain:7001')
cmo.exportData('DefaultAtn','/tmp/export.ldif', Properties())

import configuration:

java weblogic.WLST
connect('weblogic','weblogic', 't3://someotherdomain:7001')
cmo.importData('DefaultAtn','/tmp/export.ldif', Properties())
Leave a comment

Posted by on 18-06-2011 in Oracle, Weblogic, WLST


Tags: , , ,

Weblogic and IIS two-way TLS/SSL issue (debugging)

I’m blogging this to help other people who might experience the same problem. On the other hand there are some loose ends where someone out there might contribute to.

So a project required SOAP/HTTP(S) requests over two-way SSL between Oracle Service Bus and a remote service running on Microsoft IIS 6.0.

Weblogic & OSB setup:
All certicates are stored in keystores and used by the nodemgr + admin + ms.
Weblogic has a PKICredentialMapper and in the SBconsole we have our ServiceKeyProvider configured. We build our proxy and business services where:
– BS is confgured with SSL and Authentication ClientCert (http transport Tab)
– PS is configured with the ServiceKeyProvider on the Security tab

Pretty default stuff, working with other backends. The callout however fails and the IIS guys claim they never receive a client-cert.

Callout from OSB:
clientIPhere, -, 1/11/2011, 15:51:18, serviceNameHere, serverNameHere, serverIPhere, 449859, 1160, 0, 403, 64, POST, /SomeService.asmx, -,

Callout from SOAPui from client workstation:
clientIPhere, -, 1/11/2011, 16:01:21, serviceNameHere, serverNameHere, serverIPhere, 187, 918, 916, 200, 0, POST, /SomeService.asmx, -,

According to this page the 403 is a forbidden error and the 0 in front of it means 0 bytes have been send from the server to the client.

So we enable Weblogic SSL debugging with the arguments: -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true

After the next callout we see this in the logging:

</soap:Body>>   *<-------- this is the last $body logging in the ProxyService before it calls the business* <Debug> <SecuritySSL> <BEA-000000> <SSLSetup: loading trusted CA certificates><Debug> <SecuritySSL> <BEA-000000> <clientInfo has new style certificate and key><Debug> <SecuritySSL> <BEA-000000> <Filtering JSSE SSLSocket><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.addContext(ctx): 270694655><Debug> <SecuritySSL> <BEA-000000> <SSLSocket will  be Muxing><Debug> <SecuritySSL> <BEA-000000> <write SSL_20_RECORD><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: ServerHello><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: Certificate><Debug> <SecuritySSL> <BEA-000000> <Validating certificate 0 in the chain: Serial number: 130583870796631153730390131696172958331Issuer:C=xxxxxxxxxxNot Valid Before:Wed Oct 20 02:00:00 CEST 2010Not Valid After:Sun Oct 20 01:59:59 CEST 2013Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <Validating certificate 1 in the chain: Serial number: 50682576685400420811231509872710703774Issuer:C=xxxxxxxNot Valid Before:Tue Jun 07 10:09:10 CEST 2005Not Valid After:Sat May 30 12:48:38 CEST 2020Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <validationCallback: validateErr = 0><Debug> <SecuritySSL> <BEA-000000> <  cert[0] = Serial number: 130583870796631153730390131696172958331Issuer:C=xxxxxxxxxxSubject:C=xxxxxxxNot Valid Before:Wed Oct 20 02:00:00 CEST 2010Not Valid After:Sun Oct 20 01:59:59 CEST 2013Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <  cert[1] = Serial number: 50682576685400420811231509872710703774Issuer:CxxxxxxxxNot Valid Before:Tue Jun 07 10:09:10 CEST 2005Not Valid After:Sat May 30 12:48:38 CEST 2020Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <weblogic user specified trustmanager validation status 0><Debug> <SecuritySSL> <BEA-000000> <SSLTrustValidator returns: 0><Debug> <SecuritySSL> <BEA-000000> <Trust status (0): NONE><Debug> <SecuritySSL> <BEA-000000> <Performing hostname validation checks:><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: ServerHelloDone><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm MD5><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RSA><Debug> <SecuritySSL> <BEA-000000> <write HANDSHAKE, offset = 0, length = 134><Debug> <SecuritySSL> <BEA-000000> <write CHANGE_CIPHER_SPEC, offset = 0, length = 1><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <write HANDSHAKE, offset = 0, length = 16><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received CHANGE_CIPHER_SPEC><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: Finished><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 321><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 839><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.findContext(sock): 270693819><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.findContext(sock): 270693819><Debug> <SecuritySSL> <BEA-000000> <activateNoRegister()><Debug> <SecuritySSL> <BEA-000000> <SSLFilterImpl.activate(): activated: 270693844 270909954><Debug> <SecuritySSL> <BEA-000000> <270694391 read(offset=0, length=4080)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns true><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <NEW ALERT with Severity: WARNING, Type: 100java.lang.Exception: New alert stack        at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)        at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)        at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)        at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)        at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)        at Source)        at Source)        at weblogic.socket.SSLFilterImpl.isMessageComplete(        at weblogic.socket.SocketMuxer.readReadySocketOnce(        at weblogic.socket.SocketMuxer.readReadySocket(        at weblogic.socket.EPollSocketMuxer.dataReceived(        at weblogic.socket.EPollSocketMuxer.processSockets(        at        at weblogic.socket.SocketReaderRequest.execute(        at weblogic.kernel.ExecuteThread.execute(        at><Debug> <SecuritySSL> <BEA-000000> <write ALERT, offset = 0, length = 2><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns false 1><Debug> <SecuritySSL> <BEA-000000> <270694391 Rethrowing InterruptedIOException><Debug> <SecuritySSL> <BEA-000000> <270694391 read(offset=0, length=8192)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <264112838 read(offset=0, length=4080)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns true><Debug> <SecuritySSL> <BEA-000000> <264114219 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <264114219 received APPLICATION_DATA: databufferLen 0, contentLength 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read databufferLen 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read A returns 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read(offset=29, length=4051)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns false 1><Debug> <SecuritySSL> <BEA-000000> <264112838 Rethrowing InterruptedIOException><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 29>

Just before the dump we see a: Warning, Type 100. The TLS protocol states informs us that this alert 100 would mean NO_RENEGOTIATION:

A.3. Alert messages

    enum { warning(1), fatal(2), (255) } AlertLevel;

        enum {            close_notify(0),            unexpected_message(10),            bad_record_mac(20),            decryption_failed(21),            record_overflow(22),            decompression_failure(30),            handshake_failure(40),            bad_certificate(42),            unsupported_certificate(43),            certificate_revoked(44),            certificate_expired(45),            certificate_unknown(46),            illegal_parameter(47),            unknown_ca(48),            access_denied(49),            decode_error(50),            decrypt_error(51),            export_restriction(60),            protocol_version(70),            insufficient_security(71),            internal_error(80),            user_canceled(90),            no_renegotiation(100),            (255)        } AlertDescription;

    struct {        AlertLevel level;        AlertDescription description;    } Alert;

So we use Wireshark which is one of the coolest free software tools out there. And even better, did I mention it’s free? With a Wireshark capture you can get a lot of information about the connection.

Essentially, what is going on here can be summarized as:

– Step 4: The client makes a hello request
– Step 8: The server responds with its certificate
– Step 10: The client key is send to server
– Step 11+12: Clients send a change of cipher spec and handshake message
– Step 14: Server send a change of cipher spec and handshake message
– Step 19: We see another server triggered handshake message followed by
– Step 20: Encrypted Alert

Since we are looking for something interesting, this Encrypted Alert is it. The problem here is that you can see an Alert but cant see the exact alert type.

I was hoping for a CERT_CHAIN_UNTRUSTED or BAD_CERTIFICATE since that would give me a good direction. But it looks like Weblogic logging shows an alert 100 (no_renegotiation) and we had to go with that.

Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters
(key length, authentication, etc.) at startup and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.

I’m still not fully convinced of a no_renegotiation. Because for the client to trigger a renegotiation, it should send a new Client Hello message (in the encrypted channel, like any other handshaking message) which then the server responds with a Server Hello, and negotiation goes exactly as above. Other case when the server initiates a renegotiation it will send the client a Hello Request message on which he client simply sends a new Client Hello, exactly as above, and the process goes as usual. In the wireshark captures this behavious is not visible.

I found this Wireshark capture in a document called “Renegotiating TLS” by Ray and Dispensa which shows the process of renegotiation.


So as a fix we tried switching over from JRockit to Sun JDK, tried some arguments but in the end rolled everything back since 1 simple options seem to solve the issue:

With older version of Weblogic you can use these arguments for the jvm:
-Dweblogic.wsee.client.ssl.usejdk=true (for webservice clients)

With the latest versions of Weblogic there is a “Use JSEE SSL” setting. The setting is located on the SSL (advanced) tab of the managed server.

So now our Wireshark capture looks like this:

The difference looks to occur after the server sends an encrypted handshake (ERR-capture step 19 & OK-capture step 42). In the OK-capture you can see the client sending an encrypted handshake after that (step 43), however the ERR-capture results in a Alert (step 20).

Focusing on the Weblogic logging and the NO_RENEGOTIATION message a guess would be that the different client implementations handle these renegotiations differently.

The Oracle Support Knowledge base mentions something like this (ID 1078957.1). The trace mentioned there isn’t identical as our error, however the solution seems to point in the same direction.

CAUSE = This may happen when the WebLogic server connects a remote Microsoft server.
This happened before the client got the ServerHello message. The Microsoft Server was refusing the handshake because the cipher suites given to the remote server were not 128 bits – the remote server wasn’t allowing anything lower. If the client license is changed on the WebLogic Server side, it will then work.

Our issue however is not identical (i think), because I can see that the client (weblogic) sends 19 cipher specs (among them TLS_RSA_WITH_RC4_128_MD5) and that the server agrees with this specific 00 44

TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA= { 0x00,0x63 }TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }TLS_DHE_DSS_WITH_NULL_SHA = { 0x00,0x67 }TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }

So our problems seems to be solved by using the Sun SSL implementation instead of the default Certicom one.

However that still leaves questions unanswered for me as:
– how come that other 2-way SSL trusts succeed with the default, but in this case with IIS6.0 as a service provider fails
– where does the 2-way SSL trust exactly fail, and how can I pinpoint this with tools like Wireshark ?
– what is the exact difference between Certicom and Sun’s implementation off TLS 1.0 ?


Posted by on 13-01-2011 in Oracle, OSB, Security, Weblogic


Tags: , , ,

Weblogic and Triple-DES decryption

After my earlier post regarding the Triple DES encryption Weblogic uses. The next question could be, can we decrypt the 3DES hash to cleartext again ? The answer is, yes you can.

On the Internet multiple examples are available, but I found this post from Chris Vugrinec ( hi m8 ) very helpfull so muchos credits to Chris.

Off course the java code needs to include the weblogic.jar and on runtime access to the domains SerializedSystemIni.dat which encapsulates a time-variant encrypted key created with the generation of the domain.


public class DrieDesDecrypter
  static ClearOrEncryptedService ces;
  public static void main(String[] args)
System.out.println("This class decrypts the 3DES string for Weblogic");
    Console console = System.console();
    String var_folder = console.readLine("Give PATH! where SerializedSystemIni.dat for weblogic domain is located: ");
    String var_driedes = console.readLine("Give 3DES string: ");
    ces = new ClearOrEncryptedService(SerializedSystemIni.getEncryptionService(var_folder));
    var_driedes = var_driedes.replace("\\", "");
    System.out.println("Decrypted value: " + ces.decrypt(var_driedes));

The 1st input is the Directory where the SerializedSystemIni.dat resides
The 2nd input is the encrypted 3DES String
The output  is what you wanted.
Running would look something like:

java DrieDesDecrypter

This class decrypts the 3DES string for Weblogic
Give PATH! where SerializedSystemIni.dat for weblogic domain is located: C:\Oracle\domains\rbx_dev_wls\security
Give 3DES string: {3DES}OOLr88wGSPx82H1abcYU9Q==
Decrypted waarde: welcome1

This source-code should trigger any Weblogic Administrator to make sure it’s SerializedSystemIni.dat file is secured to prevent unauthorised access and included in the backup procedure.

Update 2012.01.26:

Due to lost passwords on a DEV environment I had to test my class with the new AES encryption used by Weblogic 11g (r1PS4) instead of the older 3DES algoritm it used to store it’s passwords in. And it still works like a charm. :)

Update 2012.06.27:

Make life much easier for those DEV/TST domains:
Don’t think I would like to use it for my PRD domains, but you make your own choice there,


1 Comment

Posted by on 12-04-2010 in Oracle, Weblogic


Tags: , , ,

Weblogic and Triple-DES encryption

>Weblogic allows you to store clear-text passwords in configuration files when you have a development domain, however production mode forces the use of Triple-DES block ciphers to store these password. (that’s also the reason why the encrypted passwords begin with “{3DES}”)

Often this proces is done automatically by Weblogic, but in some cases it is good to know how to manually convert clear-text to a 3DES encrypted string. You can find these 3DES strings located in the domain’s config.xml,, the service accounts used by the Oracle Service Bus (even when you use the RDBMS Security Store under your weblogic domain), etc.

For this we will need the domain’s password salt file SerializedSystemIni.dat.
Cibergavin made a good post explaining the importance of this specific file for your Weblogic domain.

SerializedSystemIni.dat is a WebLogic domain file which contains hashes. SerializedSystemIni.dat is located in the domain directory (WebLogic Server 8.1 and earlier) or in domain/security directory (WebLogic Server 9.x and later). The SerializedSystemIni.dat is created during the creation of a WebLogic domain. The hashes in the file are created using an algorithm that binds the file to the domain in which it has been created. So, a SerializedSystemIni.dat file can be used only within the domain in which it has been created.

Due to the use of the salt file (SerializedSystemIni.dat) you should execute the utility from your domain folder:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

You can also pass the password as an argument:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

And last but not least you can use WLST:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...Welcome to WebLogic Server Administration Scripting ShellType help() for help on available commands

wls:/offline> es = encrypt('weblogic')wls:/offline> print es{3DES}p2rh5zuiDsut1yNTGtUfFg==wls:/offline>
1 Comment

Posted by on 09-04-2010 in Oracle, Weblogic, WLST


Tags: , ,

Weblogic WLST connections using SSL

When your Administration Server, NodeManager and Managed Servers use SSL to communicate with each other you have a decent basic security for your Weblogic domain. (And NO, the default demo certs/stores do not fullfill that requirement in production).

However communication from WLST to your weblogic domain needs some small adjustment. The normal steps would otherwise result in this error:

call "D:\myDomain\bin\setDomainEnv.cmd"
D:\myDomain>java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands

wls:/offline> connect('weblogic',weblogic','t3s://')

Connecting to t3s:// with userid weblogic ...

<8-apr-2010 13:39:55 uur CES> <Warning> <Security< <BEA-090542> <Certificate chain received from - was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify on the command line for this client.>

Traceback (innermost last):

File "<console>", line 1, in ?

File "<iostream>", line 22, in connect WLSTException: Error occured while performing connect : Error getting the initial context. There is no server running at t3s:// Use dumpStack() to view the full stacktrace


*note: I use port 7003 because the Domain Admin Port is enabled in my domain.

Anyway, the connection to the Admin Server can not be established through SSL because there is no trust between the two components. To fix this some additional arguments need to be added.

D:\myDomain>java"JKS""D:/myDomain/security/myDomain.truststore.jks" weblogic.WLST

wls:/offline> connect(‘weblogic’,’weblogic’,’t3s://′)

Successfully connected to Admin Server myDomain_admin’ that belongs to domain ‘myDomain’

wls:/myDomain/serverConfig> disconnect()

Disconnected from weblogic server: myDomain_admin

No let’s try to connect to the Nodemanager as well:

wls:/offline> nmConnect('weblogic','weblogic','','5556','myDomain','d:/myDomain','ssl')

Connecting to Node Manager …

Successfully Connected to Node Manager.



Posted by on 08-04-2010 in Oracle, Weblogic, WLST


Tags: , ,