TLS fails - no cipher suites in common

When I enable TLS on the instant messaging server, I can't connect to it using TLS. I am using a self signed cert. Do I need to put the certificate authority in the JKS?
steve
Version
[15 Apr 2010 13:46:00,927] INFO xmppd [main] Starting XMPP Server: Version 8.0
Patch: 139893-02
iim.conf
! tls configuration
iim_server.sslkeystore=/etc/opt/SUNWiim/default/config/im.jks
iim_server.keystorepasswordfile=/etc/opt/SUNWiim/default/config/sslpassword.conf
iim_server.requiressl=false
iim_server.trust_all_cert=true
iim_server.certnickname=im.uwo.ca
# keytool -list -V -keystore im.jks
Enter keystore password: Mu51cdi3
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: im.uwo.ca
Creation date: Apr 15, 2010
Entry type: trustedCertEntry
Owner: [email protected], CN=im.uwo.ca, OU=ITS, O=The University of Western Ontario, L=London, ST=Ontario, C=CA
Issuer: [email protected], CN=UWO Certificate Authority, OU=Information Technology Services, O=The University of Western Ontario, L=London, ST=Ontario, C=CA
Serial number: 13a
Valid from: Thu Apr 15 09:05:42 EDT 2010 until: Fri Apr 15 09:05:42 EDT 2011
Certificate fingerprints:
MD5: FB:21:99:37:29:45:8C:B6:B1:55:0B:61:5B:93:28:FE
SHA1: 4D:3B:24:72:D5:CB:2D:AA:D7:7F:6B:E6:3B:F1:DB:31:5F:64:FB:6B
[15 Apr 2010 13:46:55,767] DEBUG xmppd [default-iim_server-worker 2] last read count 51
[15 Apr 2010 13:46:55,770] DEBUG xmppd.xfer [default-iim_server-worker 2] [null] Received:<starttls xmlns='urn:ietf:par
ams:xml:ns:xmpp-tls' xml:lang='en'/>
[15 Apr 2010 13:46:55,770] DEBUG xmppd [default-iim_server-worker 2] [ClientPacketDispatcher] StartTLS Packet detected
[15 Apr 2010 13:46:55,771] DEBUG xmppd [default-iim_server-worker 2] Session[null] Starting TLS nego : false, null
[15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] [SecureByteChannel] TLS started for channel id : 2
com.iplanet.im.server.io.MuxChannel@107108e
[15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] last read count 0
[15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] Session[null] processed input
[15 Apr 2010 13:46:55,776] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint finished process()
[15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint started process()
[15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint[null] processing input
[15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] last read count 0
[15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] Session[null] processed input
[15 Apr 2010 13:46:55,777] DEBUG xmppd [default-iim_server-worker 2] ConnectedStreamEndPoint finished process()
[15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint started process()
[15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint[null] processing input
[15 Apr 2010 13:46:55,782] DEBUG xmppd [default-iim_server-worker 0] last read count 90
[15 Apr 2010 13:46:55,783] DEBUG xmppd [default-iim_server-worker 0] Session[null] processed input
[15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint finished process()
[15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint started process()
[15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint[null] processing input
[15 Apr 2010 13:46:55,784] DEBUG xmppd [default-iim_server-worker 0] last read count 0
[15 Apr 2010 13:46:55,789] DEBUG xmppd [default-iim_server-worker 2] sslEngine closed
java.io.EOFException: sslEngine closed
at com.iplanet.im.common.ssl.SecureServerByteChannel.handleResult(SecureServerByteChannel.java:338)
at com.iplanet.im.common.ssl.SecureServerByteChannel.write(SecureServerByteChannel.java:244)
at com.iplanet.im.common.ssl.SecureServerByteChannel.handleHandshakeResult(SecureServerByteChannel.java:404)
at com.iplanet.im.common.ssl.SecureServerByteChannel.access$300(SecureServerByteChannel.java:27)
at com.iplanet.im.common.ssl.SecureServerByteChannel$2.run(SecureServerByteChannel.java:391)
at org.netbeans.lib.collab.util.Worker.run(Worker.java:244)
at java.lang.Thread.run(Thread.java:619)
[15 Apr 2010 13:46:55,792] DEBUG xmppd [default-iim_server-worker 2] [hsep]removing xmlns from packet ...
[15 Apr 2010 13:46:55,793] DEBUG xmppd [default-iim_server-worker 0] Sending CMD_CLOSE for channel: 2
[15 Apr 2010 13:46:55,793] INFO xmppd [default-iim_server-worker 0] MuxChannel.close() Server Closing client for chann
el : 2,null
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] outbound status changed from opened
to disconnected
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] inbound status changed from opened t
o disconnected
[15 Apr 2010 13:46:55,794] INFO xmppd [default-iim_server-worker 0] session.close() nullcloseStream false
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] [CSEP]null closeImpl
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] [CSEP] null closeSASLProvider
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] closed
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Removed connectionId : gz5im1.its.uwo.pri:7, this
: jid : nullcom.iplanet.im.server.ConnectedStreamEndPoint@1198ff2 , jid : null
[15 Apr 2010 13:46:55,794] DEBUG xmppd [default-iim_server-worker 0] Session[null] leaveAllGroupChats
[15 Apr 2010 13:46:55,795] DEBUG xmppd [default-iim_server-worker 0] RouterEndPoint[null [18452466]] removed all listen
ers. STAT:numEndPointListener=0
[15 Apr 2010 13:46:55,795] DEBUG xmppd [default-iim_server-worker 0] no cipher suites in common
org.jabberstudio.jso.StreamException: no cipher suites in common
at net.outer_planes.jso.AbstractStream.process(AbstractStream.java:1179)
at com.iplanet.im.server.ConnectedStreamEndPoint.process(ConnectedStreamEndPoint.java:356)
at com.iplanet.im.server.ConnectedStreamEndPoint.dataAvailable(ConnectedStreamEndPoint.java:312)
at com.iplanet.im.server.io.MuxChannel$MuxReadRunnable.run(MuxChannel.java:452)
at org.netbeans.lib.collab.util.Worker.run(Worker.java:244)
at java.lang.Thread.run(Thread.java:619)
[15 Apr 2010 13:46:55,797] DEBUG xmppd [default-iim_server-worker 0] ConnectedStreamEndPoint finished process()

[email protected] wrote:
When I enable TLS on the instant messaging server, I can't connect to it using TLS.What client are you using to connect to the IM Server and what platform is it running on?
I am using a self signed cert. Do I need to put the certificate authority in the JKS? Not as far as I can tell.
I used the self-signed cert from Messaging Server (./msgcert generate-certDB) and the steps provided at http://forums.sun.com/thread.jspa?messageID=10971294#10971294 and TLS worked fine with the same version as you are running.
I was testing with Pidgin 2.6.2 on Ubuntu 9.10.
Do you see:
[16 Apr 2010 16:13:03,421] INFO xmppd [main] SSL initialized - using JKSThe keytool output from my test system is below:
bash-3.00# keytool -list -V -keystore server-keystore.jks
Enter keystore password: password
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: server-cert
Creation date: 16/04/2010
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=mumble.aus.sun.com
Issuer: CN=mumble.aus.sun.com
Serial number: 90509a40
Valid from: Wed Mar 24 16:01:17 EST 2010 until: Thu Jun 24 15:01:17 EST 2010
Certificate fingerprints:
MD5: 8C:8D:67:03:2C:4C:64:B6:73:45:94:36:FA:D6:CE:4C
SHA1: B8:3E:F3:F0:D9:0C:B9:16:2F:82:3A:22:C6:1D:62:B3:90:18:02:34
*******************************************Regards,
Shane.

Similar Messages

No Cipher suites in common

Hello,
When I switch to using "setNeedClientAuth" to true on the end of the server the socket fails to connect. The error message that I get is "fatal handshake failure, no cipher suites in common". When I do not require client authentication, the program runs fine.
I created my own key using the RSA algorithem (as specified in other postings) using keytool. This does not help.
I've noticed that alot of the posts related to this don't seem to get answered.
If I cannot get client authentication to work correctly, then this security extension is worthless to me.
Dan Hughes

Hello, i saw you had the same problem that I'm having right now about the handshake exception "No Cipher suites in common".Could you fix this??
Thanks a lot.
This was your post:
When I switch to using "setNeedClientAuth" to true
e on the end of the server the socket fails to
connect. The error message that I get is "fatal
handshake failure, no cipher suites in common". When
I do not require client authentication, the program
runs fine.
I created my own key using the RSA algorithem (as
specified in other postings) using keytool. This does
not help.
I've noticed that alot of the posts related to this
don't seem to get answered.
If I cannot get client authentication to work
correctly, then this security extension is worthless
to me.

Handshake_failure (no cipher suites in common) error

Requirement
1. Login to a HTTPS site with the given site username and password through a proxy server (Proxy server doesn't require authentication)
2. Then upload a document in the site
Jars used
jsse.jar
Jcert.jar
Jnet.jar
Environment
Unix \ Weblogic
Code
import java.io.*;
import java.net.*;
import java.util.*;
import java.security.*;
import javax.net.ssl.*;
String loginURL = config.getProperty("LoginURL");
String putURL = config.getProperty("PutURL");
// This is where we have stored the certificate from the server using keytool
//keytool -import -alias ca -file xxx.cer -trustcacerts -v -keystore "cacerts"
//Stored the certificate by viewing the site throw the browser and save it locally
String certFile = config.getProperty("GetCertpath");
// Set proxy
System.setProperty("https.proxyHost", config.getProperty("Proxy"));
System.setProperty("https.proxyPort", config.getProperty("ProxyPort"));
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
// We are overriding the system default trust store
System.setProperty( "javax.net.ssl.trustStore", certFile);
URL dataURL = new URL(null, loginURL, new com.sun.net.ssl.internal.www.protocol.https.Handler());
com.sun.net.ssl.HttpsURLConnection connection = (com.sun.net.ssl.HttpsURLConnection) dataURL.openConnection();
connection.setHostnameVerifier(new HostnameVerifierImpl());
connection.setInstanceFollowRedirects(true); // Follow redirects by host
// Create login header
String hostlogin = config.getProperty("userID") + ":" + config.getProperty("password");
String encodedHostLogin = Base64Converter.encode(hostlogin.getBytes());
connection.setRequestProperty("Authorization", "Basic " + encodedHostLogin);
// Get the cookie. We'll need it to maintain the session
cookie = connection.getHeaderField("Set-Cookie");
// Read the host's reply, and dump
BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream())); //ERROR at this point
//System.out.print("## INFO: Host Replied...");
String line = null;
while((line = in.readLine()) != null)
//System.out.println(line);
in.close();
Error Dump
Exception occured Received fatal alert: handshake_failure (no cipher suites in common)
javax.net.ssl.SSLException: Received fatal alert: handshake_failure (no cipher suites in common)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
at java.io.OutputStream.write(OutputStream.java:56)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getInputStream([DashoPro-V1.2-120198])
Questions
1. The client (we\our application) does not have any certificates. We just have to login to the site with the id and password and upload a file. What extra we should do to avoid this error?

This is the full debug info
*** ClientHello, v3.1
RandomCookie: GMT: 1061973650 bytes = { 66, 125, 28, 182, 32, 174, 11, 166, 105, 30, 208, 142, 122, 250, 76, 48, 46, 41, 230, 73, 229, 20, 7, 5, 25, 218, 181, 43 }
Session ID: {}
Cipher Suites: { 0, 3, 0, 17 }
Compression Methods: { 0 }
[write] MD5 and SHA1 hashes: len = 47
0000: 01 00 00 2B 03 01 3F 4C 6F 92 42 7D 1C B6 20 AE ...+..?Lo.B... .
0010: 0B A6 69 1E D0 8E 7A FA 4C 30 2E 29 E6 49 E5 14 ..i...z.L0.).I..
0020: 07 05 19 DA B5 2B 00 00 04 00 03 00 11 01 00 .....+.........
main, WRITE: SSL v3.1 Handshake, length = 47
[write] MD5 and SHA1 hashes: len = 50
0000: 01 03 01 00 09 00 00 00 20 00 00 03 02 00 80 00 ........ .......
0010: 00 11 3F 4C 6F 92 42 7D 1C B6 20 AE 0B A6 69 1E ..?Lo.B... ...i.
0020: D0 8E 7A FA 4C 30 2E 29 E6 49 E5 14 07 05 19 DA ..z.L0.).I......
0030: B5 2B .+
main, WRITE: SSL v2, contentType = 22, translated length = 16337
main, READ: SSL v3.1 Alert, length = 2
main, RECV SSLv3 ALERT: fatal, handshake_failure
%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 1061973650 bytes = { 2, 6, 51, 93, 63, 135, 69, 177, 206, 97, 223, 48, 244, 40, 179, 108, 54, 67, 148, 76, 251, 197, 152, 112, 73, 142, 206, 13 }
Session ID: {}
Cipher Suites: { 0, 3, 0, 17 }
Compression Methods: { 0 }
[write] MD5 and SHA1 hashes: len = 47
0000: 01 00 00 2B 03 01 3F 4C 6F 92 02 06 33 5D 3F 87 ...+..?Lo...3]?.
0010: 45 B1 CE 61 DF 30 F4 28 B3 6C 36 43 94 4C FB C5 E..a.0.(.l6C.L..
0020: 98 70 49 8E CE 0D 00 00 04 00 03 00 11 01 00 .pI............
main, WRITE: SSL v3.1 Handshake, length = 47
[write] MD5 and SHA1 hashes: len = 50
0000: 01 03 01 00 09 00 00 00 20 00 00 03 02 00 80 00 ........ .......
0010: 00 11 3F 4C 6F 92 02 06 33 5D 3F 87 45 B1 CE 61 ..?Lo...3]?.E..a
0020: DF 30 F4 28 B3 6C 36 43 94 4C FB C5 98 70 49 8E .0.(.l6C.L...pI.
0030: CE 0D ..
main, WRITE: SSL v2, contentType = 22, translated length = 16337
main, READ: SSL v3.1 Alert, length = 2
main, RECV SSLv3 ALERT: fatal, handshake_failure
Exception in thread "main" javax.net.ssl.SSLException: Received fatal alert: handshake_failure (no cipher suites in common)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
at java.io.OutputStream.write(OutputStream.java:56)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getInputStream([DashoPro-V1.2-120198])
Apart from this,
1. When we run the same code in the Windows 2000 environment it works.
2. We want the code to run in the unix box.
3. We have also placed jsse.jar, jcert.jar and jnet.jar in the jre/lib/ext folder
4.Took the following existing file "cacerts" from jre/lib/security folder
5. Saved the certificate from the site through the browser as xxx.cer
6. Put both the files cacerts and xxx.cer in a directory
7. Added the xxx.cer to the cacerts using the following command
keytool -import -alias ca -file xxx.cer -trustcacerts -v -keystore "cacerts"
8. In the java code set the following property,
System.setProperty( "javax.net.ssl.trustStore", path to the cacerts file);

SSLHandshakeException: no Cipher suits in common

Hi
I have created a self signed certificate using keytool utility using RSA algorithm, key algorithm as SHA1WITHRSA. When I am trying to proxy the requests from IIS 7.5, I am getting below exception in weblogic logs.
Please let me know how do I go about debugging this.
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <DynamicJSSEListenThread[DefaultSecure] 33 cipher suites enabled:>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_RSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_RSA_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_DSS_WITH_AES_128_CBC_SHA256>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_RSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_RSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_RSA_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_DSS_WITH_AES_128_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_ECDSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_RSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <SSL_RSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_RSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_ECDSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_RSA_WITH_RC4_128_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <SSL_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <SSL_RSA_WITH_RC4_128_MD5>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_RSA_WITH_RC4_128_MD5>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <TLS_EMPTY_RENEGOTIATION_INFO_SCSV>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[DynamicJSSEListenThread[DefaultSecure],9,WebLogicServer]]weblogic.security.SSL.jsseadapter: SSLENGINE: SSLEngine.setWantClient
Auth(boolean): value=false.>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[DynamicJSSEListenThread[DefaultSecure],9,WebLogicServer]]weblogic.security.SSL.jsseadapter: SSLENGINE: SSLEngine.setUseClientM
ode(boolean): value=false.>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseada
pter: SSLENGINE: SSLEngine.unwrap(ByteBuffer,ByteBuffer[]) called: result=Status = OK HandshakeStatus = NEED_TASK
bytesConsumed = 52 bytesProduced = 0.>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseada
pter: SSLENGINE: Exception occurred during SSLEngine.wrap(ByteBuffer,ByteBuffer).
javax.net.ssl.SSLHandshakeException: no cipher suites in common
        at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1362)
        at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513)
        at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1197)
        at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1169)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
        at weblogic.security.SSL.jsseadapter.JaSSLEngine$1.run(JaSSLEngine.java:68)
        at weblogic.security.SSL.jsseadapter.JaSSLEngine.doAction(JaSSLEngine.java:732)
        at weblogic.security.SSL.jsseadapter.JaSSLEngine.wrap(JaSSLEngine.java:66)
        at weblogic.socket.JSSEFilterImpl.wrapAndWrite(JSSEFilterImpl.java:619)
        at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:91)
        at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:64)
        at weblogic.socket.JSSEFilterImpl.isMessageComplete(JSSEFilterImpl.java:282)
        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:962)
        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:889)
        at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:339)
        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: javax.net.ssl.SSLHandshakeException: no cipher suites in common
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1639)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:278)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:266)
        at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:892)
        at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:620)
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:167)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1299)
        at weblogic.socket.JSSEFilterImpl.doTasks(JSSEFilterImpl.java:186)
        at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:95)
        at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:64)
        at weblogic.socket.JSSEFilterImpl.isMessageComplete(JSSEFilterImpl.java:282)
        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:962)
        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:889)
        at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:339)
        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseada
