4 Replies Latest reply on Apr 30, 2018 8:14 PM by user551320

    ORDS standalone jetty stuck in self-signed mode (and not producing TLS 1.2)


      Updating this question because I think my main issue is our ORDS Standalone seems stuck in self-signed mode per reply below. At this point I'm not sure if my original problem with only generating tls v1 is related and/or who's the cause and whose the effect. It may be 2 different problems as well.

      Sincere thanks if anyone can help. I've been trying to isolate the variables 1 by 1 but no luck so far......  


      Hi, I’ve got an ORDS Standalone Jetty installed with Java 1.8. We need it to produce TLSv1.2 but it only seems to generate TLSv1 instead.

      Trace below shows "*** ClientHello, TLSv1.2"  followed by  "*** ServerHello, TLSv1". 

      I suspect something is wrong in the java.security default values but I can't figure out what to change.

      Thanks ahead of time for any help/ideas anyone may have ?



      Oracle DB=12.2, ORDS=18.1, Apex=5.1, OS=AIX

        works fine from IE 11 so long as TLS1 is enabled



      java -version

      java version "1.8.0"

      Java(TM) SE Runtime Environment (build pap6480sr4fp10-20170727_01(SR4 FP10))

      IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20170722_357405 (JIT enabled, AOT enabled)

      J9VM - R28_20170722_0201_B357405

      JIT  - tr.r14.java_20170722_357405

      GC   - R28_20170722_0201_B357405_CMPRSS

      J9CL - 20170722_357405)

      JCL - 20170726_01 based on Oracle jdk8u144-b01



      echo $JAVA_HOME


      echo $PATH




      java -Djavax.net.debug=ssl:handshake:verbose -Dhttps.protocols=TLSv1.2 -jar ords.war standalone > zzz

      selected contents of zzz are:


      IBMJSSE2 will not allow protocol SSLv3 per com.ibm.jsse2.disableSSLv3 set to TRUE or default

      IBMJSSEProvider2 Build-Level: -20170606


      Installed Providers =










      SSLContextImpl:  Using X509ExtendedKeyManager org.eclipse.jetty.util.ssl.SniX509ExtendedKeyManager

      SSLContextImpl:  Using X509TrustManager com.ibm.jsse2.aB

      JsseJCE:  Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.8

      trigger seeding of SecureRandom

      done seeding SecureRandom

      IBMJSSE2 will enable CBC protection

      JsseJCE:  Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.8

      JsseJCE:  Using signature SHA1withECDSA from provider TBD via init

      JsseJCE:  Using signature NONEwithECDSA from provider TBD via init

      JsseJCE:  Using KeyAgreement ECDH from provider IBMJCE version 1.8

      JsseJCE:  Using KeyFactory EC from provider IBMJCE version 1.8

      JsseJCE:  Using KeyPairGenerator EC from provider TBD via init

      jdk.tls.client.protocols is defined as null

      SSLv3 protocol was requested but was not enabled

      SSLv3 protocol was requested but was not enabled

      SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]

      SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]

      CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]

      IBMJSSE2 will enable CBC protection

      Using SSLEngineImpl.


      IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set to none or default

      IBMJSSE2 will not require renegotiation indicator during initial handshake per com.ibm.jsse2.renegotiation.indicator set to OPTION

      AL or default taken

      IBMJSSE2 will not perform identity checking against the peer cert check during renegotiation per com.ibm.jsse2.renegotiation.peer.

      cert.check set to OFF or default

      IBMJSSE2 will allow client initiated renegotiation per jdk.tls.rejectClientInitiatedRenegotiation set to FALSE or default



      Is initial handshake: true

      Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_CBC_SHA256

      Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_CBC_SHA256

      JsseJCE:  Using AlgorithmParameters EC from provider IBMJCE version 1.8

      JsseJCE:  Using AlgorithmParameters EC from provider IBMJCE version 1.8

      JsseJCE:  Using AlgorithmParameters EC from provider IBMJCE version 1.8

      JsseJCE:  Using AlgorithmParameters EC from provider IBMJCE version 1.8

      Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_GCM_SHA256

      Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_GCM_SHA256

      qtp-1006810652-31, READ: TLSv1.2 Handshake, length = 219

      *** ClientHello, TLSv1.2

      RandomCookie:  GMT: 1507727810 bytes = { .....


      Extension signature_algorithms, signature_algorithms: SHA256withRSA, SHA384withRSA, SHA512withRSA, SHA1withRSA, SHA256withECDSA, S

      HA384withECDSA, SHA512withECDSA, SHA1withECDSA, SHA1withDSA

      Unsupported extension type_23, data:

      Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }


      JsseJCE:  Using MessageDigest MD5 from provider IBMJCE version 1.8

      JsseJCE:  Using MessageDigest SHA from provider IBMJCE version 1.8

      %% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]

      ssl: ServerHandshaker.setupPrivateKeyAndChain EC_EC

      ssl: ServerHandshaker.setupPrivateKeyAndChain, chooseEngineServerAlias null

      ssl: ServerHandshaker.setupPrivateKeyAndChain RSA

      matching alias: selfsigned

      ssl: ServerHandshaker.setupPrivateKeyAndChain, chooseEngineServerAlias selfsigned

      ssl: ServerHandshaker.setupPrivateKeyAndChain, return true

      JsseJCE:  Using KeyPairGenerator EC from provider TBD via init

      JsseJCE:  Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.8

      JsseJCE:  Using KeyPairGenerator EC from provider TBD via init

      ECDHCrypt:  ECDH KeyPairGenerator  from provider from init IBMJCE version 1.8

      %% Negotiating:  [Session-1, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA]

      *** ServerHello, TLSv1



      selected lines from the default jre/lib/security/java.security:




      jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \

          DSA keySize < 1024, EC keySize < 224

      jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

      jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, 3DES_EDE_CBC, DESede, \

          EC keySize < 224

      jdk.tls.legacyAlgorithms= \

              K_NULL, C_NULL, M_NULL, \


              DH_RSA_EXPORT, RSA_EXPORT, \

              DH_anon, ECDH_anon, \

              RC4_128, RC4_40, DES_CBC, DES40_CBC


          disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\

          disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\

          disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\

          disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\

          maxTransforms 5,\

          maxReferences 30,\

          disallowReferenceUriSchemes file http https,\

          minKeySize RSA 1024,\

          minKeySize DSA 1024,\



        • 1. Re: ORDS standalone jetty not producing TLS 1.2

          Think my problem is that it keeps dropping into self-signed mode (with tls 1) for some reason. How do I stop the self signing mode?

          I think this because:

          (a) This shows up when jetty starts: 2018-04-23 17:44:11.466:INFO:oejus.SslContextFactory:main: x509=X509@9cfccbee(selfsigned,h=[ourservername.acme.com],w=.....


          (b)  I delete these self-signed key+pem files but they keep showing up when I restart ords.war:


          ls -l

          total 40

          -rw-r--r--    1 something   something         2482 Apr 23 17:44 self-signed.key

          -rw-r--r--    1 something   something         1361 Apr 23 17:44 self-signed.pem

          -rw-r--r--    1 something   something          454 Apr 23 17:44 standalone.properties

          -rw-r--r--    1 something   something          337 Apr 18 16:24 standalone.properties.orig

          -rw-r--r--    1 something   something          468 Apr 20 09:30 standalone.properties.sav


          (c) Chrome and IE 11 on Win10 is refusing to bring up the page. It only comes up under IE 11 on pre win10 pc's.

          Is my cert invalid somehow ?


          (d) the   cmd says it's selfsigned.   argh, how do I stop the self signing ?????


          depth=0 CN = ourservername.acme.com

          verify error:num=18:self signed certificate

          verify return:1

          depth=0 CN = ourservername.acme.com

          verify return:1


          Certificate chain

          0 s:/CN=ourservername.acme.com


          -----BEGIN CERTIFICATE-----




          -----END CERTIFICATE-----


          Server certificate




          No client certificate CA names sent

          Server Temp Key: ECDH, P-256, 256 bits


          SSL handshake has read 1588 bytes and written 439 bytes


          New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA

          Server public key is 3072 bit

          Secure Renegotiation IS supported

          Compression: NONE

          Expansion: NONE

          No ALPN negotiated


              Protocol  : TLSv1

              Cipher    : ECDHE-RSA-AES128-SHA

              Session-ID: 5AD....


              Master-Key: 11BD....

              Key-Arg   : None

              PSK identity: None

              PSK identity hint: None

              SRP username: None

              Start Time: 1524524998

              Timeout   : 300 (sec)

              Verify return code: 18 (self signed certificate)

          • 2. Re: ORDS standalone jetty stuck in self-signed mode (and not producing TLS 1.2)

            If you are running in standalone mode, Modify the standalone.properties file properties for ssl.cert and ssl.cert.key.  It must contain the path and the file name. 

            • 3. Re: ORDS standalone jetty stuck in self-signed mode (and not producing TLS 1.2)

              3310272, Thanks for replying. Appreciate it. Yes I have set those carefully and also saw them percolate back to the ords_param.properties. Also traced through a lot of that verbose logging from ords/jetty. Finally got a solution that worked on our server although it has a step I can't explain. I'm posting that now in case someone else hits the same combination.

              Thanks again.

              • 4. Re: ORDS standalone jetty stuck in self-signed mode (and not producing TLS 1.2)

                This took almost 3 weeks of my life but things seem to be working now. Wanted to mention what it was in case someone else runs into a similar scenario.

                To recap, my problem was 2fold: an ORDS/Jetty standalone on aix which kept negotiating back down to TLSv1 and self-signing certs with no 3 layer chain, just issued by and authorized by the server only. All of which meant the website would not come up on win10 under either Chrome 65 or IE 11 the way our company has them configured and locked down. Have been using the apex\apex_admin screen as the test page. This was Ora 12.2, ORDS 18.1, serverside JDK 1.8, Apex 5.1, and a new, current AIX LPAR.


                The solution for me was a combination of:


                (1) There appears to be an issue with the IBM version of the jsse2 layer for jetty and serverside JDK 1.8.

                A DrStephenH in https://www.ibm.com/developerworks/community/forums/html/topic?id=d34413d1-fc6d-4ea1-9e7b-4e331b591aa9&ps=10

                indicated a  "-Dcom.ibm.jsse2.overrideDefaultTLS=true"  switch to use on the java -jar cmdline. This was the magic which enabled TLSv1.2 to start showing up. The  final cmdline is:

                   java -Dcom.ibm.jsse2.overrideDefaultTLS=true -Dhttps.protocols=TLSv1.2  -jar ords.war standalone


                (2) When I downloaded the Oracle version of the unrestriced policy files for jdk 8 then ORDS immediately abended on our AIX. Our AIX support group then downloaded the same files from the IBM website and ORDS was ok. It's entirely possible I somehow got the wrong files although I tried to be very careful. This was for the US_export_policy.jar and local_policy.jar in the jre/lib/security folder. May not have been a factor. Just mentioning it.


                (3) For some reason (which I cannot explain) the ssl.cert value in the config/ords/standalone/standalone.properties does not seem to bind to a new .cer file except at install time. I originally had recvd an incomplete .cer file from our cert group and went thru the install steps. Once that became apparent I stopped ORDS, modified the standalone.properties file to point to the corrected file (and also explicitily specified the path in the params/ords_param.properties even though those are overwritten from the standalone.properties), removed the synthesized self-signed.cer.pem files, restarted ORDS, and it went back into self-signed mode. I went through numerous iterations like that with deliberately pointing to good certs and even bad certs and it always went to self-signed. However, when I do the un-install and even manually remove the various property and xml files at the unix level, and then do an "install advanced" and specify the same good cert path then it starts issuing the good cert and does NOT exhibit those config/ords/standalone/self-signed.cer and self-signed.pem files.


                Also, our cert file had to include all 3 levels in the order of server, intermediate, and lastly root.


                Of course during the "install advanced" it immediately starts up ORDS which did not have the -Dcom.ibm.jsse2.overrideDefaultTLS=true switch value but I just kill it and then explicitly restart it by hand with the switch value present.


                I kept thinking it was storing the cert somewhere (like an ords schema) but I could not find anything. Obviously something is missing in my understanding/implementation but so far this is the only recipe that seems to work for our AIX environment. And for now I'm just hugely relieved that it's working.