Re: Need Help on Tomcat 8.1.1 SSL Public Facing URL !!
Hi, 2016-11-17 7:51 GMT+02:00 : > > Hi Group, > > Please help in resolving the issue with Public Facing URL of Tomcat server. Currently the existing configuration is as follows : > > > 1) Tomcat 8.1.1 is installed on Red-Hat Linux OS along with Jdk1.7 There isn't a version Tomcat 8.1.1 Please verify your Tomcat version. More information about Tomcat versions can be found here http://tomcat.apache.org/whichversion.html Regards, Violeta > 2) Tomcat is enabled with SSL and able to access with https with the IP Address in the internal network > > 3) Public IP address is assigned where this tomcat installed > > 4) Firewall rules are relaxed for both Http and Https ports > > 5) Tomcat server.xml is modified (Host Element) with the public facing host name instead of localhost > > But still Tomcat is not getting accessed in the internet either with Http or Https. Could you please throw some light where I am missing here ? > > I appreciate your quick help on this. > > Thanks & Regs, > Ramagopala Chaturvedula (Ram) > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: Tomcat 8.0.39 and tomcat 8.5.8 fails handling requsest
On 16/11/2016 20:05, Mark Eggers wrote:
> Mark,
>
> On 11/16/2016 12:23 AM, Mark Thomas wrote:
>> On 15/11/2016 22:36, Zdeněk Henek wrote:
>>> Hi,
>>>
>>> we are using tomcat 8.0.30 without problems.
>>>
>>> I have tested upgrade to 8.0.38 today and I got this error
>>> More env. details JDK 8, tested on both Linux and Windows using different
>>> JDK 8 updates (71, 111).
>>>
>>> 15-Nov-2016 17:14:51.189 INFO [http-nio-8080-exec-2]
>>> org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP
>>> request header
>>> Note: further occurrences of HTTP header parsing errors will be logged at
>>> DEBUG level.
>>> java.lang.IllegalArgumentException: Invalid character found in the request
>>> target. The valid characters are defined in RFC 7230 and RFC 3986
>>
>>
>>
>>> The parameter in the request is this
>>>
>>> /list?criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>>
>> Neither '{' nor '}' are permitted characters in a URI and that includes
>> the query string.
>>
>>> Looks like this commit caused the exception
>>> https://github.com/apache/tomcat80/commit/779d5d34e68e50d2f721897050b147106992f566
>>>
>>> The commit message says:
>>> Add additional checks for valid characters to the HTTP request line
>>> parsing so invalid request lines are rejected sooner.
>>>
>>> We don't get any error in 8.0.30 using same request.
>>>
>>> The state in 8.0.30 was bug or 8.0.38 should process parameter
>>>
>>> criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>>>
>>> ?
>>
>> Technically, 8.0.30 should have rejected the request but didn't.
>>
>> As per the commit message, Tomcat has tightened up validation of
>> incoming HTTP requests to reject any that are not specification compliant.
>>
>> For the query string, the relevant extracts from RFC 3986 are:
>>
>> query = *( pchar / "/" / "?" )
>>
>> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
>>
>> unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
>>
>> sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
>> / "*" / "+" / "," / ";" / "="
>>
>>
>> Hence, '{' and '}' are rejected.
>>
>> Mark
>
> Based on your explanation above, shouldn't the following query parameter
> be rejected?
>
> http://somehost/someurl?plist=tagA=valueA|tagB=valueB|tagC=valueC
>
> where tagA, tagB, tagC, valueA, valueB, valueC are all ALPHA or DIGIT.
>
> I didn't see "|" listed as acceptable anywhere in RFC 3986.
I agree, such a request should be rejected.
> However, above URL works in Tomcat 8.0.39.
I've just tested 9.0.x and 8.0.x and both rejected it. I don't think
there have been any changes since those releases. Are you sure that:
a) you are using 8.0.39
b) the client isn't encoding the '|' before it is sent to Tomcat
> I ask this because a developer has used the pipe symbol to separate
> components. It plays havoc with mod_security rules, among other things.
>
> . . . a bit puzzled
Me too. Any light you can shed would be helpful.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Sanity Check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I've got a problem with a vendor and I'd like another opinion just to
make sure I'm not crazy. The vendor and I have a difference of opinion
about how a character should be encoded in an HTTP POST request.
The vendor's API officially should accept requests in UTF-8 encoding.
We are using application/x-www-form-urlencoded content type.
I'm trying to send a message with a non-ASCII character -- for
example, a ® (that's (R), the registered trademark symbol).
The Java code being used to package-up this POST looks something like
this:
OutputStream out = httpurlconnection.getOutputStream();
out.print("notetext=");
out.print(URLEncoder.encode("test®", "UTF-8"));
out.close();
So the POST payload ends up being notetext=test%C2%AE or, on the wire,
the bytes are 6e 6f 74 65 74 65 78 74 3d 74 65 73 74 25 43 32 25 41 45.
The final bytes 25 43 32 25 41 45 are the characters % C 2 % A E.
Can someone verify that I'm encoding everything correctly?
The vendor is claiming that ® can be sent "directly" like one might do
using curl:
$ curl -d 'notetext=®' [url]
and the bytes on the wire are 6e 6f 74 65 74 65 78 74 3d c2 ae (note
that c2 and ae are "bare" and not %-encoded).
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYLbzjAAoJEBzwKT+lPKRYaYoP/2oXJV2vhL4bLuZ2SF/0K46E
cQvPE6QbL+6OeC3jfpPKICDd0/0mFmbIxusdKDEcOeKWogVC+lH2by4ghMz4/s/3
dHqi4XYdCymGAikx+khptsna5ITlEgwSVNgCxeZUtMK1MKVpJqa7qOrZkddRi9uZ
RuT54WZ7iVSqOxHvGBf6pJ148Oh0J9gPKMrEdTW48avulvYzKagAH8XgIs8uOM8c
Cvd3yPhRxGLD8tenIrPOiD6G6PYRaSnBY5dOp42vvLXvBPb++bsqNU69RpnxNz1D
W+2BD8P6MDOJQChyBAILBmhhJRLPBQQYZuXtMjAfUCceLYichao515rdpCRX7t7g
Lcyiaz6ht5vOo1iW/r05GviKNl02Fi4BA5gOGaFewlAEwBJIDkPG/NeHXFM8clsy
gRJnmXRtL5IR5hudASMqiRQf0AUG3Ss+gVXXHdsqc+XuE7Q0VawjonCqDLCDwGpG
ZNMIULyWdUosCd5gC47rRN7irsclfOJ8ynI2WREGPlTTml8TKaIhrsaoB4RI4M4r
dUxAgDFOiONwZuXy53peAp6jziUwjqZS2H6BTwSXu+p6+RKvgGL5IuHP3UFfwQbL
JYzakySFoBR6FxN3fiotXKtwAXMtE77k4irzuc/iSxmDmJTdwatRuIQTHbXRoDm0
HcQh/hM/mVNcgRZJ+aqh
=heIv
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL on Tomcat7 on AWS not connecting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 11/16/16 12:38 PM, George Chanady wrote: > I hope someone can help.I have exhausted all my troubleshooting > skills and all of my newbie Linux knowledge and I am at the end of > my rope. > > All documentation from around the web always seem to tell me to > try everything I have already tried. I am sure that there must be a > caveat that I am missing. > > I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the > life of me get the SSL working. > > I set up the AWS instance with nothing else on the server and using > a fresh installation of Tomcat with basic config settings. I am > able to connect http://mysite.com:8080 but cannot connect with > https://mysite.com:8443. I am able to SSH as that is the only way I > communicate with the server. > > I only have forwarders for port 80 and 443 in the iptables and > nothing else and have security groups in AWS setup to allow all > traffic from everywhere for ports 80, 8080, 443, and 8443. > > I have ensured the ports needed are open and listening using > netstat I have checked to ensure connectivity to the ports from > other machines using netcat I checked that the certs were installed > properly and that the tomcat connectors were pointed the proper > location > > I am attaching my configuration from start to where I hit the > wall. What if you give curl the --tls1 switch? Can you try with openssl s_client? I find that tends to give more information about the conversation. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLcVwAAoJEBzwKT+lPKRY+7UQAIURP7wWTMinfL8E28SERuwK NsyvBQOEsWXSHweN5tkmgqiUF7zWcYFf0j+reDpaEvR9KIV+Wd1vI/LvCqQO7wEA p8Nv+jvet3ObWOInN9A0HcZsf8H5bpuIrE0a2d/B5P2EIFEOlESgjhgyEjcNEVL/ LFwSZX+rCbtzt/vSSk8fQpout7+5jaYIOLOhxmB4qAvBJI3dLXOV4d3Kfty+FxrK JfUwBDsS4RdZoH+i52XXemERR+Y5cIcpNul2BFQ0xo2knRfVPl1b1mzWxJGuAFbI lHZr9QuyaOymgYJ6PTGRQZXx2jXCdYM7U8ryTShTeiGC8b5IMfMF9z2E3qRfdcAw RZXaDJ3GKVPcZcGBvFCtP6G5I1UiOi6PrXu/TkjmfG8tlyqA3dkXyH/dIYUYuO0Y h65brIcLNZZbiOECX0v/jupMlnHa584cZcYOnvXF9wrfBQb3d62PFf4DRO+a0ozk AKEGxBdGt75KzMpb5PS6pH+T74P6LHqrCTEzZ63G9O0No0CSKFwRizb+4DGeOTDN dYk7Bx7+HolYe1u02mBgEfgfwItrj8131ddHoHSp8btYVyJ+2HfmI9DOJV9Cxo+r 1aa0DeIsu6G24TkFrpNzn+SgBYyZdp/+lNeWnxbz4fu4wMLcetVbpSdSjQ8xeKna uIACDouiyhLDNYXgVhmz =/Z5J -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need Help on Tomcat 8.1.1 SSL Public Facing URL !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ramagopala, On 11/17/16 12:51 AM, ramagopala.chaturved...@wipro.com wrote: > Please help in resolving the issue with Public Facing URL of > Tomcat server. Currently the existing configuration is as follows > : > > > 1) Tomcat 8.1.1 is installed on Red-Hat Linux OS along with > Jdk1.7 > > 2) Tomcat is enabled with SSL and able to access with https > with the IP Address in the internal network > > 3) Public IP address is assigned where this tomcat installed > > 4) Firewall rules are relaxed for both Http and Https ports > > 5) Tomcat server.xml is modified (Host Element) with the > public facing host name instead of localhost > > But still Tomcat is not getting accessed in the internet either > with Http or Https. Could you please throw some light where I am > missing here ? So you cannot access Tomcat using the server's public IP address from out on the internet? If your client is within the internal network and you use the internal IP address, does that work? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLcipAAoJEBzwKT+lPKRYDKEQAMGQZIY71uLKsYbsMOZxILL+ hyqTX8f/KfTnO+KK24kcOyXIwIXUP6X0QoMlodHN6fu9rKSbfCOd3JURZjc+5dML cy9zVu2AOWnthx9W16vkNI7dtvfU5H4NHheSsIa+iM3BzM9HyVd1LqoUQm21dDvV PxFrgJD2Fdv7PKN74+I5f00D6QwQNdNLX8unXKUphB5kknSGkkxXLhkCPf2N/Ty4 osPtSK38ZCkWTrLX02OSN8F9qgK0h5v5m0qRJtbWujgpZVwX4B1MAbukITl4/Ujl RBaNXNAly4ZXBpn2bgEAWLCwEGt9EB0nvvFh74TM6onr9yi4c2mtYd3b7Lf3WICx T2b0sRhVHcDcaYSfhfA5lslWHR2UBUQbAhnKCUKB94cwnsiE41AnFbRCURTw7ewq b+Uzxu73Mjn3mrBkSnmelyLbPfwxM+cbBVMa6qPDI9/iVgGufUT5LmdMXMmoGqIb lROqaZ2P0KlRAVFzfr/lVGyicixf2TJzDLNIjpoQ1vJ4jJYOQw3KUTi4UGfjcTsY RqtRBKIji4NoL/gsrHNViOwkaA+QJrIplNVc54/jd4AyMoGROIqlehsutnA/j6Nx i1hRA2n4JQY56TwatyFW3SZZICAeDu2Y9Y2xE2KHl1TwNo4FEIeRTa8j5DGz+bnk mFH2QtmLzCS3ZIG5fobn =lVYd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 enabling SSL for JDBC during startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mohan, On 11/16/16 5:01 PM, Mohan Kumar wrote: > I'm using Tomcat 6.0.29 version with Java 1.6.0_45 on Windows > server 2008 and started noticing SSL related information in > Catalina logs recently. >> From the logs it looks like SSL is getting enabled for JDBC. Any >> help to > understand why the below information shows up in catalina logs > would be much appreciated? There is nothing that got changed in the > JDBC datasource configuration recently and the application uses SQL > server 2008. > >> From catalina.log > > Oct 31, 2016 10:18:26 AM com.microsoft.sqlserver.jdbc.TDSChannel > enableSSL INFO: java.security path: C:\Program > Files\Java\jre6\lib\security Security providers: [SUN version 1.6, > SunRsaSign version 1.5, SunJSSE version 1.6, SunJCE version 1.6, > SunJGSS version 1.0, SunSASL version 1.5, XMLDSig version 1.0, > SunPCSC version 1.6, SunMSCAPI version 1.6] SSLContext provider > info: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, > TLSv1) SSLContext provider services: [SunJSSE: KeyFactory.RSA -> > sun.security.rsa.RSAKeyFactory aliases: [1.2.840.113549.1.1, > OID.1.2.840.113549.1.1] , SunJSSE: KeyPairGenerator.RSA -> > sun.security.rsa.RSAKeyPairGenerator aliases: [1.2.840.113549.1.1, > OID.1.2.840.113549.1.1] , SunJSSE: Signature.MD2withRSA -> > sun.security.rsa.RSASignature$MD2withRSA aliases: > [1.2.840.113549.1.1.2, OID.1.2.840.113549.1.1.2] , SunJSSE: > Signature.MD5withRSA -> sun.security.rsa.RSASignature$MD5withRSA > aliases: [1.2.840.113549.1.1.4, OID.1.2.840.113549.1.1.4] , > SunJSSE: Signature.SHA1withRSA -> > sun.security.rsa.RSASignature$SHA1withRSA aliases: > [1.2.840.113549.1.1.5, OID.1.2.840.113549.1.1.5, 1.3.14.3.2.29, > OID.1.3.14.3.2.29] , SunJSSE: Signature.MD5andSHA1withRSA -> > com.sun.net.ssl.internal.ssl.RSASignature , SunJSSE: > KeyManagerFactory.SunX509 -> > com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509 , > SunJSSE: KeyManagerFactory.NewSunX509 -> > com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$X509 , SunJSSE: > TrustManagerFactory.SunX509 -> > com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl$SimpleFactory > , SunJSSE: TrustManagerFactory.PKIX -> > com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl$PKIXFactory > aliases: [SunPKIX, X509, X.509] , SunJSSE: SSLContext.SSL -> > com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: > SSLContext.SSLv3 -> com.sun.net.ssl.internal.ssl.SSLContextImpl , > SunJSSE: SSLContext.TLS -> > com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: > SSLContext.TLSv1 -> com.sun.net.ssl.internal.ssl.SSLContextImpl , > SunJSSE: SSLContext.Default -> > com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl , SunJSSE: > KeyStore.PKCS12 -> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore > ] java.ext.dirs: C:\Program > Files\Java\jre6\lib\ext;C:\Windows\Sun\Java\lib\ext > > And sometimes, there are warnings in the catalina logs about DB > connection pool initialization and the application would not be > able to connect to databases until another Tomcat restart. > > Oct 31, 2016 10:18:26 AM org.apache.naming.NamingContext lookup > WARNING: Unexpected exception resolving reference > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Error preloading > the connection pool at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicData Source.java:1398) > > at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getLogWriter(BasicDataSource .java:1098) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory.createDataSource(Ba sicDataSourceFactory.java:350) > > at org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory.getObjectInstance(Bas icDataSourceFactory.java:156) > at > org.moss.jdj.dbcp.EncryptedDataSourceFactory.getObjectInstance(Encrypt edDataSourceFactory.java:25) > > > at java.lang.reflect.Method.invoke(Unknown Source) at > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) > Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The > driver could not establish a secure connection to SQL Server by > using Secure Sockets Layer (SSL) encryption. Error: "SQL Server > returned an incomplete response. The connection has been closed.". > at > com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerCo nnection.java:1352) > > at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1533) > at > com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServ erConnection.java:1042) > > at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnecti on.java:817) > at > com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConn ection.java:700) > > at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.jav a:842) > at > org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(D riverConnectionFactory.java:38) > > at org.apache.tomcat.dbcp.dbcp.PoolableConnectio
Getting "Invalid message received with signature xxxxx" messages in catalina.out
Ladies and Gentlemen: Got a customer box, Tomcat 7.0.47 running on an AS/400, and I'm getting a lot of Nov 17, 2016 3:39:44 AM org.apache.coyote.ajp.AjpMessage processHeader SEVERE: Invalid message received with signature 18245 with occasional Nov 17, 2016 3:41:06 AM org.apache.coyote.ajp.AjpMessage processHeader SEVERE: Invalid message received with signature 18501 mixed in. They're coming in clusters, about 3-4 within a minute or two, separated by anywhere from a few minutes to a few hours. I'm also seeing occasional clusters of java.io.IOException: The requested resource is busy. The only contexts running are two instances of our own CRM front-end, along with manager and host-manager. I've never seen this before, and a Google search on the message seems to mainly return answers for a different Apache product. Can anybody tell me what it is I'm looking at? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multi-level context path
I can't get my multi-level context path to deploy correctly. In Tomcat 5.5.26 foo#bar.war placed in my webapps directory deploys to /foo/bar. This is how I think is should work. In Tomcat 8.0.39 foo#bar.war placed in my webapps directory deploys to /foo#bar. It is like Tomcat doesn't recognize the #. My OS is Windows 2012 R2
Re: Getting "Invalid message received with signature xxxxx" messages in catalina.out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 11/17/16 11:54 AM, James H. H. Lampert wrote: > Ladies and Gentlemen: > > Got a customer box, Tomcat 7.0.47 running on an AS/400, and I'm > getting a lot of >> Nov 17, 2016 3:39:44 AM org.apache.coyote.ajp.AjpMessage >> processHeader SEVERE: Invalid message received with signature >> 18245 > > with occasional >> Nov 17, 2016 3:41:06 AM org.apache.coyote.ajp.AjpMessage >> processHeader SEVERE: Invalid message received with signature >> 18501 > mixed in. > > They're coming in clusters, about 3-4 within a minute or two, > separated by anywhere from a few minutes to a few hours. > > I'm also seeing occasional clusters of >> java.io.IOException: The requested resource is busy. > > The only contexts running are two instances of our own CRM > front-end, along with manager and host-manager. > > I've never seen this before, and a Google search on the message > seems to mainly return answers for a different Apache product. > > Can anybody tell me what it is I'm looking at? Presumably, you have httpd out in front of your Tomcat instances? Please check to see that these two configuration settings match each other: httpd/mod_jk: worker.name.max_packet_size=[some value] (or for mod_proxy_ajp: ProxyIOBufferSize [some value] ) Tomcat: http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLeonAAoJEBzwKT+lPKRYh4gP/jzjoUkDLQViSXJAT6NcxL38 qHHZBNIfaZivtnDkuRb7TTHDOyFu/5jM5SfSzr/B9lPwKAc0H8c9DhubfoQZ0CX7 6kuILJOoUOAfwTLIuHxQ3UjwzWwEucT0ephjg+rGn8KJH27h8j+2bZJjKymjZEBK Y8bik/xJYzI0hNyrUdTW4garbCCOvJ7fOr0SW5b2Qnin3BqvcyikOolw2nVCrkHr AoVV+/kD+M9F2oOsRHCifz/dQ5w213vfJcQ5ZjicDnfeTglcZoaDCBzzDGqiWxmP 4hsHcRH+y7a7SEelXG9+DVkmp1VbHJUA5S89zXdjcoktZKRRVNUXZZIoed9CYyym QVcD3+9l86EL8VgjsLYE3ILVRybACEgryEFADy+hWGCDjtSB84WVnNAPoHTIOSm+ Fi5YUMnf2POlZGAEr61zIM7HOwlnL7EB1RrHhSXeMzFtrL4BFuNDFfQRgMVLT0Me HAM4uabjneJu3IZbG8ai6vE4XJvjx+7+SyFMaRyyNsqi1S4NhpX7Vm5QdSquMcH2 6Os8IBG4SCn3oFq7YfN1eMGOgnfLLa2iOKwFJDgdEwllNbVYV90Re6SRFeTpX5aV oRUfrsxbcJ9Xh56A40Lnf2UVYn6J706tKCGU7nPVY5DrR2z3VoHjDk5NDGW6K7uO Rku5XM/DrQ93VvAas27c =UePC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting "Invalid message received with signature xxxxx" messages in catalina.out
On 11/17/16, 9:34 AM, Christopher Schultz wrote: Presumably, you have httpd out in front of your Tomcat instances? I wouldn't know. Tomcat is running by itself, rather than under Apache (or anything else), using JSSE, rather than OpenSSL. Connector tag is: Two other details (the first of which I hadn't known at the time of the initial query): 1. This particular Tomcat server has been running nonstop since June 5th. 2. Our webapp uses BIRT reports, and the customer has been having response time issues and error messages, particularly in connection with the BIRT reports. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.39 and tomcat 8.5.8 fails handling requsest
Mark,
On 11/17/2016 2:00 AM, Mark Thomas wrote:
> On 16/11/2016 20:05, Mark Eggers wrote:
>> Mark,
>>
>> On 11/16/2016 12:23 AM, Mark Thomas wrote:
>>> On 15/11/2016 22:36, Zdeněk Henek wrote:
Hi,
we are using tomcat 8.0.30 without problems.
I have tested upgrade to 8.0.38 today and I got this error
More env. details JDK 8, tested on both Linux and Windows using different
JDK 8 updates (71, 111).
15-Nov-2016 17:14:51.189 INFO [http-nio-8080-exec-2]
org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP
request header
Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986
>>>
>>>
>>>
The parameter in the request is this
/list?criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>>>
>>> Neither '{' nor '}' are permitted characters in a URI and that includes
>>> the query string.
>>>
Looks like this commit caused the exception
https://github.com/apache/tomcat80/commit/779d5d34e68e50d2f721897050b147106992f566
The commit message says:
Add additional checks for valid characters to the HTTP request line
parsing so invalid request lines are rejected sooner.
We don't get any error in 8.0.30 using same request.
The state in 8.0.30 was bug or 8.0.38 should process parameter
criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
?
>>>
>>> Technically, 8.0.30 should have rejected the request but didn't.
>>>
>>> As per the commit message, Tomcat has tightened up validation of
>>> incoming HTTP requests to reject any that are not specification compliant.
>>>
>>> For the query string, the relevant extracts from RFC 3986 are:
>>>
>>> query = *( pchar / "/" / "?" )
>>>
>>> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
>>>
>>> unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
>>>
>>> sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
>>> / "*" / "+" / "," / ";" / "="
>>>
>>>
>>> Hence, '{' and '}' are rejected.
>>>
>>> Mark
>>
>> Based on your explanation above, shouldn't the following query parameter
>> be rejected?
>>
>> http://somehost/someurl?plist=tagA=valueA|tagB=valueB|tagC=valueC
>>
>> where tagA, tagB, tagC, valueA, valueB, valueC are all ALPHA or DIGIT.
>>
>> I didn't see "|" listed as acceptable anywhere in RFC 3986.
>
> I agree, such a request should be rejected.
>
>> However, above URL works in Tomcat 8.0.39.
>
> I've just tested 9.0.x and 8.0.x and both rejected it. I don't think
> there have been any changes since those releases. Are you sure that:
> a) you are using 8.0.39
> b) the client isn't encoding the '|' before it is sent to Tomcat
>
>> I ask this because a developer has used the pipe symbol to separate
>> components. It plays havoc with mod_security rules, among other things.
>>
>> . . . a bit puzzled
>
> Me too. Any light you can shed would be helpful.
I did a Wireshark capture. The client is not encoding '|' before
sending. The '=' is not being encoded either.
I figured it out. I have Apache 2.2 (on Linux) or Apache 2.4 (on
Windows) in front of Tomcat.
I connect the two using mod_jk. When going through the following:
browser --> apache httpd (2.2, 2.4) -->(AJP) Tomcat (8.0.39, 8.5.8)
the request works ('|', '=', and other hideousness).
When going through the following:
browser --> Tomcat (8.0.39, 8.5.8)
the request fails with the error message as posted by the original author.
I'll go through the Apache HTTPD and mod_jk configurations carefully to
see what's going on.
However, both are pretty stock configurations.
. . . thanks for your patience
/mde/
signature.asc
Description: OpenPGP digital signature
Re: Tomcat 8.0.39 and tomcat 8.5.8 fails handling requsest
On 17/11/2016 21:29, Mark Eggers wrote:
> Mark,
>
>
> On 11/17/2016 2:00 AM, Mark Thomas wrote:
>> On 16/11/2016 20:05, Mark Eggers wrote:
>>> Mark,
>>>
>>> On 11/16/2016 12:23 AM, Mark Thomas wrote:
On 15/11/2016 22:36, Zdeněk Henek wrote:
> Hi,
>
> we are using tomcat 8.0.30 without problems.
>
> I have tested upgrade to 8.0.38 today and I got this error
> More env. details JDK 8, tested on both Linux and Windows using different
> JDK 8 updates (71, 111).
>
> 15-Nov-2016 17:14:51.189 INFO [http-nio-8080-exec-2]
> org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing
> HTTP
> request header
> Note: further occurrences of HTTP header parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: Invalid character found in the
> request
> target. The valid characters are defined in RFC 7230 and RFC 3986
> The parameter in the request is this
>
> /list?criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
Neither '{' nor '}' are permitted characters in a URI and that includes
the query string.
> Looks like this commit caused the exception
> https://github.com/apache/tomcat80/commit/779d5d34e68e50d2f721897050b147106992f566
>
> The commit message says:
> Add additional checks for valid characters to the HTTP request line
> parsing so invalid request lines are rejected sooner.
>
> We don't get any error in 8.0.30 using same request.
>
> The state in 8.0.30 was bug or 8.0.38 should process parameter
>
> criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>
> ?
Technically, 8.0.30 should have rejected the request but didn't.
As per the commit message, Tomcat has tightened up validation of
incoming HTTP requests to reject any that are not specification compliant.
For the query string, the relevant extracts from RFC 3986 are:
query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Hence, '{' and '}' are rejected.
Mark
>>>
>>> Based on your explanation above, shouldn't the following query parameter
>>> be rejected?
>>>
>>> http://somehost/someurl?plist=tagA=valueA|tagB=valueB|tagC=valueC
>>>
>>> where tagA, tagB, tagC, valueA, valueB, valueC are all ALPHA or DIGIT.
>>>
>>> I didn't see "|" listed as acceptable anywhere in RFC 3986.
>>
>> I agree, such a request should be rejected.
>>
>>> However, above URL works in Tomcat 8.0.39.
>>
>> I've just tested 9.0.x and 8.0.x and both rejected it. I don't think
>> there have been any changes since those releases. Are you sure that:
>> a) you are using 8.0.39
>> b) the client isn't encoding the '|' before it is sent to Tomcat
>>
>>> I ask this because a developer has used the pipe symbol to separate
>>> components. It plays havoc with mod_security rules, among other things.
>>>
>>> . . . a bit puzzled
>>
>> Me too. Any light you can shed would be helpful.
>
> I did a Wireshark capture. The client is not encoding '|' before
> sending. The '=' is not being encoded either.
>
> I figured it out. I have Apache 2.2 (on Linux) or Apache 2.4 (on
> Windows) in front of Tomcat.
>
> I connect the two using mod_jk. When going through the following:
>
> browser --> apache httpd (2.2, 2.4) -->(AJP) Tomcat (8.0.39, 8.5.8)
>
> the request works ('|', '=', and other hideousness).
>
> When going through the following:
>
> browser --> Tomcat (8.0.39, 8.5.8)
>
> the request fails with the error message as posted by the original author.
>
> I'll go through the Apache HTTPD and mod_jk configurations carefully to
> see what's going on.
>
> However, both are pretty stock configurations.
The AJP checks are much less rigorous since it is assumed that the
front-end server will validate the data before forwarding. It looks like
httpd isn't as strict as Tomcat in this case.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.39 and tomcat 8.5.8 fails handling requsest
Mark,
On 11/17/2016 1:06 PM, Mark Thomas wrote:
> On 17/11/2016 21:29, Mark Eggers wrote:
>> Mark,
>>
>>
>> On 11/17/2016 2:00 AM, Mark Thomas wrote:
>>> On 16/11/2016 20:05, Mark Eggers wrote:
Mark,
On 11/16/2016 12:23 AM, Mark Thomas wrote:
> On 15/11/2016 22:36, Zdeněk Henek wrote:
>> Hi,
>>
>> we are using tomcat 8.0.30 without problems.
>>
>> I have tested upgrade to 8.0.38 today and I got this error
>> More env. details JDK 8, tested on both Linux and Windows using different
>> JDK 8 updates (71, 111).
>>
>> 15-Nov-2016 17:14:51.189 INFO [http-nio-8080-exec-2]
>> org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing
>> HTTP
>> request header
>> Note: further occurrences of HTTP header parsing errors will be logged
>> at
>> DEBUG level.
>> java.lang.IllegalArgumentException: Invalid character found in the
>> request
>> target. The valid characters are defined in RFC 7230 and RFC 3986
>
>
>
>> The parameter in the request is this
>>
>> /list?criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>
> Neither '{' nor '}' are permitted characters in a URI and that includes
> the query string.
>
>> Looks like this commit caused the exception
>> https://github.com/apache/tomcat80/commit/779d5d34e68e50d2f721897050b147106992f566
>>
>> The commit message says:
>> Add additional checks for valid characters to the HTTP request line
>> parsing so invalid request lines are rejected sooner.
>>
>> We don't get any error in 8.0.30 using same request.
>>
>> The state in 8.0.30 was bug or 8.0.38 should process parameter
>>
>> criteria={%22$type%22:%22Equal%22,%22attr%22:%22id%22,%22value%22:101}
>>
>> ?
>
> Technically, 8.0.30 should have rejected the request but didn't.
>
> As per the commit message, Tomcat has tightened up validation of
> incoming HTTP requests to reject any that are not specification compliant.
>
> For the query string, the relevant extracts from RFC 3986 are:
>
> query = *( pchar / "/" / "?" )
>
> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
>
> unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
>
> sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
> / "*" / "+" / "," / ";" / "="
>
>
> Hence, '{' and '}' are rejected.
>
> Mark
Based on your explanation above, shouldn't the following query parameter
be rejected?
http://somehost/someurl?plist=tagA=valueA|tagB=valueB|tagC=valueC
where tagA, tagB, tagC, valueA, valueB, valueC are all ALPHA or DIGIT.
I didn't see "|" listed as acceptable anywhere in RFC 3986.
>>>
>>> I agree, such a request should be rejected.
>>>
However, above URL works in Tomcat 8.0.39.
>>>
>>> I've just tested 9.0.x and 8.0.x and both rejected it. I don't think
>>> there have been any changes since those releases. Are you sure that:
>>> a) you are using 8.0.39
>>> b) the client isn't encoding the '|' before it is sent to Tomcat
>>>
I ask this because a developer has used the pipe symbol to separate
components. It plays havoc with mod_security rules, among other things.
. . . a bit puzzled
>>>
>>> Me too. Any light you can shed would be helpful.
>>
>> I did a Wireshark capture. The client is not encoding '|' before
>> sending. The '=' is not being encoded either.
>>
>> I figured it out. I have Apache 2.2 (on Linux) or Apache 2.4 (on
>> Windows) in front of Tomcat.
>>
>> I connect the two using mod_jk. When going through the following:
>>
>> browser --> apache httpd (2.2, 2.4) -->(AJP) Tomcat (8.0.39, 8.5.8)
>>
>> the request works ('|', '=', and other hideousness).
>>
>> When going through the following:
>>
>> browser --> Tomcat (8.0.39, 8.5.8)
>>
>> the request fails with the error message as posted by the original author.
>>
>> I'll go through the Apache HTTPD and mod_jk configurations carefully to
>> see what's going on.
>>
>> However, both are pretty stock configurations.
>
> The AJP checks are much less rigorous since it is assumed that the
> front-end server will validate the data before forwarding. It looks like
> httpd isn't as strict as Tomcat in this case.
>
> Mark
Also, the default for mod_jk JkOptions is:
JkOptions +ForwardURIProxy
which according to the documentation does a partial encoding before
sending the request off to Tomcat.
So in summary:
1. Apache HTTPD 2.2 and Apache HTTPD 2.4 are lenient when parsing URIs
2. Default JkOptions partially encode the request before sending
3. The resulting encoded URI is happily parsed by Tomcat
Removing Apache HTTPD 2.2 / Apache HTTPD 2.4 with the default mod_jk
configuration (JkOptions) and the URI will no longer work with Tomcat 8.x.
Time to get the developers to fix their code.
. . . just my two
RE: SSL on Tomcat7 on AWS not connecting
Chris, I tried curl with the -tls1 switch and received the same error. [ec2-user@ip-172-31-52-159 bin]$ curl -vk https://bageoconsultants.com:8443 -tls1 * Rebuilt URL to: https://bageoconsultants.com:8443/ * Trying 52.54.85.95... * Connected to bageoconsultants.com (52.54.85.95) port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP) * Cannot communicate securely with peer: no common encryption algorithm(s). * Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). I also tried with openssl s_client which was the last few lines of my of the original attachment. Also a no go, [ec2-user@ip-172-31-34-217 conf]$ openssl s_client -connect bageoconsultants.com:8443 CONNECTED(0003) 140427891013472:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 249 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Thanks --George -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, November 17, 2016 9:58 AM To: Tomcat Users List Subject: Re: SSL on Tomcat7 on AWS not connecting -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 11/16/16 12:38 PM, George Chanady wrote: > I hope someone can help.I have exhausted all my troubleshooting skills > and all of my newbie Linux knowledge and I am at the end of my rope. > > All documentation from around the web always seem to tell me to try > everything I have already tried. I am sure that there must be a caveat > that I am missing. > > I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the > life of me get the SSL working. > > I set up the AWS instance with nothing else on the server and using a > fresh installation of Tomcat with basic config settings. I am able to > connect http://mysite.com:8080 but cannot connect with > https://mysite.com:8443. I am able to SSH as that is the only way I > communicate with the server. > > I only have forwarders for port 80 and 443 in the iptables and nothing > else and have security groups in AWS setup to allow all traffic from > everywhere for ports 80, 8080, 443, and 8443. > > I have ensured the ports needed are open and listening using netstat I > have checked to ensure connectivity to the ports from other machines > using netcat I checked that the certs were installed properly and that > the tomcat connectors were pointed the proper location > > I am attaching my configuration from start to where I hit the wall. What if you give curl the --tls1 switch? Can you try with openssl s_client? I find that tends to give more information about the conversation. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLcVwAAoJEBzwKT+lPKRY+7UQAIURP7wWTMinfL8E28SERuwK NsyvBQOEsWXSHweN5tkmgqiUF7zWcYFf0j+reDpaEvR9KIV+Wd1vI/LvCqQO7wEA p8Nv+jvet3ObWOInN9A0HcZsf8H5bpuIrE0a2d/B5P2EIFEOlESgjhgyEjcNEVL/ LFwSZX+rCbtzt/vSSk8fQpout7+5jaYIOLOhxmB4qAvBJI3dLXOV4d3Kfty+FxrK JfUwBDsS4RdZoH+i52XXemERR+Y5cIcpNul2BFQ0xo2knRfVPl1b1mzWxJGuAFbI lHZr9QuyaOymgYJ6PTGRQZXx2jXCdYM7U8ryTShTeiGC8b5IMfMF9z2E3qRfdcAw RZXaDJ3GKVPcZcGBvFCtP6G5I1UiOi6PrXu/TkjmfG8tlyqA3dkXyH/dIYUYuO0Y h65brIcLNZZbiOECX0v/jupMlnHa584cZcYOnvXF9wrfBQb3d62PFf4DRO+a0ozk AKEGxBdGt75KzMpb5PS6pH+T74P6LHqrCTEzZ63G9O0No0CSKFwRizb+4DGeOTDN dYk7Bx7+HolYe1u02mBgEfgfwItrj8131ddHoHSp8btYVyJ+2HfmI9DOJV9Cxo+r 1aa0DeIsu6G24TkFrpNzn+SgBYyZdp/+lNeWnxbz4fu4wMLcetVbpSdSjQ8xeKna uIACDouiyhLDNYXgVhmz =/Z5J -END PGP SIGNATURE- - 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: Sanity Check
2016-11-17 17:21 GMT+03:00 Christopher Schultz :
> All,
>
> I've got a problem with a vendor and I'd like another opinion just to
> make sure I'm not crazy. The vendor and I have a difference of opinion
> about how a character should be encoded in an HTTP POST request.
>
> The vendor's API officially should accept requests in UTF-8 encoding.
> We are using application/x-www-form-urlencoded content type.
>
> I'm trying to send a message with a non-ASCII character -- for
> example, a ® (that's (R), the registered trademark symbol).
>
> The Java code being used to package-up this POST looks something like
> this:
>
> OutputStream out = httpurlconnection.getOutputStream();
> out.print("notetext=");
> out.print(URLEncoder.encode("test®", "UTF-8"));
> out.close();
>
> So the POST payload ends up being notetext=test%C2%AE or, on the wire,
> the bytes are 6e 6f 74 65 74 65 78 74 3d 74 65 73 74 25 43 32 25 41 45.
>
> The final bytes 25 43 32 25 41 45 are the characters % C 2 % A E.
>
> Can someone verify that I'm encoding everything correctly?
>
> The vendor is claiming that ® can be sent "directly" like one might do
> using curl:
>
> $ curl -d 'notetext=®' [url]
>
> and the bytes on the wire are 6e 6f 74 65 74 65 78 74 3d c2 ae (note
> that c2 and ae are "bare" and not %-encoded).
1. That is a wrong way to use curl. The manual says that the argument
to -d should be properly urlencoded. The above value is an incorrect
one.
https://curl.haxx.se/docs/manual.html
See "POST (HTTP)" and below.
2. If you are submitting data programmatically, I wonder why you are
using simple "application/x-www-form-urlencoded".
I think it would be better to use explicit charset argument in the
Content-Type value, as it is easy to do so with Java clients.
3. The application/x-www-form-urlencoded encoding was originally
specified in HTML specification.
Current specification:
https://www.w3.org/TR/html51/sec-forms.html#urlencoded-form-data
It defers details to
https://url.spec.whatwg.org/#concept-urlencoded-serializer
Historic, HTML 4.01:
https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
My opinion is that the correct value on the wire is
25 43 32 25 41 45 = % C 2 % A E.
If a vendor accepts non-encoded "c2 ae":
it technically may work (in some versions of some software), but this
is not a standard feature and one would better not rely on it.
Technically, if non-encoded bytes ("c2 ae") are accepted, they won't
be confused with special character ("=", "&", "+", "%", CRLF), as all
multi-byte UTF-8 characters have 0x80 bit set.
4. You code fragment is broken and won't compile: there are none
"print" methods in java.io.OutputStream.
OutputStream works with byte[] and the method name is "write".
5. Wikipedia:
https://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-urlencoded_type
Wikipedia mentions XForms spec,
-> https://www.w3.org/TR/2007/REC-xforms-20071029/#serialize-urlencode
6. You can test with real browsers.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL on Tomcat7 on AWS not connecting
Hi Igor, I am too new at Linux to know if the output from this is bad, other than the first line. Not really sure what the rest is telling me. [ec2-user@ip-172-31-52-159 logs]$ tail -f catalina.out java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:136) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1000) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Thanks, --George -Original Message- From: Igor Cicimov [mailto:icici...@gmail.com] Sent: Wednesday, November 16, 2016 8:48 PM To: Tomcat Users List Subject: Re: SSL on Tomcat7 on AWS not connecting On 17 Nov 2016 4:38 am, "George Chanady" wrote: > > I hope someone can help.I have exhausted all my troubleshooting skills and all of my newbie Linux knowledge and I am at the end of my rope. > > All documentation from around the web always seem to tell me to try everything I have already tried. I am sure that there must be a caveat that I am missing. > > I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the > life of me get the SSL working. > > I set up the AWS instance with nothing else on the server and using a fresh installation of Tomcat with basic config settings. I am able to connect http://mysite.com:8080 but cannot connect with https://mysite.com:8443. > I am able to SSH as that is the only way I communicate with the server. > > I only have forwarders for port 80 and 443 in the iptables and nothing else and have security groups in AWS setup to allow all traffic from everywhere for ports 80, 8080, 443, and 8443. > > I have ensured the ports needed are open and listening using netstat I > have checked to ensure connectivity to the ports from other machines using netcat > I checked that the certs were installed properly and that the tomcat connectors were pointed the proper location > > I am attaching my configuration from start to where I hit the wall. > > Thanks in advance for any assistance. > And you are sure the keystore loads properly? Are those values for keystoreFile and keystorePass correct? Do you see any errors in catalina.out log? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Need Help on Tomcat 8.0.14.0 SSL Public Facing URL !!
Hi Violeta, Currently the existing configuration is as follows : 1) Server version: Apache Tomcat/8.0.14 Server built: Sep 24 2014 09:01:51 Server number: 8.0.14.0 OS Name:Linux OS Version: 3.10.0-229.el7.x86_64 JVM Version:1.8.0_51-b16 2)Tomcat is enabled with SSL and able to access with HTTP and HTTPS with the IP Address in the internal network 3)Public IP address is assigned where this tomcat installed 4)Firewall rules are relaxed for both HTTP and HTTPS ports 5)Tomcat server.xml is modified (Host Element) with the public facing host name instead of localhost But still Tomcat is not getting accessed in the internet either with Http or Https. Could you please throw some light where I am missing here ? I appreciate your quick help on this. Thanks & Regs, Ram. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: Tomcat6 enabling SSL for JDBC during startup
On Thu, Nov 17, 2016 at 7:13 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > king for help in correcting the problems that have caused the > messages in the first place? > Chris - Both. I would like to know why they started appearing in the catalina logs and how to correct the problems that caused these messages to appear. Cheers! Mohan
Re: Sanity Check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 11/17/16 4:58 PM, Konstantin Kolinko wrote:
> 2016-11-17 17:21 GMT+03:00 Christopher Schultz
> :
>> All,
>>
>> I've got a problem with a vendor and I'd like another opinion
>> just to make sure I'm not crazy. The vendor and I have a
>> difference of opinion about how a character should be encoded in
>> an HTTP POST request.
>>
>> The vendor's API officially should accept requests in UTF-8
>> encoding. We are using application/x-www-form-urlencoded content
>> type.
>>
>> I'm trying to send a message with a non-ASCII character -- for
>> example, a ® (that's (R), the registered trademark symbol).
>>
>> The Java code being used to package-up this POST looks something
>> like this:
>>
>> OutputStream out = httpurlconnection.getOutputStream();
>> out.print("notetext="); out.print(URLEncoder.encode("test®",
>> "UTF-8")); out.close();
>>
>> So the POST payload ends up being notetext=test%C2%AE or, on the
>> wire, the bytes are 6e 6f 74 65 74 65 78 74 3d 74 65 73 74 25 43
>> 32 25 41 45.
>>
>> The final bytes 25 43 32 25 41 45 are the characters % C 2 % A
>> E.
>>
>> Can someone verify that I'm encoding everything correctly?
>>
>> The vendor is claiming that ® can be sent "directly" like one
>> might do using curl:
>>
>> $ curl -d 'notetext=®' [url]
>>
>> and the bytes on the wire are 6e 6f 74 65 74 65 78 74 3d c2 ae
>> (note that c2 and ae are "bare" and not %-encoded).
>
> 1. That is a wrong way to use curl. The manual says that the
> argument to -d should be properly urlencoded. The above value is an
> incorrect one.
>
> https://curl.haxx.se/docs/manual.html See "POST (HTTP)" and below.
+1
The curl manual says that -d is the same as --data-ascii, which is
totally wrong here if they are accepting UTF-8.
> 2. If you are submitting data programmatically, I wonder why you
> are using simple "application/x-www-form-urlencoded".
>
> I think it would be better to use explicit charset argument in the
> Content-Type value, as it is easy to do so with Java clients.
Their API expects application/x-www-form-urlencoded. Everything else
they do is in JSON... I have no idea why they don't accept JSON as
input, but that's the deal.
MIME types that aren't text/* aren't supposed to have Content-Type
parameters.
> 3. The application/x-www-form-urlencoded encoding was originally
> specified in HTML specification.
>
> Current specification:
> https://www.w3.org/TR/html51/sec-forms.html#urlencoded-form-data
>
> It defers details to
> https://url.spec.whatwg.org/#concept-urlencoded-serializer
>
> Historic, HTML 4.01:
> https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
All true, but the spec argues with itself over the character encoding,
and browsers make this worse with their stupid "I'll use whatever
character encoding was used to load the page containing the form"
behavior. With a software-client API, there basically is no spec.
Their assertion is that their character encoding "is UTF-8". But it
looks like they aren't doing it right.
> My opinion is that the correct value on the wire is 25 43 32 25 41
> 45 = % C 2 % A E.
So, the same bytes as I had, right?
> If a vendor accepts non-encoded "c2 ae": it technically may work
> (in some versions of some software), but this is not a standard
> feature and one would better not rely on it.
>
> Technically, if non-encoded bytes ("c2 ae") are accepted, they
> won't be confused with special character ("=", "&", "+", "%",
> CRLF), as all multi-byte UTF-8 characters have 0x80 bit set.
Their non-%-encoded bytes could be considered legitimate, because the
application/x-www-form-urlencoded rules say that any character "in the
character set of the request" can be dropped-into the request without
being %-encoded. But they we are back to the problem of not knowing
what the encoding of the request is.
Since UTF-8 is supposed to be the "official" character encoding, I
would expect that a properly-encoded request would contain nothing but
valid ASCII characters, which means that 0xc2 0xae need to be
%-encoded to become "%c2%ae".
> 4. You code fragment is broken and won't compile: there are none
> "print" methods in java.io.OutputStream.
>
> OutputStream works with byte[] and the method name is "write".
Yes, it was hastily-typed from memory. The true code compiles and runs
as expected.
> 5. Wikipedia:
> https://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www
- -form-urlencoded_type
>
> Wikipedia mentions XForms spec, ->
> https://www.w3.org/TR/2007/REC-xforms-20071029/#serialize-urlencode
Thanks
>
for the XForms reference... it's nice that it has a real
example (including a non-ASCII character) instead of the usual trivial
examples in the HTTP and HTML specs, for instance.
> 6. You can test with real browsers.
I will certainly be doing that.
https://www.w3.org/TR/2007/REC-xforms-20071029/#serialize-urlencode
The vendor has responded with (paraphrasing) "it seems
Re: Getting "Invalid message received with signature xxxxx" messages in catalina.out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 11/17/16 12:52 PM, James H. H. Lampert wrote: > On 11/17/16, 9:34 AM, Christopher Schultz wrote: > >> Presumably, you have httpd out in front of your Tomcat >> instances? > > I wouldn't know. Tomcat is running by itself, rather than under > Apache (or anything else), using JSSE, rather than OpenSSL. > Connector tag is: > >> > keystoreFile=[REDACTED} alias=[REDACTED] maxThreads="150" >> scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" >> /> >> There must be another connector. This one uses HTTP, and the error messages you posted are using AJP. Do you have a connector in conf/server.xml that you thought was disabled, but isn't? > Two other details (the first of which I hadn't known at the time of > the initial query): 1. This particular Tomcat server has been > running nonstop since June 5th. Yay, uptime! Probably needs some OS patches, though :) > 2. Our webapp uses BIRT reports, and the customer has been having > response time issues and error messages, particularly in connection > with the BIRT reports. It's not clear whether BIRT is related, here. Probably not, but good to know. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLoraAAoJEBzwKT+lPKRYFZ4P/iq+MrtsOQ3LFNjjQwfljeM8 71yIF/DluUh3ZBgHPFd/rVgjfPb1TxNL1b6nXtSz2A2zJ4BMB09F09nrdWCLfsrB QspdD38v1RGf2rf61DCCx1pvjN3RL/epBKMKPOUbiBGYFS2dMVsxf7T4+X6L9Iuy rObjSNJzhcPr5plNtRw+lu8IAL92rid0+Z66oczD08g7Z+cgc3J78KFgiHUULQ6x pOpzmY/T1+cHT3bP9vsFIsMKsxIy8yaE9HjiAmH1G/+dsHabHfu9sy/l6JzEPvHa ohXbdJD7GVjNI8ibN6VfBO1Na6zUUMxIBXFyMyHw7HaTSkPlpxeC+ejb6RG/S4Rn KmkDomjjStphrmADJeHooC728RIqdsyQ/n6UvUxVPySrfH0RsNxJZ4wKZdfSHypt wYG49Os8QhBPTwyyypl4CT22/YsWxG/4jpWxih+mzn/y5TsV3tb6+EtdE+p/TASb MjejlhcUYFTSlZHlRobgwM6xuIiyYeEqtqGNGGd2JHohuk+nSFZf2hHpJ8KpE/4v 1ygvvq5z1MENTxcy5VHtxy3b45yLStVq2M0dDwnPhVMtfvGtfJBhx08bbK73ah+Y 9y7/QwmuYPkCbRwCNKtQkYu5tSO0Ka1CCnF2YOg0hQg2yfkU6HWE+x+oKhZ6NgEs vPuHaTY7vTXyVF/QQgDJ =8RL+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