pter: SSLENGINE: SSLEngine.closeOutbound(): value=closed.>
<26 Nov, 2014 7:29:42 PM IST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseada
pter: SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = CLOSED HandshakeStatus = NEED_UNWRAP
bytesConsumed = 0 bytesProduced = 7.>
Regards
PPK

Hi gimbal2,
I've already googled the error but I didn't find anything useful: however I will try again.
Thank you,
AndreaWeird, because the first result I got was a highly informative stackoverflow post. I think you need to blame more what you were looking for: you were looking for a cut, copy and paste solution in stead of searching for information to understand the problem and solve it. But that is conjecture on my part, feel free to ignore me.I read that stackoverflow post (about forcing the RSA algorithm instead of the default DSA) some days ago but didn't fully understant it; now I first generated a keystore with the RSA algorithm then I imported the certificate and now it almost works, I.E. now warns me about the certificate not being trusted while it should (I can see the issuer in the Trusted Root CA of the browser). To recap:
- in every browser at the customer sites there are two certificates installed (one intermediate and one wildcard)
- the customer can use a Web MS application and has imported a certificate in IIS, so I exported this certificate and imported it in the keystore but I get the error about the CA not being trusted.
So now it's not working and I will try to import the intermediate and the wildcard certificate (I think this could solve). I will post the result.
Thank you gimbal2.

