Re: AW: Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 5/31/19 18:41, James H. H. Lampert wrote: > On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote: >> You can run a small java program on your jvm to print out the >> supported And default protocols. Yet, I didn’t find a better >> way. >> >> e.g. ==> >> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679 609085.html >> > >> > If I set the same JAVA_HOME as Tomcat was launched under, and > compile and run "Ciphers.java" from the above site, on the customer > box, I get: > >> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 >> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 >> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA >> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 >> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 >> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA256 >> SSL_DH_anon_WITH_AES_128_GCM_SHA256 >> SSL_DH_anon_WITH_AES_256_CBC_SHA >> SSL_DH_anon_WITH_AES_256_CBC_SHA256 >> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA >> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * >> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA * >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDHE_ECDSA_WITH_NULL_SHA * >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDHE_RSA_WITH_NULL_SHA * >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA * >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA * >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDH_ECDSA_WITH_NULL_SHA * >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA * >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA * >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA >> SSL_ECDH_anon_WITH_AES_128_CBC_SHA >> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5 >> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >> SSL_RSA_FIPS_WITH_DES_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_RSA_WITH_AES_256_CBC_SHA * >> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384 >> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 >> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 * >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV Other than the fact that none of those start with TLS_ like all modern cipher suites do, the above looks okay. > FOR COMPARISON PURPOSES, what we get on our box is: >> Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >> SSL_DHE_DSS_WITH_DES_CBC_SHA * >> SSL_DHE_DSS_WITH_RC4_128_SHA * >> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_DHE_RSA_WITH_DES_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA >> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA >> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA >> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA >> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA >> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA >> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA * >> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * >> SSL_RSA_EXPORT_WITH_RC4_40_MD5 * >> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA * >> SSL_RSA_FIPS_WITH_DES_CBC_SHA * >> SSL_RSA_WITH_3DES_EDE_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA * >> SSL_RSA_WITH_AES_256_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA >> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA * >> SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA Almost all of the above cipher suites are useless. Anything starting with SSL_*_DSS
Re: AW: Outbound SSL?
On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote: You can run a small java program on your jvm to print out the supported And default protocols. Yet, I didn’t find a better way. e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html If I set the same JAVA_HOME as Tomcat was launched under, and compile and run "Ciphers.java" from the above site, on the customer box, I get: > Default Cipher > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 > SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 > SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 > SSL_DHE_DSS_WITH_DES_CBC_SHA > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 > SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 > SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 > SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA256 > SSL_DH_anon_WITH_AES_128_GCM_SHA256 > SSL_DH_anon_WITH_AES_256_CBC_SHA > SSL_DH_anon_WITH_AES_256_CBC_SHA256 > SSL_DH_anon_WITH_AES_256_GCM_SHA384 > SSL_DH_anon_WITH_DES_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > SSL_ECDHE_ECDSA_WITH_NULL_SHA > * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA > * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA > * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > SSL_ECDHE_RSA_WITH_NULL_SHA > * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA > * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 > SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA > * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 > SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 > SSL_ECDH_ECDSA_WITH_NULL_SHA > * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA > * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 > SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA > * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 > SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 > SSL_ECDH_RSA_WITH_NULL_SHA > SSL_ECDH_anon_WITH_AES_128_CBC_SHA > SSL_ECDH_anon_WITH_AES_256_CBC_SHA > SSL_ECDH_anon_WITH_NULL_SHA > SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA > SSL_KRB5_WITH_DES_CBC_MD5 > SSL_KRB5_WITH_DES_CBC_SHA > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_RSA_FIPS_WITH_DES_CBC_SHA > * SSL_RSA_WITH_AES_128_CBC_SHA > * SSL_RSA_WITH_AES_128_CBC_SHA256 > SSL_RSA_WITH_AES_128_GCM_SHA256 > * SSL_RSA_WITH_AES_256_CBC_SHA > * SSL_RSA_WITH_AES_256_CBC_SHA256 > SSL_RSA_WITH_AES_256_GCM_SHA384 > SSL_RSA_WITH_DES_CBC_SHA > SSL_RSA_WITH_NULL_MD5 > SSL_RSA_WITH_NULL_SHA > SSL_RSA_WITH_NULL_SHA256 > * TLS_EMPTY_RENEGOTIATION_INFO_SCSV FOR COMPARISON PURPOSES, what we get on our box is: > Default Cipher > * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA > * SSL_DHE_DSS_WITH_DES_CBC_SHA > * SSL_DHE_DSS_WITH_RC4_128_SHA > * SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA > * SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA > SSL_DH_anon_WITH_AES_256_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_RC4_128_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA > SSL_KRB5_EXPORT_WITH_RC4_40_MD5 > SSL_KRB5_EXPORT_WITH_RC4_40_SHA > SSL_KRB5_WITH_3DES_EDE_CBC_MD5 > SSL_KRB5_WITH_3DES_EDE_CBC_SHA > SSL_KRB5_WITH_DES_CBC_MD5 > SSL_KRB5_WITH_DES_CBC_SHA > SSL_KRB5_WITH_RC4_128_MD5 > SSL_KRB5_WITH_RC4_128_SHA > * SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > * SSL_RSA_EXPORT_WITH_RC4_40_MD5 > * SSL_RSA_FI
Re: AW: Outbound SSL?
This just keeps getting weirder and weirder. I extracted the actual request > https://maps.googleapis.com/maps/api/geocode/json?key=&address= from where it had been logged to catalina.out, and built a simple program to feed it to Scott Klement's HTTPAPI, an open-source HTTP interface for OS/400-native programs. It has a rather rich debugging capability. Once I got it working on our box, I sent it over to the "problem" box. And it worked perfectly: it got what appears to be the expected response. Of course, it's doing all of this natively, rather than through Java. We also know that Tomcat is running under a 64-bit Java 7 JVM on that box. And we also know that we've got this product running in Java 6, 7, and 8, on IBM Midrange boxes, WinDoze boxes, and Linux boxes, without the problem occurring. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 5/31/19 13:50, André Warnier (tomcat) wrote: > On 31.05.2019 18:12, James H. H. Lampert wrote: >> Thanks. >> >> We think that the customer has solved the cipher problem, >> because, at least as of when I checked on Wednesday, that error >> message was no longer appearing. >> >> Yet they're still not connecting. I can *ping* >> maps.googleapis.com from their box, with no trouble whatsoever, > > That is perhaps because "ping" does not use TCP/IP, it uses > another protocol called ICMP, which is (a) connection-less and (b) > not usually blocked by firewalls. At least, this shows that the DNS > part is working correctly, and that the customer's host has a > "route" to that server. But for example, if the server (or a > firewall) blocked connections to the port which the webapp is > trying to reach, you would still get the problem below. (Or if the > server simply is not listening on that port). +1 James, what if you: $ openssl s_client -connect maps.googleapis.com:443 Do you get a connection? If so, there is some other issue with the software and we'll have to dig-in. If that does NOT connect, then it is probably a network / firewall problem. That's the same IPv6 address that I get when I do "host maps.googleapis.com" so at least you aren't having DNS intercepted or something like that. You may also need to go through an HTTP proxy to get to the outside. You might want to ask the client is they require an HTTP proxy. Hmm. Intermittent connection failures, sometimes with cipher-suite mismatches and other weird things? Maybe they are one of those companies who MitM everything and their MitM box is badly configured... or they are playing with it. I'm putting the certificate actually presented by maps.googleapis.com to a clean source below. If you can connect with "openssl s_client" then check to see that they are the same. If the company is MitM'ing, then tell them to (a) stop it and (b) fix that component to that it works properly. > But when the webapp tries to connect, it gets >>> java.net.ConnectException: Failed to connect to >>> maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 >> >> And the really weird part is that none of the messages in the >> resulting stacktrace appear to refer to any of our classes, or to >> any classes that appear to have anything to do with Tomcat. >> > > This is not so weird, if that webapp (as is likely) contains its > own classes to make the connection that /it/ tries to make to the > Google server. Or, like a lot of software, using something like Apache http-client. The package name for that starts with org.apache.http and there can be miles of stack frames in their traces. (IMO http-client has become far too complicated to be of use to casual programmers. I honestly can't believe it's that complicated to make an HTTP request. Spoiler alert: it's not.) Would you be willing to post some (or all!) of the stack trace? > The problem seems to be with the webapp, and you would have more > luck trying to get information from whoever supplied that webapp. > Maybe it has some parameter to increase its log level, which may > tell you in the log the details of why it cannot establish a TCP > connection with the Google server. (Who knows, the customer server > IP may even be blacklisted by Google..) That's an interesting thought, but Google doesn't usually do that without a really good reason. - -chris FYI, Google's certificate from maps.googleapis.com - -BEGIN CERTIFICATE- MIIJgjCCCGqgAwIBAgIQcK7vFJuw8fXplnyGbKi9QTANBgkqhkiG9w0BAQsFADBU MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw IwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE5MDUxNDEz MjkxM1oXDTE5MDgwNjEzMjAwMFowajELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2ds ZSBMTEMxGTAXBgNVBAMMECouZ29vZ2xlYXBpcy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6XmMJ8cxe0oZB9J7hVKGmxaVUTDv68JPrhWeKpnd0 fXrUFGJsP9XREfdRQV+K30pwSFFfbHA/nZCvwPpsp63uuLq+NBXZ7bqylRKyafbL ThBzkv/2U8SSPQuriQAAkJOS7c+wDfx8eugSzDq1NEmbRAAvYcphszy2LLD8GpZm 2ueogwYDnojcolZ2n34nXPq6ae8BQSxJzbhirzBknNapRuos/knu3KNWq/a/LgPx SVa1yN6OcBoWWRKcVYz74mGEbVA9kwAmA2xhGd/lXHg7lotjRgBWHv1Bt+QumRFE XCPIWeFcY/eSVqcNK0RUydp5UnMpvSYd/QfQ2sZAk3pNAgMBAAGjggY4MIIGNDAT BgNVHSUEDDAKBggrBgEFBQcDATCCBQ0GA1UdEQSCBQQwggUAghAqLmdvb2dsZWFw aXMuY29tghQqLmNsaWVudHM2Lmdvb2dsZS5hZYIUKi5jbGllbnRzNi5nb29nbGUu YXSCFCouY2xpZW50czYuZ29vZ2xlLmJlghQqLmNsaWVudHM2Lmdvb2dsZS5jYYIU Ki5jbGllbnRzNi5nb29nbGUuY2iCFCouY2xpZW50czYuZ29vZ2xlLmNsghcqLmNs aWVudHM2Lmdvb2dsZS5jby5pZIIXKi5jbGllbnRzNi5nb29nbGUuY28uaWyCFyou Y2xpZW50czYuZ29vZ2xlLmNvLmlughcqLmNsaWVudHM2Lmdvb2dsZS5jby5qcIIX Ki5jbGllbnRzNi5nb29nbGUuY28ua3KCFyouY2xpZW50czYuZ29vZ2xlLmNvLm56 ghcqLmNsaWVudHM2Lmdvb2dsZS5jby51a4IXKi5jbGllbnRzNi5nb29nbGUuY28u dmWCFyouY2xpZW50czYuZ29vZ2xlLmNvLnphghUqLmNsaWVudHM2Lmdvb2dsZS5j b22CGCouY2xpZW50czYuZ29vZ2xlLmNvbS5hcoIYKi5jbGllbnRzNi5nb29nbGUu Y29tLmF1ghgqLmNsaWV
Re: AW: Outbound SSL?
On 31.05.2019 18:12, James H. H. Lampert wrote: Thanks. We think that the customer has solved the cipher problem, because, at least as of when I checked on Wednesday, that error message was no longer appearing. Yet they're still not connecting. I can *ping* maps.googleapis.com from their box, with no trouble whatsoever, That is perhaps because "ping" does not use TCP/IP, it uses another protocol called ICMP, which is (a) connection-less and (b) not usually blocked by firewalls. At least, this shows that the DNS part is working correctly, and that the customer's host has a "route" to that server. But for example, if the server (or a firewall) blocked connections to the port which the webapp is trying to reach, you would still get the problem below. (Or if the server simply is not listening on that port). But when the webapp tries to connect, it gets java.net.ConnectException: Failed to connect to maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 And the really weird part is that none of the messages in the resulting stacktrace appear to refer to any of our classes, or to any classes that appear to have anything to do with Tomcat. This is not so weird, if that webapp (as is likely) contains its own classes to make the connection that /it/ tries to make to the Google server. I believe that someone mentioned before, that Tomcat does not contain any class for making outbound connections to another server. The connection is thus (probably, at a lower level) made by classes belonging to the JVM which you are using to run Tomcat (like the "java.net.ConnectException" above). In any case, Tomcat itself has no role in it. The problem seems to be with the webapp, and you would have more luck trying to get information from whoever supplied that webapp. Maybe it has some parameter to increase its log level, which may tell you in the log the details of why it cannot establish a TCP connection with the Google server. (Who knows, the customer server IP may even be blacklisted by Google..) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Outbound SSL?
Thanks. We think that the customer has solved the cipher problem, because, at least as of when I checked on Wednesday, that error message was no longer appearing. Yet they're still not connecting. I can *ping* maps.googleapis.com from their box, with no trouble whatsoever, But when the webapp tries to connect, it gets java.net.ConnectException: Failed to connect to maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 And the really weird part is that none of the messages in the resulting stacktrace appear to refer to any of our classes, or to any classes that appear to have anything to do with Tomcat. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Outbound SSL?
Hi, > -Ursprüngliche Nachricht- > Von: Peter Kreuser > Gesendet: Donnerstag, 30. Mai 2019 07:22 > Outbound SSL is usually handled by the underlying Java VM. ... and the problem occurs often if you use different jdks, like openjdk and ibmjdk. You can run a small java program on your jvm to print out the supported And default protocols. Yet, I didn’t find a better way. e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html -- Mit freundlichen Grüßen / Kind Regards/ नमस्ते(Namaste) Bernd Schatz ITI/FT - CoC Enterprise Platforms Services (PAI) HPC Z252 Gebäude VDZ Ost 1.OG Plieninger Str. 150 70567 Stuttgart Bernd Schatz Büro: +49 711 17 41463 Mobile: +49 151 5862 6591 FAX: +49 711 17 7904 1252 mailto:bernd.sch...@daimler.com https://matter.i.daimler.com openpgp-digital-signature.asc Description: PGP signature
