SSL cipher suites with v3

Any way to adjust which SSL cipher suites are used with the messaging agent on version 3 of messenger? There are a few that are not compatible with our firewall and we need to disable them. It's keeping iOS clients from connecting.

Palo Alto Networks firewall. We enforce SSL decryption on all traffic and any suite that uses Diffie-Hellman key exchange isn't supported. Has to be RSA key exchange.
Originally Posted by ahidalgo
Which SSL cipher suites are not compatible with your firewall, just curious. Whose firewall are you using?
Al
On 2/27/2015 at 9:26 PM, jarrodholder<[email protected]> wrote:
Any way to adjust which SSL cipher suites are used with the messaging
agent on version 3 of messenger? There are a few that are not
compatible with our firewall and we need to disable them. It's keeping
iOS clients from connecting.
jarrodholder
jarrodholder's Profile: https://forums.novell.com/member.php?userid=1616
View this thread: https://forums.novell.com/showthread.php?t=482111

Similar Messages

Why in Firefox there are no cipher suits with SHA-256?

I don't see cipher suits with SHA-256 in Firefox ClientHello. Why? They are not supported?

I think that it is best to keep the discussion in one thread, so I locking the other two that you created.
Please continue here: [[/questions/976999]]

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

How to locate and configure SSL cipher suites

hi all,
i wanted to knw how Ciphersuites that are used in SSL Connections are picked up by the JVM or whoever is responsible for establishing the connection at lower level. I mean there are methods in SSLSocketFactory, HttpsURLConnection named getEnabledCipherSuites(). I was just wondering where these default cipher suites are picked up. Is there any configuration file or some setting where we can add our own cipher suite to the list?
Please advice.
Thanks in advance :)
Arun

hi,
As already we have discussed this, we can set the ciphersuite used in the SSLConnection using SSLSocket.setEnabledCIpherSuite() function only. And getSupportedCipherSuites() function returns the list of cipher suites that are supported by the connection.
But i want to set ciphersuite in SSLConnection using HttpsURLConnection. Under this class (HttpsURLConnection) there is no such method where u can specify the ciphersuite.
So i am trying to find out when an SSL connection is setup from where does the JVM loads the cipher suites? I checked the All the basic classes in javax.net.ssl package and all contain the methods as abstract. So if anybody has any idea regarding where these supported cipher suites are located in jdk please let me knw.
Thanks in advance :)
Arun

No available certificate or key corresponds to the SSL cipher suites which

Hi,
I have only recently started with SSL. So far I have managed to secure a Tomcat Server on my local area network with SSL. However when using the same keystore to start an Apache Derby Network Server with SSL I am getting the above mentioned error. Attached is the outpout a keytool -v -list provides for the keystore I am using. Can someone help in identifying what the problem is please? What I find confusing is that the same keystore works in conjunction with Tomcat while it does not in conjunction with Derby. Thanks
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: thmb
Creation date: Dec 11, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: EMAILADDRESS=x <at> t-online.de, CN=THMB, OU=IT, O=x, L=x, ST=x, C=DE
Issuer: EMAILADDRESS=x <at> t-online.de, CN=THMB CA, OU=IT, O=x, L=x, ST=x, C=DE
Serial number: 1
Valid from: Sat Dec 11 12:50:08 CET 2010 until: Sun Dec 11 12:50:08 CET 2011
Certificate fingerprints:
     MD5: A8:27:6E:B4:81:E0:6B:23:B4:A7:4C:13:4B:16:80:EC
     SHA1: B9:9F:2B:CA:03:40:00:A0:4B:03:A0:CD:E7:E7:8F:61:9D:B9:26:42
     Signature algorithm name: SHA1withRSA
     Version: 3
Certificate[2]:
Owner: EMAILADDRESS=x <at> t-online.de, CN=THMB CA, OU=IT, O=x, L=x, ST=x, C=DE
Issuer: EMAILADDRESS=x <at> t-online.de, CN=THMB CA, OU=IT, O=x, L=x, ST=x, C=DE
Serial number: 95e743a14724966f
Valid from: Sat Dec 11 12:44:17 CET 2010 until: Tue Dec 08 12:44:17 CET 2020
Certificate fingerprints:
     MD5: 8D:D4:44:B6:37:EC:51:CD:25:85:E8:F1:0A:A9:30:2D
     SHA1: E7:04:DB:FC:DA:16:FE:46:88:56:C5:0B:65:D5:0F:DF:AC:0E:A1:D7
     Signature algorithm name: SHA1withRSA
     Version: 3
Edited by: user13506192 on 22.12.2010 00:08
I have now tried to run the Derby Server on Windows with this keystore. On this platform I am getting the following exception:
java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: com.sun.net.internal.ssl.DefaultSSLContextImpl)
Can someone please help? Should more information be required to analyse what is causing this, please let me know.
Thanks a lot in advance.
Regards
Thomas

Not sure what imports are used in the programs as both the server and the client program are standard software, i.e. the Apache Derby Network Server and the IJ SQL command line client that comes with it.
I request/enforce SSL use by supplying command line parameters at server (/ client) start up, i.e.
java -jar -Djavax.net.ssl.keyStore=myServerKeyStore.jks -Djavax.net.ssl.keyStorePassword=xxx -Djavax.net.ssl.trustStore=myServerTrustStore.jks -Djavax.net.ssl.trustStorePassword=xxx derbyrun.jar server start -ssl paarAuthentication
java -jar -Djavax.net.ssl.keyStore=myClientKeyStore.jks -Djavax.net.ssl.keyStorePassword=xxx -Djavax.net.ssl.trustStore=myClientTrustStore.jks -Djavax.net.ssl.trustStorePassword=xxx derbyrun.jar ij
After having recreated my certificates and keystores the exception which originally lead to this post are no longer given and the server and the client program can now properly be started. So not sure what the problem was, but may be no need to further investigate as the scenario now works.
Thanks & Regards
Thomas