SSL and TLS Cipher Suites

Hello,
I am tying to use the SSLContext class in a nonblocking IO application with "TLS" protocol in Server mode.
I am seeing a "no cipher suites in common" error message during the handshake.
The Client is requesting for "TLS_RSA_WITH_RC4_128_MD5" but this cipher is not available (verified from the list returned by SSLEngine.getSupportedCipherSuites()).
I have the following questions.
1> Are SSL_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_MD5 the same?
2>Is it possible for me to register TLS_RSA_WITH_RC4_128_MD5 as an alias for SSL_RSA_WITH_RC4_128_MD5?
3> How can I get the Server to recognize TLS_RSA_WITH_RC4_128_MD5?
Thanks,
arun.

Hello,
I am tying to use the SSLContext class in
a nonblocking IO application with "TLS" protocol in
Server mode.
I am seeing a "no cipher suites in common" error
message during the handshake.
The Client is requesting for
"TLS_RSA_WITH_RC4_128_MD5" but this cipher is not
available (verified from the list returned by
SSLEngine.getSupportedCipherSuites()).
I have the following questions.
1> Are SSL_RSA_WITH_RC4_128_MD5 and
TLS_RSA_WITH_RC4_128_MD5 the same?Yes
2>Is it possible for me to register
TLS_RSA_WITH_RC4_128_MD5 as an alias for
SSL_RSA_WITH_RC4_128_MD5?Shouldn't be necessary, as they are compared by RFC2246 value, not by name.
3> How can I get the Server to recognize
TLS_RSA_WITH_RC4_128_MD5?Do the client and server both create their SSLContexts with "TLS". Do either of them modify the enabled cipher suites? Does the server have an RSA certificate?

