I am using Twilio sandbox environment for testing WhatsApp integration with my application. As I moved application to different server twilio API is sending Error 20426 Upgrade Required.
Application was working fine on previous server. TLS version on both the server is 1.2 and SSL version is 3. Cipher Suits are also present on both servers as List provided in Twilio document. The only difference between two servers is the OS. On server where application is working OS installed is Linux and where application is not working OS is AIX 7.
Related
We are trying to validate what TLS version our web client application is using. We can run nmap --script ssl-enum-ciphers -p 443 www.example.com as we see TLS version 1.2 (That's the version we want.) However we are wanting to validate what version of TLS is being used from web application client directly? Not the server. This is a 1.6 java application that is deployed on Weblogic. Is this request possible to validate on the application directly? I see a lot of threads validating at the server level or the or validating what the server end, not the client application level.
I have a client application communicating with external party application. The client application is up and running for long time.
Recently, I received a request from the third party asking about the allowed SSL/TLS protocols from the application server where my client application is running and calling their application.
Questions
How to tell what SSL/TLS protocols allowed from my client application ?
What has been done so far
1 - I checked SSL configration at the server's browser where my client application is running, See below screen shot. Is this what the third party team trying to know?
2 - The client application is running from weblogic 10.3.6. I cheked weblogic configuration in the following but I could not find any thing about the SSL/TLS protoclos used:
2.1 - Summary of Servers >Server_1 >Protocols
2.2 - Summary of Servers >Server_1 >Configuration >SSL
------ Update ------
I am using Java 7 for the client application. For that I checked the Java™ Secure Socket Extension (JSSE) documentation online. In the online documentation I found the following
Engine Class Implemented : SSLContext
Algorithm or Protocol: SSLv3 (a.k.a. SSL), TLSv1 (a.k.a. TLS), TLSv1.1, TLSv1.2
See documentation Java Cryptography Architecture Oracle Providers Documentation for Java Platform Standard Edition 7, The SunJSSE Provider for more information.
So is this the allowed SSL/TLS protocols from my client application? Further if Java has its own allowed Protocols, then how is that related to protocols setting in the browser ( Point 1 above )?
See http://docs.oracle.com/cd/E24329_01/web.1211/e24422/ssl.htm#SECMG634 (there are similar settings for 11G)
The browser settings are a red herring - the third-party app will connect to weblogic, not your browser, and negotiate a secure protocol based on what WLS + the third party app can mutually support.
Java7's default settings are acceptable, although if you need PCI-DSS compliance, you should probably set TLS1.1 as the minimum.
I use a mock SMTP server (MockSmtp or fakeSMTP) on my Mac for debugging and testing mail delivery during development. These mock SMTP servers simply display the mails which are to be sent instead of delivering them.
Since upgrading to Yosemite, though, sending mails to this local SMTP server via JavaMail (tested on Glassfish V3 and JBoss AS 7) is painfully slow. A single mail takes about 20s to send. Sending a mail via netcat does not have any delay so the problem should not be caused by the SMTP server. I had no such problems with Mavericks. Mails sent on the production systems (Debian stable) are delivered quickly, too.
I am currently running JAVA JDK v1.7.0_71, the JavaMail implementation and the mail session is provided by JBoss AS 7.4 and mails are sent using Seam Mail (Seam v2.3, latest nightly build). Using seams own JavaMail implementation and mail session does not change anything. Disabling the firewall (Little Snitch) also does not help.
What has changed from Mavericks to Yosemite which could cause these issues?
Doing sudo scutil --set HostName macbook-my-name worked for me too! email send went from 9 seconds to .09s. Thank you Roben!
I am currently implementing a single signon solution for a customer that is based on Java, Tomcat and Kerberos.
Users are to access the URL of an intranet Tomcat application from their client browsers, the Tomcat application acquires the users' credentials via Kerberos and redirects them to the actual web application.
Our customer's environment is a typical mixture of a Windows AD server acting as the KDC and Linux Tomcat application servers. The SSO functionality is supposed to be used from both Windows and Linux clients. This is what appears to be different from most answers I can find on the net where people have Linux web application servers but only use Windows clients.
Now, in my local setup I get some strange behaviour. My development environment is a Tomcat 7.0.26 running from MyEclipse 8.6 under Windows 7. My test environment is a Tomcat 7.0.26 or 7.0.53 behind an Apache web server on a Centos 6 machine. I have set up the AD server correctly, generated the necessary keytab files etc. and everything is running smoothly in the development environment. I can access the Tomcat application from both Linux and Windows clients using IE and Firefox, Kerberos authentication proceeds and I get redirected properly.
When deploying the Tomcat application on the test server this keeps working when trying to sign on from Windows clients. However, when I try to access the test server from a Linux client (I have tried from Linux Mint 13 and Ubuntu 13.10), I get the following error:
javax.servlet.ServletException: GSSException: No credential found for: 1.3.6.1.5.2.51.3.6.1.5.2.5 usage: Accept
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:233)
I have to admit that I do not properly understand this message. Does it point to a problem with the credentials supplied by the client or a problem with the application server negotiating with the KDC? I have done some research on this problem and have found out that the indicated oid 1.3.6.1.5.2.5 stands for GSS_IAKERB_MECHANISM and not GSS_KRB5_MECHANISM or GSS_SPNEGO_MECHANISM which I find strange. Also, nobody else appears to have exactly the same problem.
I have tried switching from MIT Kerberos to Heimdal Kerberos and back. I have tried Firefox and Chromium, on the application server I have switched between Tomcat 7.0.26 and 7.0.53, the problem still persists. I am using the latest spnego.jar.
Now: Calls from Linux to the Tomcat running on the Windows development machine succeed and calls from Linux clients to the Linux application server fail with the same error message for both browsers tried.
Any ideas on this one?
GSS_IAKERB_MECHANISM means that the client is not able to determine the realm/kdc to create a service ticket and asks the server to serve as an intermediate to the target KDC. Check Wireshark traffic. Your task now is to analyze why the client is not able to create a service ticket for that SPN. I have observed this issue on Heimdal on FreeBSD with Microsoft KDC.
So the problem ist not your Tomcat instance.
We are calling a web service (jaxws) running on JBoss 4 from one of our .NET, C#, web services clients. It is working just fine on our local network, but as soon as we connect to our VPN to test on the production environment it throws a 505 error (HTTP version not supported). On both our local and production machines, we have tested the services from a Java client while still connecting to VPN and it's working fine for the java client
Any hint regarding this issue?
I would guess that your production web server is not configured the same as your test web server; it is more restrictive and not allowing the HTTP version that you want. Ask the server admin for your production server what versions of HTTP are supported.
Another possibility is that on the VPN you have an intermediate proxy that is converting your request from one version of HTTP to another. Ask a network admin for help.