SSL Medium Strength Cipher Suites Supported vulnerability

Kind of an odd thing. We just had a vulnerability scan and a 2960 got pinged for supporting medium strength SSL cipher suites. I say strange cause I have 3 others that have the same IOS image and they didn't get pinged. Swap out the management IP address and they are all the same. They are all running 12.2(52)SE C2960-LANBASEK9-M, with a 768 bit keys. Here is the text of the vulnerability :
Synopsis : The remote service supports the use of medium strength SSL ciphers. Description : The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits.
Reconfigure the affected application if possible to avoid use of medium strength ciphers. / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here are the medium strength SSL ciphers supported by the remote server : Medium Strength Ciphers (>= 56-bit and < 112-bit key) SSLv3 EDH-RSA-DES-CBC-SHA Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 TLSv1 EDH-RSA-DES-CBC-SHA Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag}
Can someone point me in the right direction on how to re-configure the switch to pass this test?
Thanks
Poirot

I believe the alert there is because you are using a 768 key which was broken recently (Jan 2010 a paper was published on it with results from efforts that took 4 years to break 768 keys). 768bit RSA keys is not considered secure enough any more.
I would suggest you to configure keys of 1024 on these switches and try again.
I hope it helps.
PK

Supported Cipher suites.

Hi All,
I am successfully communicating with the server using HTTPS with HttpsConnection from my J2ME Midlet. I am using APACHE as HTTP Server. However, the best cipher suite negutiated between the device and the server used by HTTPS was DES-CBC3-SHA. As you can see, it uses DES, which is not quite as secure as AES.However despite a lot of effort, i am just not able to get it to use an AES cipher suite. Is AES part of any supported cipher suite by MIDP? If not, can anyone tell me how i can enumeration the cipher suites supported on the MIDLet?
Thanks in advance
Edited by: AUTOMATON on Sep 14, 2007 3:38 AM

@superena,
Thanks for the links, but they actually dont give me the info I need. What I want to do is to find out how many SSL cipher suites are supported by J2ME. I mean if there is a list somewhere, of if i can write a program that can enumerate them for me..

Cisco Prime Infrastucture vulnerability SSL RC4 Cipher Suites Supported

Hi All,
I have a question on how to disable RC4 Cipher Suites Supported on Cisco Prime Infrastructure Platform.
My Client have use Nessus Software to scan on prime. and found on below vulnerability
SSL RC4 Cipher Suites Supported
Cisco prime infrastructure deploy on latest 2.1
we have gain the root access and modifier the ssl.conf and restart the service also unable to solve.
/opt/CSCOlumos/httpd/ssl/backup/ssl.conf
/opt/CSCOlumos/httpd/ssl/ssl.conf
C:\Program Files\Tenable\Nessus>nessuscmd -v -p 443 -i 21643 192.168.1.55
Starting nessuscmd 5.2.7
Scanning '192.168.1.55'...
Host 192.168.1.55 is up
Discovered open port https (443/tcp) on 192.168.1.55
[i] Plugin 21643 reported a result on port https (443/tcp) of 192.168.1.55
+ Results found on 192.168.1.55 :
   - Port https (443/tcp) is open
     [i] Plugin ID 21643
      | Here is the list of SSL ciphers supported by the remote server :
      | Each group is reported per SSL Version.
      | SSL Version : TLSv1
      |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
      |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
      | C(56)          Mac=SHA1
      |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
      | 8)             Mac=MD5
      |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
      | 8)             Mac=SHA1
      |
      | SSL Version : SSLv3
      |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
      |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
      | C(56)          Mac=SHA1
      |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
      | C(56)          Mac=SHA1
      |   High Strength Ciphers (>= 112-bit key)
      |       EDH-RSA-DES-CBC3-SHA         Kx=DH          Au=RSA      Enc=3DES(
      | 68)            Mac=SHA1
      |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
      | 8)             Mac=MD5
      |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
      | 8)             Mac=SHA1
      | The fields above are :

Hi ,
"SSL RC4 Cipher Suites Supported" has been documented in bug CSCum03709.
CSCum03709    PI 2.0.0.0.294 with SSH vulnerabilities
Presently, there is no workaround for this vulnerability, however, the fix will be implemented in
Prime Infrastructure 2.2.which is planned to be released around the end of this year ( tentative)
Thanks-
Afroz
***Ratings Encourages Contributors ***

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

Setting cipher suites for ssl sockets

Hi
While setting cipher suites for ssl serversocket and socket, there may be lot of stream ciphers and block ciphers in the list. (also there may or may not be anonymous cipher suites).
How does the ssl socket decide which cipher suite to use?
Sorry for this newbie question.
Thank you.

Have you read the JSSE Reference Guide? It has a really good description of how the SSL handshake works. Part of the "Client Hello" step includes sending all the cipher-suites the client has enabled. The server picks the "best" of that set, that the server also supports, and sends it back as part of the "Server Hello". Both sides switch to that set.
Now, what "best" means isn't defined. I'm not sure what criteria the server uses to determine that. Maybe someone else reading the thread can chime in.
Grant

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?

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.

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);

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.

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.

SSL cipher suites with v3

Similar Messages

Maybe you are looking for