WSMAN CredSSP TLS 1.2 support and cipher suites

Hi all,
The protocol document [MS-CSSP] explains the first base64 encoded token send in the authenticate from the client to the server is a TLS Client Hello. The response is a ServerHello.
The diagram in section 4 'Protocol Examples' of the document indicates the ServerHello has a cipher suite of TLS_RSA_WITH_RC_128_SHA. The TLS version and cipher suites are not mentioned anywhere else in the document.
So lets take a look a network packet capture of a CredSSP authentication between a winrm.exe client and a Windows 2008 R2 server. I have base64 decoded the contents of the CredSSP Authorization headers,
The ClientHello bytes (without the extensions) send by my client are:
16 03 01 00 6B 01 00 00 67 03 01 54 DB 64 77 22
A2 1C A3 23 93 61 3B 00 1B DE 1C 6D 42 34 94 8D
1D 44 2C 64 8B 42 AC 41 B4 E2 DE 00 00 14 00 2F
00 35 00 0A C0 13 C0 14 C0 09 C0 0A 00 32 00 38
00 13 01 00 00 2A FF 01 00 01 00 00 00 00 11 00
0F 00 00 0C
Decoding this we can see that this is TLS 1.0 {03, 01}, taking a look at the ciphers we have:
TLS_RSA_WITH_AES_128_CBC_SHA 0x00 0x2F
TLS_RSA_WITH_AES_256_CBC_SHA 0x00 0x35
TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x00,0x0A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xC0,0x13
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC0,0x14
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xC0,0x09
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xC0,0x0A
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0x00,0x32
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0x00,0x38
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0x00,0x13
Now lets look at the ServerHello (without the extensions)
16 03 01 02 3C 02 00 00 4D 03 01 54 DB 64 78 73
92 C6 86 A3 F8 FF 3D D4 36 77 C0 FC 80 61 3F 4D
8C BC 60 CD BC 4D B1 1C 4A CF 0A 20 DA 14 00 00
38 11 DB C9 1C D0 8C 76 E7 A0 B9 F7 A5 D4 94 DF
8B 83 38 B3 FF EB AA 65 EB 23 03 0A 00 2F 00 00
05 FF 01 00 01 00 0B 00 01 E3 00 01 E0 00 01 DD
30 82 01 D9 30 82 01 42 A0 03 02 01 02 02 10 44
56 23 69 44 ED 93 85 43 DF B8 DF E3 75 DC A7 30
0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 2B
31 29 30 27 06 03 55 04 03 13 20
The server responds with TLS 1.0 and selected cipher (0x00 0x2F)
TLS_RSA_WITH_AES_128_CBC_SHA
Based on this I created a WSMan CredSSP client using Python and OpenSSL and configured it to use TLS 1.2. I found the Windows server always responded with TLS 1.0. So, I configured my OpenSSL client for TLS 1.0 and set the cipherlist to AES128-SHA (like winrs.exe).
The CredSSP TLS handshake completes, but the first ASN.1 encoded TSRequest token (containing an NTLM negotiate token) is rejected. However, if my openssl cipherlist is set to RC4, the TSRequest token is accepted and authentication is successful.
This raises several questions:
1. Despite sending a TLS 1.2 ClientHello the WSMan CredSSP Server always responded with TLS 1.0 ServerHello. A number of security experts consider this version effectivly broken. Does CredSSP support TLS 1.2?
2. I can authenticate with CredSSP using openssl 'RC4' cipher suites - but not with AES128-SHA suites. Are suites besides RC4 supported (winrs.exe appears to use AES).
Thanks
Ian

