I've put the log files, the jpg of the chrome page and the netstat -a -b in Google Drive and sent you a link.
My application is somewhat complex and hopefully not the cause of the problem. It is composed of a large number of php and javascript files in the Financials application, which includes the php/java bridge, which calls into a java application called JFin in a number of places, which also has a large number of java files, The JFin jar is placed in the webapps/Financials/WEB-INFO/lib directory along with a large number of other jars, which are includes in the java files. All this runs fine under Tomcat on port 8080. The log files ect. that I sent are when I run localhost:8080/Financials. The log files capture the restart of Tomcat and the run of the Financials application. I also have run it under debug in NetBeans 8.2. and it never gets to the first line in Financials/index.php. The logs capture Tomcat startup, then run as localhost:8080/Financials.index.php in chrome and then at 12:49 I ran it in netbeans debug. The logs look ok in the first two cases, but when run under netbeans the tomcat stderr gave an error - 25-Sep-2017 12:56:18.251 INFO [http-nio-8080-exec-1] org.apache.coyote.http11.Http11Processor.service 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 method name. HTTP method names must be tokens at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine( Http11InputBuffer.java:406) I don't know what this means. Is it a clue or is it an artifact of NetBeans debug? It didn't show up in the run directly from chrome. I ran it again at about 1:30pm directly from chrome and the error again didn't show up. So the On Mon, Sep 25, 2017 at 10:26 AM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > On 25.09.2017 15:57, Don Flinn wrote: > >> Andre, >> >> I've attached the output from netstat -a. I see 8080 listening, but not >> 8443. I've also >> attached the screen shot of the result of running my "protected" >> application in Tomcat. >> > > This list removes most attachments, so we did not get the screenshot. > You have ti post it to dropbox or so, for us to have a look. > > But you should definitely look in the tomcat logfiles (in the subdirectory > inventively named "logs"), to see why it did not open port 8443 when > supposedly told to do so. > > As I mentioned, when I have Norton Security and it shuts down Windows >> firewall and runs >> its own firewall. >> > > Yes, but if port 8443 is not open and listening, that's a secondary > consideration now. The first is why tomcat does not open that port. > > P.S. There are additional options to netstat, which will also print the > name of the process which "owns" that port. Makes it easier to scan the > list, because it will say > "tomcat" next to the ones opened by tomcat. > > >> Don >> >> On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) <a...@ice-sa.com >> <mailto:a...@ice-sa.com>> wrote: >> >> On 24.09.2017 16 <tel:24.09.2017%2016>:08, Don Flinn wrote: >> >> Andre, >> >> I apologize for not giving all my information. As you perceived, >> I'm >> running Windows. Other info, Windows 10, Tomcat 9, java >> 1.8.0_144. As you >> suggested, using netstat and telnet I found that port 8443 is not >> open. >> Looking further Windows firewall is controlled by Norton >> security. I am >> now trying to find out how to open ports in Norton security using >> the >> Norton blog. >> >> Thank you for your help. As is obvious, I'm a newbee in low >> level admin >> work. I'm hoping that when I get port 8443 open things will >> work. I'll >> let you know. >> >> Maybe wait just a second more, before you go digging in the firewall. >> You say that you found out that "the port is not open". >> That is not the same thing as >> - the port /is/ open >> - but it cannot be connected to >> If netstat shows the port open and listening, but you cannot connect >> to it with >> telnet, it is probably a firewall issue. >> But if the port is not open, then it is a tomcat issue. >> Provided that you configured tomcat properly, the port should be >> open, firewall or no >> firewall. (A firewall can only block access by a client, to a server >> port that is >> open. It cannot prevent a server process to open that port for >> listening.) >> If it isn't open, the tomcat logs should tell you why. >> >> >> >> >> >> Don >> >> >> >> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) < >> a...@ice-sa.com >> <mailto:a...@ice-sa.com>> >> wrote: >> >> On 24.09.2017 02 <tel:24.09.2017%2002>:36, Don Flinn wrote: >> >> I'm trying to use a self signed certificate generated in >> keytool. When I >> run the application Chrome, Firefox and internet Explorer >> using >> localhost:8080/<myapp> all the browsers do a redirect to >> localhost:8443 >> and >> then return This site can’t be reachedL*ocalhost* refused >> to connect. >> There is no red lined out protocol in any of the >> browsers. All the Tomcat >> logs show no errors or warnings. I can access >> applications that are not >> protected and tomcat itself. >> >> >> I would suggest that you first re-read what you wrote above, >> line by line, >> and reflect quietly on what each line is telling you. >> >> 1) you say "localhost". That means that you are using a >> browser as client, >> on the same machine as the one which is running the server. >> 2) you also say that one of the browsers is IE. >> 3) (1) and (2) together imply that the host in a Windows >> server (and the >> client also of course). >> 4) you are not saying which version of Tomcat you are using, >> neither which >> version of Java, neither which version of Windows. That >> makes helping you >> more complicated and time-consuming, and delays any help, >> because now we >> have to ask you, and you have to respond. >> 5) "refused to connect" : before any kind of SSL dialog can >> even take >> place, the browser must be able to establish a TCP connection >> to the >> host:port in question. >> "refused to connect" seens to indicate that this is not the >> case. >> 6) the logs do not show anything : that would seem to >> corroborate (5) : >> tomcat does not even see this connection. iow, there is no >> connection. >> >> There are several possible reasons for this. >> a) Tomcat never opens the port 8443 for listening on it. >> That can be checked, with tomcat running, with the "netstat" >> utility >> program, included in Windows. With the proper arguments >> (which I will leave >> to you as an exercise)(but "netstat -h" will help), netstat >> will show you >> on which ports tomcat is listening locally. If this does not >> include a >> ":8443" port, then it is not listening on that port, and >> certainly the logs >> of tomcat will tell you why. >> b) tomcat does listen on port 8443, but something else is >> blocking access >> to that port. >> Then you probably have to check your local firewall settings >> (or whatever >> else in whatever version of Windows may be blocking >> connections to a port). >> >> Another quick way to check if tomcat (or anything) is >> listening on port >> 8443 (and/or something is blocking it) would be, in a command >> window, to >> run the following command : >> telnet localhost 8443 >> (also with tomcat running) >> If it also tells you "no connection", then (a) or (b) above >> would be >> confirmed. >> If it connects, then you may get another message, due to the >> fact that it >> expects an SSL connection. (If it did not expect an SSL >> connection, you'd >> just get a blank page until you type something else). >> Obviously, access to tomcat's port 8080 is fine, so you can >> compare the >> responses above with what happens when you substitute 8080 >> for 8443. >> >> Once the above is really cleared up, then it may be worth >> looking at the >> rest of the information which you sent below. >> >> If I set <transport-guarantee> >> >> CONFIDENTIAL</transport-guarantee> to NONE everything >> works with >> localhost:8080. >> >> My SSL files in tomcat - >> >> *server.xml -* >> >> Connector >> protocol="org.apache.coyote.ht >> <http://org.apache.coyote.ht>tp11.Http11NioProtocol" >> scheme="https" >> sslImplementationName="org.apa >> che.tomcat.util.net.jsse.JSSEI >> mplementation" >> SSLEnabled="true" acceptCount="100" clientAuth="false" >> disableUploadTimeout="true" enableLookups="false" >> maxThreads="25" >> port="8443" keystoreFile="c:/temp/mkeystore2.jks" >> keystorePass="foobar" >> secure="true" sslProtocol="TLS" clientAuth="false" /> >> >> *web.xml -* >> >> <security-constraint> >> <web-resource-collection> >> <web-resource-name> >> Financials</web-resource-name> >> <url-pattern>/*</url-pattern> >> </web-resource-collection> >> <user-data-constraint> >> <transport-guarantee>CONFIDEN >> TIAL</transport-guarantee> >> </user-data-constraint> >> </security-constraint> >> >> *the output from my keystore list -* >> >> C:\Users\don\Documents\Mansurus\Security> >> "%java_home%/bin/keytool.exe" >> -list -v -keystore c:/temp/mkeystore2.jks >> Enter keystore password: >> >> Keystore type: JKS >> Keystore provider: SUN >> >> Your keystore contains 1 entry >> >> Alias name: tomcat >> Creation date: Sep 23, 2017 >> Entry type: PrivateKeyEntry >> Certificate chain length: 1 >> Certificate[1]: >> Owner: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, >> ST=Unknown, C=Unknown >> Issuer: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, >> ST=Unknown, >> C=Unknown >> Serial number: 6b5fe428 >> Valid from: Sat Sep 23 12:57:19 EDT 2017 until: Sun Sep >> 23 12:57:19 EDT >> 2018 >> Certificate fingerprints: >> MD5: 11:9D:2C:50:4A:09:9D:17:2F:46: >> 3C:AF:AF:E5:59:EE >> SHA1: 63:EF:21:21:3C:22:82:46:21:84: >> 9C:81:C6:B0:C1:EC:0F:1C:87:31 >> SHA256: >> 4E:75:D6:6A:6C:23:84:E0:36:AF: >> CF:1E:56:7D:18:6E:A1:BE:E5:EE: >> 0B:E5:7B:2A:01:96:DF:49:CA:F1:50:C7 >> Signature algorithm name: SHA256withRSA >> Version: 3 >> >> Extensions: >> >> #1: ObjectId: 2.5.29.14 Criticality=false >> SubjectKeyIdentifier [ >> KeyIdentifier [ >> 0000: 46 C9 48 D4 54 2A 54 CE 24 1F 22 ED 1D FC 6E 14 >> F.H.T*T.$."...n.. >> 0010: BE 6F 4A 49 >> .oJI >> ] >> ] >> >> What am I doing wrong? I want to get a self-signed >> keystore working >> before >> I purchase a commercial certificate. >> >> Don >> >> >> >> ------------------------------------------------------------ >> --------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> <mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> <mailto:users-h...@tomcat.apache.org> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> <mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> <mailto:users-h...@tomcat.apache.org> >> >> >> >> >> >> --------------------------------------------------------------------- >> 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 > >