Forum Update:
I can now answer my 2nd question. The reason CredSSP is rejecting my TSRequest token when using AES128-SHA is because this ciphersuite is using CBC.
Some years ago OpenSSL added empty fragments to SSLv3 and TLS 1.0 packets to address a potential security vulnerability. These empty fragments are not compatible with Microsofts SChannel implementation so Windows is unable to decrypt the data. OpenSSL added
a compatibility flag SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS (0x00000800L) that must be set in the openssl client's context options to address this issue with Microsofts implementation. Once I set this option my python openssl client successfully authenticated
with a Windows 2012 R2 server using ECDHE-RSA-AES256-SHA - much better.
Question 1 is still unanswered. Is TLS 1.2 with CredSSP supported?

TLS cipher suites: Is there any Windows application that is using one of the two NULL cipher suites?

My question is about these two standard cipher suites from Windows 7/8 (and Windows Servers):
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
Question: Is there any native Windows 7 application/process that must use one of these two ciphers?
If not, I would simply kick them out to make sure that they are never used.
Bonus question: Is there any reason to keep these on any Windows Server?

Thank you for your response. I kicked out the NULL ciphers and everything weaker than 3DES. Consequently I also deactivated SSLv3 on five windows clients (computers and not servers, no server admin here). Rearranged the order of preference according to
my needs. So far I don't experience any issues. Did the same with JRE many years ago (just kicked it out), now I lean back and enjoy the show.

How Redirect browser(client) based on non-negotiable SSL/TLS protocol or cipher

Hi guys,
we have a security requirement wherein we have to force the browsers accessing our asp.net application hosted on windows server 2012 to have atleast tsl 1.1 , but we don't want to simply block the request, instead we would like to redirect the request
to a unsecured static html page with the instructions on how to get them onto tsl.
can any one help me here?>? actually i found a similar and exactly same thread on stackoverflow but i think that is probably directed towards linux family. http://serverfault.com/questions/591188/redirect-browser-based-on-non-negotiable-ssl-tls-protocol-or-cipher
please help me guys..
ps: i have posted the same question on IIS forum (http://forums.iis.net/t/1223352.aspx?How+Redirect+browser+client+based+on+non+negotiable+SSL+TLS+protocol+or+cipher+from+IIS)
and got a reply saying that it can be done at windows kernel level(possibly).

Hi,
As far as I know, once SSL handshake fails, no subsequent communication would occur between the server and client.
Therefore, as the way I see it, the goal cannot be achieved.
Best Regards,
Amy
Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]

Setting cipher suite name in Httprequest header

Is it possible to set the cipher suite name in http request header ?

The cipher suite has nothing to do with HTTP. Ciphersuites are only negotiated by the SSL/TLS peers.

Transport Layer Security Cipher Suites in Safari

Does anyone happen to know which Transport Layer Security (TLS) Cipher Suites Safari 4 supports?
Specifically, does it support the Elliptic Curve suites from RFC 4492? How about AES?
Thanks!

Hi,
i`m only aware that SSL is supported. If you need an official Statement i would recommend you open an OSS Message with the SAP Support.
Regards
-Seb.

Help enabling AES 256-bit cipher suites

I can't seem to create an SSLServerSocket with the 2 AES 256-bit cipher suites that are supposed to be available in JDK1.4.2. As you can see in the following code, the SSLServerSocket, ss, is enabled with the 2 AES_256 cipher suites. But, when ss.getEnabledCipherSuites() is invoked, those 2 suites aren't listed. What's up?
Also, what is this SSLv2Hello that I can't seem to get rid of?
    String[] PROTOCOLS = {"SSLv3", "TLSv1"};
    String[] CIPHER_SUITES = {"TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
                              "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
                              "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
                              "TLS_RSA_WITH_AES_256_CBC_SHA",
                              "TLS_RSA_WITH_AES_128_CBC_SHA",
                              "SSL_RSA_WITH_3DES_EDE_CBC_SHA"};// create an SSLServerSocket ss
        SSLContext context = SSLContext.getInstance("TLS", "SunJSSE");
        context.init(myKeyManagers, myTrustManagers, SecureRandom.getInstance("SHA1PRNG", "SUN"));
        SSLServerSocketFactory ssFactory = context.getServerSocketFactory();
        SSLServerSocket ss = ssFactory.createServerSocket();
        ss.setEnabledProtocols(PROTOCOLS);
        ss.setEnabledCipherSuites(CIPHER_SUITES);// output a bunch of useful debugging information
        System.out.println(System.getProperty("java.version") + "\n");
        Provider[] providers = Security.getProviders();
        for(int i=0; i < providers.length; ++i)
            System.out.println(providers[i] + "\n" + providers.getInfo() + "\n********************");
String[] enabledProtocols = ss.getEnabledProtocols();
for(int i=0; i < enabledProtocols.length; ++i)
System.out.println(enabledProtocols[i]);
String[] enabledCipherSuites = ss.getEnabledCipherSuites();
for(int i=0; i < enabledCipherSuites.length; ++i)
System.out.println(enabledCipherSuites[i]);
OUTPUT
1.4.2
SUN version 1.42
SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores)
SunJSSE version 1.42
Sun JSSE provider(implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
SunRsaSign version 1.42
SUN's provider for RSA signatures
SunJCE version 1.42
SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)
SunJGSS version 1.0
Sun (Kerberos v5)
SSLv2Hello
SSLv3
TLSv1
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Now I get an Exception when I run the same program.
OUTPUT
1.4.2
SUN version 1.42
SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores)
SunJSSE version 1.42
Sun JSSE provider(implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
SunRsaSign version 1.42
SUN's provider for RSA signatures
SunJCE version 1.42
SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)
SunJGSS version 1.0
Sun (Kerberos v5)
java.lang.IllegalArgumentException: Cannot support TLS_DHE_RSA_WITH_AES_256_CBC_SHA with currently installed providers
        at com.sun.net.ssl.internal.ssl.CipherSuiteList.<init>(DashoA6275)
        at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.setEnabledCipherSuites(DashoA6275)
        at test.util.ConcreteSSLServerSocketFactory.initSocket(ConcreteSSLServerSocketFactory.java:111)
        at test.util.ConcreteSSLServerSocketFactory.createServerSocket(ConcreteSSLServerSocketFactory.java:100)
        at test.Test.main(Test.java:111)
Exception in thread "main"

Schannel cipher suites and ChaCha20

Is there a blog or other communications channel devoted to the PKI internals of Windows? Most security researchers focus on Linux web servers/OpenSSL, but there are folks in the Windows world who really care about this stuff too, and we'd like to hear
about what the Windows PKI developers are working on and planning, and perhaps interact with comments and suggestions.
Because I couldn't find any discussion about Schannel development, I started a
feature suggestion on the Windows User Voice site for Microsoft to add ChaCha20-Poly1305 cipher suites to Schannel, mostly for the benefit of mobile visitors to IIS websites, but also to help Windows phones and tablets that don't have integrated CPU extensions
for GCM encryption (improved speed and reduced power consumption).
It's frustrating to be a security-focused IIS website administrator. Schannel is a "black box" that we can't tinker with or extend ourselves, and support for modern ciphers has been lagging behind other website and client software (it looks like we'll
at least finally get strong and forward secret ECDHE_RSA + AES + GCM suites with Windows 10 and Server vNext/2016). The methods for configuring cipher suite orders and TLS versions could really use a rethink too (thank goodness for IISCrypto).

Hi Jamie_E,
May the following article can help you,
Cipher Suites in Schannel
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx
Managing SSL for a Client Access Server
http://technet.microsoft.com/en-us/library/bb310795.aspx
Configuring Secure Sockets Layer in IIS 7
http://technet.microsoft.com/en-us/library/cc771438(WS.10).aspx
How to enable Schannel event logging in IIS
https://vkbexternal.partners.extranet.microsoft.com/VKBWeb/?portalId=1#
How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
http://support.microsoft.com/kb/245030/EN-US
I’m glad to be of help to you!
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

How to add a Cipher Suite using RSA 1024 algorithm to the 'SSL Cipher Suite Order' GPO

Following a VA test the Default Domain GPO has been set to enable the SSL Cipher Suite Order. Following the change Symantec Endpoint Protection Manager doesn't work properly as the the Home, Monitors and Reports pages are blank and an Schannel error is
logged in the SEPM server's event log.
I have spoken to Symantec and I have been told that we need to allow the RSA 1024 bit algorithm but they can't tell me which cipher suite this would be. I have looked in the GPO setting and can't see an RSA 1024 suite but have found some in this article:
http://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01
I want to know how to add an additional cipher suite into the setting safely. Am I able to just add the suite into the GPO setting (eg TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA) or do I need to do anything else beforehand?
If anyone has any advice regarding this or cipher suite orders and troubleshooting SSL problems it would be much appreciated,
Thanks
Chris

Hi Chris,
Based on my research, RSA_EXPORT1024_DES_CBC_SHA is a previous cipher suite, which is supported, you can enable it use
SSL Cipher Suite Order policy setting under Administrative Templates\Network\SSL Configuration Settings.
More information for you:
TLS/SSL Cryptographic Enhancements
http://technet.microsoft.com/en-us/library/cc766285(v=WS.10).aspx
Best Regards,
Amy

Add-On connection for Journal Entry - Failed to Connect to SBO Common

We have a customer (SAPBO 2005A SP01 PL29) with some specific requirements that required an add-on running in the background to monitor the addition of Goods Receipt PO's to the system. When the GRPO is successfully added, the Add-On will (behind the scenes) create an appropriate Journal Entry through the SAP DI. One of the issues that we encountered during the development of this functionality was that when it was tested by users, they weren't authorized to access the Financials module or the Journal Entry screen. What we ended up doing was creating a secondary connection (vCompany) in the DL pulling the information from the encrypted user information from SAP the Add-On used to connect, but utilizing a management level user ID and password. Once that connection has been made, the Journal Entry is added through the DI and that secondary connection is disconnected.
The problem that we're encountering is this. When the users are logged into SAP Client with an regular user, and the GRPO adds, the secondary connection fails and returns a message of "Failed to Connect to SBO-Common". However, if the user is logged into SAP as an adminitrative level user and the GRPO is added, the secondary connection is successful and the Journal Entry is created. The secondary connection is strictly used for the JE. Here's the code (VS.Net 2005) for the secondary connection:
vCompany = New SAPbobsCOM.Company
vCompany.UseTrusted = True
vCompany.language = SAPbobsCOM.BoSuppLangs.ln_English
vCompany.CompanyDB = oCompany.CompanyDB
vCompany.UserName = "XXXXX"
vCompany.Password = "YYYYY"
vCompany.Server = oCompany.Server
vCompany.DbServerType = SAPbobsCOM.BoDataServerTypes.dst_MSSQL2005
lRetConnect = vCompany.Connect()
Where "XXXXX" would be the appropriate management level SAP User Name and "YYYYY" would be that users password.
Has anyone else had this kind of issue where you needed a secondary connection with management level access behind the scenes to accomplish something in SAP and had problems getting it to connect? Any thoughts or ideas would be greatly appreciated.

Hi Dennis,
what you can try is to make a untrusted connection
oCompany.UseTrusted = False
and set the DBUser and Pwd
oCompany.DbUserName = "sa"
oCompany.DbPassword = "insertpwd"
lg David

How can I control the list of cipher suites offered in the SSL Client Hello message? I want to forbid MD5 and RC4.

How can I control the list of cipher suites offered in the SSL Client Hello message?
I want to limit my browser to negotiating strong cipher suites. I'd like to forbid DES, MD5 and RC4.

Set the related SSL3 prefs to false on the about:config page (Filter: security.ssl3.).
*http://kb.mozillazine.org/about:config

TLS fails - no cipher suites in common

Similar Messages

Maybe you are looking for