Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.
Christopher, Peter Kreuser > Am 10.10.2017 um 00:14 schrieb Christopher Schultz > : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > James, > >> On 10/9/17 5:19 PM, Christopher Schultz wrote: >>> On 10/6/17 6:34 PM, James H. H. Lampert wrote: >>> Noting that my connector tag is written using Tomcat 7 connector >>> syntax, is there a good example of how to code a ciphers clause >>> for that tag? >> >> Tomcat 8.5+ and 9.0+ can do it... but nobody has written a >> command-line tool around that capability. (I could have sworn such >> a tool existed already. I guess I'll write one.) > > Okay, it's in Tomcat 9, now. Grab Tomcat 9 trunk, build it ("ant > deploy"), then run: > > $ output/build/bin/ciphers.sh [cipherspec] > > where "cipherspec" is an OpenSSL-style cipher suite spec, like: > > $ output/build/bin/ciphers.sh 'DEFAULT' > > This gives you the JVM's current default, and dumps-out all of the > IANA-style cipher suite names. So if you want to add one cipher suite > to the default Java suites, just do this: > > $ output/build/bin/ciphers.sh 'DEFAULT' > > and then add this to the end: > > TLS_RSA_WITH_AES_256_CBC_SHA > > (Unless TLS_RSA_WITH_AES_256_CBC_SHA is already present in the list.) > > Note that the "DEFAULT" list has a bunch of junk you don't need. > Specifically, you can probably get rid of all of these things with no > ill effects, and your configuration will "look" simpler: > > $ ./bin/ciphers.sh '!PSK:!aNULL:!DSA:!SRP:!DSS:HIGH' A good read on the appropriate (openssl) cipher string that I use can be found here: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ Hynek explains the whys and don'ts and updates the string on a regular basis! HTH Peter > Hope that helps, > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb9NkdHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFisoA//bj9GFzlMaZdPYXHt > y2iQIToESUg6Wa8vU5lQscLDfqtXeAIawiXusILz/th1fCu1usy8HeC/5nBINXAQ > McbEUSRiq6YitPXDIwXqbOGZS76vxmheFPTst6gHCN6hNOYbFEbejK3cxX8s0Bbg > kXtqcrnnN+a+J5UZmFeB3tctQfwsVLyGcvcwzDRTjFCIjrD1CwdEd+Ckk740jCFU > HXgEewO6rVnxAx80hP2c9ztsHblNt0KFm4zMtWjxmHTigac1EEA1ZAi5P3nIJu5n > 7HIw0jVX3qZHamVHXWSPb7skEZY/wj7Kko8XmJFWS0bbwuaTQJ+Pr8ZJPT145/Tb > F0w6PqPqiR9sre7Yvy4v9y/QOqFjujEqMzkTNedRaBEItmzELPkYBBms2b2bkIVj > bMptV5FidCthzvJAnQ5efuiG9qYCuHajNEjQM4Mhu0t95yolmh4+yD2yxA4sS35W > YPxy24tgY9A2nNpJS+QSWtCzkQBJz+0Uxnw8y3AbW2oRkA649i+9+KppSAqCx7kH > QYUSwTD+7aETlVthfANEr5D/MbzJbflhTjXl/bZjuEc2p1tWPxZrqC+E8FwniMLL > NYwK4rMDrSZfrgY7mn6uPcTxzEIMTj/KvtaZCFY1GRAlAf16vNVlnCHQzMvlYKGW > gtqS2tF9DBurCs65qocxtWLAQwU= > =bEIh > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Enforcing server preference for cipher suites
Harish, > Am 10.10.2017 um 00:00 schrieb Harish Krishnan : > > Thanks for the response, Chris. > > Below are my answers in order. > To keep the response as short as possible, i have not included the ciphers > list in the connector - > > a) Tomcat 7.0.79 (will be updating to 7.0.82) > b) JRE 1.80_144 > c) Our connector configuration is below. > d) We are using NIO. > e) I am using a simple java client that makes TLS connection to our tomcat > on below port. I am capturing the SSL handshake. > The way i tested the client preference is: Lets take the same example i > gave in my first email i.e. clients preference is ABCDEF and the tomcat > servers preference is DEFABC with *useServerCipherSuitesOrder* set to true. > During the 1st handshake connection, "A" cipher suite was chosen. I removed > "A" from my tomcat connector, restarted the service, and did the connection > test again. > "B" was chosen during this 2nd handshake. Same test was continued and > observed that CDEF were chosen next in order. > I am expecting DEFABC as the order of preference as per the > *useServerCipherSuitesOrder* setting. > I believe that there is a misunderstanding. Your simple client does not seem to handle the situation correctly (even not at all). I think if you request cipher B you will get B. Please check with a ssl-tool like sslyze or testssl.sh. If your site is available on the internet, you could try ssllabs.com. The settings seem to be OK, unless I do not see an incorrect formatting on my phone. HTH, Peter > Let me know if i am missing anything or is my understanding is incorrect. > > id="orion.server.https" >acceptCount="100" >*useServerCipherSuitesOrder*="true" >ciphers="we have around 20 cipher suites listed..." >clientAuth="want" > > compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" >compression="on" >compressionMinSize="2048" >disableUploadTimeout="true" >enableLookups="false" >keystoreFile="keystore/xyz" >keystorePass="" >maxConnections="500" >maxHttpHeaderSize="8192" >maxKeepAliveRequests="500" >maxThreads="250" >minSpareThreads="25" >noCompressionUserAgents="gozilla, traviata" >port="8443" >processorCache="500" >protocol="org.apache.coyote.http11.Http11NioProtocol" >scheme="https" >secure="true" >server="Undefined" >sessionCacheSize="400" >SSLEnabled="true" >sslProtocol="TLS" >sslEnabledProtocols="TLSv1.1, TLSv1.2" >truststoreFile="keystore/xyz" >truststorePass="" >truststoreType="jks" >URIEncoding="UTF-8" /> > > > On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Harish, >> >>> On 10/9/17 12:31 PM, Harish Krishnan wrote: >>> Need your expert input here. Not sure what I am doing wrong, but I >>> cannot get this server preference cipher suites feature working. >>> >>> My setup: Latest tomcat 7.x build (which supports >>> useServerCipherSuitesOrder attribute) Latest Java 1.8 build. >>> >>> No matter what value I set to this attribute (true OR false OR >>> undefined which is by default), I always see the Clients preference >>> picked. As an example, if clients order is ABCDEF, and servers >>> order is DEFABC, no matter what value I set to this >>> useServerCipherSuitesOrder attribute, always the order selected is >>> ABC... >> >> What exact version of Tomcat are you using? >> What exact version of Java are you using? >> >> Please post your configuration, minus any secrets. >> >> Do you know if you are using the BIO, NIO, or APR connector? >> >> How are you determining client-preference? >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo >> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C >> qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK >> j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p >> MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s >> n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If >> xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0 >> RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR >> /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O >> GHAsqCD+8m3z/Oohi09Mi+pPebYAFuTHSERkK4s7rOHUinxzr1utx87s4g5m
Re: installing certificates
Graphical keystore tool - http://keystore-explorer.org/ It may make things easier On Mon, Oct 9, 2017 at 6:13 PM, Adam Pease wrote: > Hi Chris, > Many thanks for the quick response! There's a lot of new terminology (to > me) to all this and it's quite confusing I'm afraid. > > I tried Let's Encrypt just now but since I'm running Tomcat sites either > I'm not doing it right, or it doesn't know how to verify domains when they > don't answer on port 80. So I get "The server could not connect to the > client to verify the domain :: Timeout" > Following the process at "gethttpsforfree.com" resulted in two long hex > keys: one titled "Signed Certificate" and one titled "Intermediate > Certificate". I'm not sure what a "server certificate" is. Is that a > public/private key pair that I generated at the beginning of this process > with > > openssl genrsa 4096 > account.key > > or what I did at the beginning of the tomcat instructions > > $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA > > But that generates a .keystore file which is already a parameter to the > failing command. > > I really appreciate your help. > > all the best, > Adam > > > On 10/09/2017 02:00 PM, Christopher Schultz wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Adam, >> >> On 10/9/17 4:24 PM, Adam Pease wrote: >>> >>> Hi, I'm running Tomcat 8.5.23 on an AWS Ubuntu Linux 16.04 LTS >>> installation. I'm trying to follow the instructions at >>> https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html to get >>> HTTPS running under tomcat. >> >> >> Version mismatch. You want this guide: >> https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html >> >>> My site runs with a self-signed certificate. Now I'm trying to >>> install a proper certificate from > https://gethttpsforfree.com/ >> >> Try Let's Encrypt. I know nothing about "gethttpsforfree.com", but >> I've personally done Let's Encrypt. >> >>> After the rather lengthy process to generate the "Signed >>> Certificate" and "Intermediate Certificate" it appears I'm ready to >>> follow the instructions under the heading "Importing the >>> Certificate". >> >> >> BTW, LE is a single command to get a signed certificate. >> >>> My first question is whether there is a difference between the >>> certificates mentioned in >>> >>> - "import a so called Chain Certificate or Root Certificate into >>> your keystore" >>> >>> and >>> >>> - "After that you can proceed with importing your Certificate." >> >> >> You have a "server certificate" -- that's yours, and represents you. >> There is (usually) another certificate, called the "chain" or >> "intermediate" certificate, which represents the Certificate Authority >> who signed your certificate. >> >> When your server performs a TLS handshake with the client, it needs to >> present a "certificate chain" which includes your server certificate >> (the "leaf") and any certificates required to link the server cert to >> a root certificate which is stored within the client and already >> trusted (e.g. VeriSign, DigiCert, etc.). So your server needs to have >> multiple certificates available to send, and only one "belongs" to you. >> >>> I was able to execute the command: >>> >>> keytool -import -alias root -keystore >>> -trustcacerts -file >>> >>> using a single file that has the "Signed Certificate" and >>> "Intermediate Certificate" from gethttpsforfree. But then I get an >>> error from the next command >>> >>> ~$ keytool -import -alias tomcat -keystore .keystore -file >>> chained.pem Enter keystore password: keytool error: >>> java.lang.Exception: Certificate reply does not contain public key >>> for >> >> >> Which file is which? Looks like you imported the chain twice. >> >>> When I run >>> >>> ~$ keytool -list -v >>> >>> I see (in part) >>> >>> Alias name: tomcat Creation date: Oct 9, 2017 Entry type: >>> PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: >>> CN=Adam Pease >>> >>> I'm very new to certificates. Could someone point me in the right >>> direction? >> >> >> Java keystores are a nightmare... it's not your fault. ;) >> >> It looks like you didn't successfully import the CA's >> root/intermediate certificate. Can you reply with some more specifics? >> What files do you have from the CA, what keystore(s) do you have, and >> what are the exact commands you are running? You've left-out some >> important details from your post above. >> >> Here's what I have in my "Java Keystore Cheat Cheet": >> >> Create your server key and self-signed cert: >>> >>> $ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 4096 >>> -alias ${HOSTNAME} -keystore ${HOSTNAME}.jks >> >> >> Now, export your CSR: >> >>> $ keytool -certreq -sigalg SHA256withRSA -keystore ${HOSTNAME}.jks >>> >> Use that CSR to get your cert signed. >> >> Now, import the signed cert back into your keystore, starting with the >> root and/or intermediate cert and finishing with your server's cert: >> >>> $ keytool -import -alias [Au
Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 10/9/17 5:19 PM, Christopher Schultz wrote: > On 10/6/17 6:34 PM, James H. H. Lampert wrote: >> Noting that my connector tag is written using Tomcat 7 connector >> syntax, is there a good example of how to code a ciphers clause >> for that tag? > > Tomcat 8.5+ and 9.0+ can do it... but nobody has written a > command-line tool around that capability. (I could have sworn such > a tool existed already. I guess I'll write one.) Okay, it's in Tomcat 9, now. Grab Tomcat 9 trunk, build it ("ant deploy"), then run: $ output/build/bin/ciphers.sh [cipherspec] where "cipherspec" is an OpenSSL-style cipher suite spec, like: $ output/build/bin/ciphers.sh 'DEFAULT' This gives you the JVM's current default, and dumps-out all of the IANA-style cipher suite names. So if you want to add one cipher suite to the default Java suites, just do this: $ output/build/bin/ciphers.sh 'DEFAULT' and then add this to the end: TLS_RSA_WITH_AES_256_CBC_SHA (Unless TLS_RSA_WITH_AES_256_CBC_SHA is already present in the list.) Note that the "DEFAULT" list has a bunch of junk you don't need. Specifically, you can probably get rid of all of these things with no ill effects, and your configuration will "look" simpler: $ ./bin/ciphers.sh '!PSK:!aNULL:!DSA:!SRP:!DSS:HIGH' Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb9NkdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFisoA//bj9GFzlMaZdPYXHt y2iQIToESUg6Wa8vU5lQscLDfqtXeAIawiXusILz/th1fCu1usy8HeC/5nBINXAQ McbEUSRiq6YitPXDIwXqbOGZS76vxmheFPTst6gHCN6hNOYbFEbejK3cxX8s0Bbg kXtqcrnnN+a+J5UZmFeB3tctQfwsVLyGcvcwzDRTjFCIjrD1CwdEd+Ckk740jCFU HXgEewO6rVnxAx80hP2c9ztsHblNt0KFm4zMtWjxmHTigac1EEA1ZAi5P3nIJu5n 7HIw0jVX3qZHamVHXWSPb7skEZY/wj7Kko8XmJFWS0bbwuaTQJ+Pr8ZJPT145/Tb F0w6PqPqiR9sre7Yvy4v9y/QOqFjujEqMzkTNedRaBEItmzELPkYBBms2b2bkIVj bMptV5FidCthzvJAnQ5efuiG9qYCuHajNEjQM4Mhu0t95yolmh4+yD2yxA4sS35W YPxy24tgY9A2nNpJS+QSWtCzkQBJz+0Uxnw8y3AbW2oRkA649i+9+KppSAqCx7kH QYUSwTD+7aETlVthfANEr5D/MbzJbflhTjXl/bZjuEc2p1tWPxZrqC+E8FwniMLL NYwK4rMDrSZfrgY7mn6uPcTxzEIMTj/KvtaZCFY1GRAlAf16vNVlnCHQzMvlYKGW gtqS2tF9DBurCs65qocxtWLAQwU= =bEIh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: installing certificates
Hi Chris, Many thanks for the quick response! There's a lot of new terminology (to me) to all this and it's quite confusing I'm afraid. I tried Let's Encrypt just now but since I'm running Tomcat sites either I'm not doing it right, or it doesn't know how to verify domains when they don't answer on port 80. So I get "The server could not connect to the client to verify the domain :: Timeout" Following the process at "gethttpsforfree.com" resulted in two long hex keys: one titled "Signed Certificate" and one titled "Intermediate Certificate". I'm not sure what a "server certificate" is. Is that a public/private key pair that I generated at the beginning of this process with openssl genrsa 4096 > account.key or what I did at the beginning of the tomcat instructions $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA But that generates a .keystore file which is already a parameter to the failing command. I really appreciate your help. all the best, Adam On 10/09/2017 02:00 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adam, On 10/9/17 4:24 PM, Adam Pease wrote: Hi, I'm running Tomcat 8.5.23 on an AWS Ubuntu Linux 16.04 LTS installation. I'm trying to follow the instructions at https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html to get HTTPS running under tomcat. Version mismatch. You want this guide: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html My site runs with a self-signed certificate. Now I'm trying to install a proper certificate from > https://gethttpsforfree.com/ Try Let's Encrypt. I know nothing about "gethttpsforfree.com", but I've personally done Let's Encrypt. After the rather lengthy process to generate the "Signed Certificate" and "Intermediate Certificate" it appears I'm ready to follow the instructions under the heading "Importing the Certificate". BTW, LE is a single command to get a signed certificate. My first question is whether there is a difference between the certificates mentioned in - "import a so called Chain Certificate or Root Certificate into your keystore" and - "After that you can proceed with importing your Certificate." You have a "server certificate" -- that's yours, and represents you. There is (usually) another certificate, called the "chain" or "intermediate" certificate, which represents the Certificate Authority who signed your certificate. When your server performs a TLS handshake with the client, it needs to present a "certificate chain" which includes your server certificate (the "leaf") and any certificates required to link the server cert to a root certificate which is stored within the client and already trusted (e.g. VeriSign, DigiCert, etc.). So your server needs to have multiple certificates available to send, and only one "belongs" to you. I was able to execute the command: keytool -import -alias root -keystore -trustcacerts -file using a single file that has the "Signed Certificate" and "Intermediate Certificate" from gethttpsforfree. But then I get an error from the next command ~$ keytool -import -alias tomcat -keystore .keystore -file chained.pem Enter keystore password: keytool error: java.lang.Exception: Certificate reply does not contain public key for Which file is which? Looks like you imported the chain twice. When I run ~$ keytool -list -v I see (in part) Alias name: tomcat Creation date: Oct 9, 2017 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Adam Pease I'm very new to certificates. Could someone point me in the right direction? Java keystores are a nightmare... it's not your fault. ;) It looks like you didn't successfully import the CA's root/intermediate certificate. Can you reply with some more specifics? What files do you have from the CA, what keystore(s) do you have, and what are the exact commands you are running? You've left-out some important details from your post above. Here's what I have in my "Java Keystore Cheat Cheet": Create your server key and self-signed cert: $ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 4096 -alias ${HOSTNAME} -keystore ${HOSTNAME}.jks Now, export your CSR: $ keytool -certreq -sigalg SHA256withRSA -keystore ${HOSTNAME}.jks Use that CSR to get your cert signed. Now, import the signed cert back into your keystore, starting with the root and/or intermediate cert and finishing with your server's cert: $ keytool -import -alias [Authority.CA] -trustcacerts -file [authority's CA cert] -keystore ${HOSTNAME}.jks (^ if necessary) $ keytool -import -alias [Authority.intermediate] -trustcacerts -file [authority's intermediate cert] -keystore ${HOSTNAME}.jks $ keytool -import -alias ${HOSTNAME} -file ${HOSTNAME}.crt -keystore ${HOSTNAME}.jks Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe
Re: Enforcing server preference for cipher suites
Thanks for the response, Chris. Below are my answers in order. To keep the response as short as possible, i have not included the ciphers list in the connector - a) Tomcat 7.0.79 (will be updating to 7.0.82) b) JRE 1.80_144 c) Our connector configuration is below. d) We are using NIO. e) I am using a simple java client that makes TLS connection to our tomcat on below port. I am capturing the SSL handshake. The way i tested the client preference is: Lets take the same example i gave in my first email i.e. clients preference is ABCDEF and the tomcat servers preference is DEFABC with *useServerCipherSuitesOrder* set to true. During the 1st handshake connection, "A" cipher suite was chosen. I removed "A" from my tomcat connector, restarted the service, and did the connection test again. "B" was chosen during this 2nd handshake. Same test was continued and observed that CDEF were chosen next in order. I am expecting DEFABC as the order of preference as per the *useServerCipherSuitesOrder* setting. Let me know if i am missing anything or is my understanding is incorrect. On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Harish, > > On 10/9/17 12:31 PM, Harish Krishnan wrote: > > Need your expert input here. Not sure what I am doing wrong, but I > > cannot get this server preference cipher suites feature working. > > > > My setup: Latest tomcat 7.x build (which supports > > useServerCipherSuitesOrder attribute) Latest Java 1.8 build. > > > > No matter what value I set to this attribute (true OR false OR > > undefined which is by default), I always see the Clients preference > > picked. As an example, if clients order is ABCDEF, and servers > > order is DEFABC, no matter what value I set to this > > useServerCipherSuitesOrder attribute, always the order selected is > > ABC... > > What exact version of Tomcat are you using? > What exact version of Java are you using? > > Please post your configuration, minus any secrets. > > Do you know if you are using the BIO, NIO, or APR connector? > > How are you determining client-preference? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C > qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK > j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p > MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s > n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If > xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0 > RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR > /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O > GHAsqCD+8m3z/Oohi09Mi+pPebYAFuTHSERkK4s7rOHUinxzr1utx87s4g5m995R > qU97BpOc33+ouOS5cKx4t+xrGaZr5LfNb8lXEZluNSDmU7Lnb7qA/yrr6prXbniG > 5wv2zVlFit/8rKQInCEH0c/c2cD15RaU6iBujhfRpWYl1XWmOkWYQCzZ2xlLy/Hg > lPIZuxLUk5GBnA/vV8qtLIfK7cc= > =SuWg > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat SSL issue
On 10/9/2017 10:01 AM, John Ellis wrote: I posted questions about this a couple of weeks ago I think it was. I have been trying to get Tomcat running on a secure port with a valid SSL certificate. We finally got version 9.0.0.M20 setup successfully on port 9443 and I can go to that IP:port and get a Tomcat webpage but when I go through all the steps using the keytool commands to submit a certificate (we use Cacert.org) and try to plug that certificate into the mix it doesn’t work. I still get an error message telling me that I will have to create an exception to go to that IP address and port. Last Friday I even deleted the certificate and all the keystore file, etc. and got the same exact error. So it appears that Tomcat is not seeing the certificate at all since I get the same error about having to add an exception whether or not I have a valid certificate in place on the server. The lines we added to the server.xml file to get the secure port working are- John Ellis Hi, John- Is it a browser that's displaying the error message and requesting that you create an exception to continue? If so, have you looked at the additional information to determine what problems the browser has detected with the certificate? -Terence Bandoian http://www.tmbsw.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 10/6/17 6:34 PM, James H. H. Lampert wrote: > On 10/6/17, 6:58 AM, Mark Thomas (Tomcat List) wrote: > >> It might help to think of it like this: >> >> There are the ciphers that a JVM supports. The JVM only enables >> sub-set of the supported ciphers are enabled by default. Tomcat >> with a default configuration only uses a sub-set of the ciphers >> that the JVM enables by default. . . . It looks like you have an >> incompatible set of ciphers configured. >> >> As per Chris's previous email, it looks like RSA_AES_256_CBC_SHA >> is the least worse option. The Java name for this is: >> TLS_RSA_WITH_AES_256_CBC_SHA > > I should have tried this DAYS ago. There is also a Tomcat 7 server > installed on the Google Cloud server. With no apparent differences > in the Java list of available and "enabled-by-default" ciphers > between the two boxes, it's clear that the biggest single > difference that I'm actually able to do anything about is which > Tomcat server is running on 443. > > So with both Tomcat servers shut down, I switched Tomcat 7 over to > port 443, brought it up, and tried connecting to it from the same > program as before. > > This time, I got a 404. Not the least bit surprising, since the > webapp context isn't actually installed on the Tomcat 7 server. > > Incidentally, I also tried running the ssllabs.com test on the > Tomcat 7 server. The results weren't very meaningful: it only > listed the ECDHE suites, but then again, it only listed the ECDHE > suites when I tried it on one of our other Tomcat 7 servers. > >> Tomcat with a default configuration only uses a sub-set of the >> ciphers that the JVM enables by default. > > So is there a way, short of downloading and recompiling Tomcat > myself, to control what's in that default subset of a default > subset? Nope. You can't change the JVM (well, you CAN but it's not worth it) and you can't change Tomcat's further-restricted list of cipher suites. But it's got nearly everything you'd actually want in there, and it's even got some stuff you might actually NOT want in there, depending upon your level of paranoia. > Or failing that, is there a way, in my connector tag, to specify > "Use TLS_RSA_WITH_AES_256_CBC_SHA in addition to all the suites > Tomcat 8.5 uses by default"? No. > Or do I need to list all the Tomcat 8.5 defaults in a "ciphers" > clause, along with the TLS_RSA_WITH_AES_256_CBC_SHA? You need to list everything. > Noting that my connector tag is written using Tomcat 7 connector > syntax, is there a good example of how to code a ciphers clause for > that tag? Tomcat 8.5+ and 9.0+ can do it... but nobody has written a command-line tool around that capability. (I could have sworn such a tool existed already. I guess I'll write one.) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5/AdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh7nA/+Nq5pXhaL9++l2y8b LSVfaoy5PamsIFvn5paEchot2XfvoE4TXMWb3e5EmVPPk89QLZKn/jMzOukKs/9S 7g4QVtngxEfi9W48poj45abfwMk+Rh2Na4fNIwMLjNFFVYLH1AeuO/hvDk1/Zf0z mIgqa85OlMuwnpWF3AqWI/KEOi9d9PNOIm2TT8c+lI6WyR99M+FTWtt10Zlv/IFG 7JeSEbKURxkacOlwe6aR7Paa7Wt2LcUldYcAhmYwKJPvHJaYcs1ZdbvPsx2h8j2E eGBftxjl9+2cx0+5+tkQtl0nAotZmqoX3SsIgeDJWwUdUI/7iLkJMt/d8A1gdGgR AaCZgW09fn8MpzAaqqOz+FdqpNcldBsiut4o4gv+bUhDQClijvpz/LDKW02eJhEi 6/1U+Eqe5MyXj+zn02Am+z7uoyyU8H1F3QUEN1+OsKH3/AsOCZBwkqeBvig3a8Mb XXPCOUroDqW4zhvAd8/mk0tuoo2OZ+O3rd/VuZecDU7uuhclvgp7+orhsIwrDL0o jynVbIm0k2VPHPwDQRAL9scdXc0BGFih8D6tP9JBmIgVHQhHVoqbJkwfo+Zrer/L cLP7R2iBcg2d2EqYxlMXYmgVf4jnVcGTfn1n2V9Hc6YYhcLIxTF3s37xln2StERB 69veYEnl/qoqo/7IcKp5YrE+kP8= =w1+P -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat APR / openssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jennifer, On 10/9/17 10:22 AM, Wang, Jennifer wrote: > I am looking openssl's SSL_CTX_set_psk_server_callback in APR & > did not found it. Just wonder if there is way to set it. We need to > use TLS-PSK. I don't believe there is an easy way to use Tomcat with a PSK-based TLS cipher suite. Why not use RSA with a client-certificate if you want two-way authentication? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5SQdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgwwQ/+JUc5+GjSPj5geBUh QEGLd5+7wJSb48rZ1dLXrMPDkHms9js/osGnwLKF6R0ypJHkIcHnq380ZpMREPgZ YVHTEcoWSoeUAmN+xavJAaaTyiRtE3al3IuHMegiEq/ld95EaJ1kKAxup8kH/rIs s46Z3fpaho6auxPNXtAxYbCQ/SOjgHmC2v6ZJsJKJRrI/QotEWlOISaxgo4oJk5X DVfzEaIplFx74WR+jpXyQJFGI19BI93bCSPgy4Niqk9wJb3Wv3XuEoolyoZkL5yC QuaoUAIqFGuNqRR+WbjYH7kNjRv+HtmY+fhZCk2YnmUDytg2xj+MPOXIDdKACJQv Nlns4KhLU2AtXTTluO+nLEfbl9r9OtTMuVqDl0+Sbl2gest2JipY4Zgm7h7+r83h a77Ct0EDGomDhUkqrvfvRE6so0KO5uga9sj8kGulmA5EiPK3/tOrseJ1ZDMnvCfH 8+ev/oHqjAjFOojCX5u+omZ4RNsx+Va7/RMJCbfUcpB4HjrX1MDIIlsmq2egi6Rg DJA3g1+GkwCS2Ul2EehuZmo5Lez3oamIDksJ04GyMUbyx5QBS4JJqGR5KGIE9+nM M51t932+ioFxgEndTYBUedftiDGvEGBH8Wy7yUhpXtrPmg5SF6Izih7n9OyBlATr X4SHzGl7BNeWxRvf33hbH1T+ToE= =nDIg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Enforcing server preference for cipher suites
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Harish, On 10/9/17 12:31 PM, Harish Krishnan wrote: > Need your expert input here. Not sure what I am doing wrong, but I > cannot get this server preference cipher suites feature working. > > My setup: Latest tomcat 7.x build (which supports > useServerCipherSuitesOrder attribute) Latest Java 1.8 build. > > No matter what value I set to this attribute (true OR false OR > undefined which is by default), I always see the Clients preference > picked. As an example, if clients order is ABCDEF, and servers > order is DEFABC, no matter what value I set to this > useServerCipherSuitesOrder attribute, always the order selected is > ABC... What exact version of Tomcat are you using? What exact version of Java are you using? Please post your configuration, minus any secrets. Do you know if you are using the BIO, NIO, or APR connector? How are you determining client-preference? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0 RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O GHAsqCD+8m3z/Oohi09Mi+pPebYAFuTHSERkK4s7rOHUinxzr1utx87s4g5m995R qU97BpOc33+ouOS5cKx4t+xrGaZr5LfNb8lXEZluNSDmU7Lnb7qA/yrr6prXbniG 5wv2zVlFit/8rKQInCEH0c/c2cD15RaU6iBujhfRpWYl1XWmOkWYQCzZ2xlLy/Hg lPIZuxLUk5GBnA/vV8qtLIfK7cc= =SuWg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: installing certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adam, On 10/9/17 4:24 PM, Adam Pease wrote: > Hi, I'm running Tomcat 8.5.23 on an AWS Ubuntu Linux 16.04 LTS > installation. I'm trying to follow the instructions at > https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html to get > HTTPS running under tomcat. Version mismatch. You want this guide: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html > My site runs with a self-signed certificate. Now I'm trying to > install a proper certificate from > https://gethttpsforfree.com/ Try Let's Encrypt. I know nothing about "gethttpsforfree.com", but I've personally done Let's Encrypt. > After the rather lengthy process to generate the "Signed > Certificate" and "Intermediate Certificate" it appears I'm ready to > follow the instructions under the heading "Importing the > Certificate". BTW, LE is a single command to get a signed certificate. > My first question is whether there is a difference between the > certificates mentioned in > > - "import a so called Chain Certificate or Root Certificate into > your keystore" > > and > > - "After that you can proceed with importing your Certificate." You have a "server certificate" -- that's yours, and represents you. There is (usually) another certificate, called the "chain" or "intermediate" certificate, which represents the Certificate Authority who signed your certificate. When your server performs a TLS handshake with the client, it needs to present a "certificate chain" which includes your server certificate (the "leaf") and any certificates required to link the server cert to a root certificate which is stored within the client and already trusted (e.g. VeriSign, DigiCert, etc.). So your server needs to have multiple certificates available to send, and only one "belongs" to you. > I was able to execute the command: > > keytool -import -alias root -keystore > -trustcacerts -file > > using a single file that has the "Signed Certificate" and > "Intermediate Certificate" from gethttpsforfree. But then I get an > error from the next command > > ~$ keytool -import -alias tomcat -keystore .keystore -file > chained.pem Enter keystore password: keytool error: > java.lang.Exception: Certificate reply does not contain public key > for Which file is which? Looks like you imported the chain twice. > When I run > > ~$ keytool -list -v > > I see (in part) > > Alias name: tomcat Creation date: Oct 9, 2017 Entry type: > PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: > CN=Adam Pease > > I'm very new to certificates. Could someone point me in the right > direction? Java keystores are a nightmare... it's not your fault. ;) It looks like you didn't successfully import the CA's root/intermediate certificate. Can you reply with some more specifics? What files do you have from the CA, what keystore(s) do you have, and what are the exact commands you are running? You've left-out some important details from your post above. Here's what I have in my "Java Keystore Cheat Cheet": Create your server key and self-signed cert: > $ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 4096 > -alias ${HOSTNAME} -keystore ${HOSTNAME}.jks Now, export your CSR: > $ keytool -certreq -sigalg SHA256withRSA -keystore ${HOSTNAME}.jks > Use that CSR to get your cert signed. Now, import the signed cert back into your keystore, starting with the root and/or intermediate cert and finishing with your server's cert: > $ keytool -import -alias [Authority.CA] -trustcacerts -file > [authority's CA cert] -keystore ${HOSTNAME}.jks (^ if necessary) > $ keytool -import -alias [Authority.intermediate] -trustcacerts > -file [authority's intermediate cert] -keystore ${HOSTNAME}.jks $ > keytool -import -alias ${HOSTNAME} -file ${HOSTNAME}.crt -keystore > ${HOSTNAME}.jks Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb41sdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjanw//ZLdT9HeenslFlWAz 6Bn76MPvXVnBAQ2NqK0ufp26p70KpOpYb+3+4OxxVIvZBo7DAFwS3Q6EY/bntij7 eyH8m/7GH3ZwIiNrwyFpRbIVQh9Jft5Q+Cmf9ARvUespfJZ0MjxvPKXfxGvt6IAI ojyexYNlQ4P2kL2I1CCcYwQtwu838nFlZOHIw+11BlPl2Opm5GLcXVgVUtIoNS4n JfgS7818t45mUeH1kPfTYwGaI/3KNRJS2OFp0A7dSr3qamR9Xpve0mYG2G4XH9BI PGbGgXKQhaAAsw4rMtuOxp1ukxsfRW3VQItrTTg5F0juR2BkTZOsxzJMlJrKcvrG 3p+BmH9rTEUE6EctyLOu0b20DzeM5FHtBGxNOSuPBuQpFq28Nzgvjm5QQPosyEZG uESgDOpsJ/qVLgBZeEd3HlLJGF2UQQryW5gAWhUVn3gk3/IEyrmhfWipqw1IBhgP uJ6g8rowShwIOz/9b7ZLwPlyl0r+diTtMXf8qT5+DpsS7SMHSJ47/Kcba2wQxoON TQnerLohHKJcKg140liZvpYI7bh63nendNsUdMTOKcyAKLhIw0deDkeHDTx/DCks 0QJAkW2SvjeIBeRN/3+xrsvYD/XvKr/xCuUGIdsHCDotrFsF+lk7SwecFhU+8I+W RoezW/Qt6SSgu5iyyfuioT/na64= =3ECo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For addition
installing certificates
Hi, I'm running Tomcat 8.5.23 on an AWS Ubuntu Linux 16.04 LTS installation. I'm trying to follow the instructions at https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html to get HTTPS running under tomcat. My site runs with a self-signed certificate. Now I'm trying to install a proper certificate from https://gethttpsforfree.com/ . After the rather lengthy process to generate the "Signed Certificate" and "Intermediate Certificate" it appears I'm ready to follow the instructions under the heading "Importing the Certificate". My first question is whether there is a difference between the certificates mentioned in - "import a so called Chain Certificate or Root Certificate into your keystore" and - "After that you can proceed with importing your Certificate." I was able to execute the command: keytool -import -alias root -keystore -trustcacerts -file using a single file that has the "Signed Certificate" and "Intermediate Certificate" from gethttpsforfree. But then I get an error from the next command ~$ keytool -import -alias tomcat -keystore .keystore -file chained.pem Enter keystore password: keytool error: java.lang.Exception: Certificate reply does not contain public key for When I run ~$ keytool -list -v I see (in part) Alias name: tomcat Creation date: Oct 9, 2017 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Adam Pease I'm very new to certificates. Could someone point me in the right direction? all the best, Adam -- --- Adam Pease http://www.ontologyportal.org http://www.adampease.org @apease_ontology on Twitter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat SSL issue
On 09/10/17 18:48, John Ellis wrote: > > > John Ellis > > 405.285.2500 office > > > > > http://biz-e.io > > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, October 9, 2017 12:33 PM > To: Tomcat Users List > Subject: Re: Tomcat SSL issue > > On 09/10/17 16:01, John Ellis wrote: >> I posted questions about this a couple of weeks ago I think it was. I >> have been trying to get Tomcat running on a secure port with a valid >> SSL certificate. We finally got version 9.0.0.M20 setup successfully >> on port >> 9443 and I can go to that IP:port and get a Tomcat webpage but when I >> go through all the steps using the keytool commands to submit a >> certificate (we use Cacert.org) and try to plug that certificate into >> the mix it doesn’t work. I still get an error message telling me that >> I will have to create an exception to go to that IP address and port. >> Last Friday I even deleted the certificate and all the keystore file, >> etc. and got the same exact error. So it appears that Tomcat is not >> seeing the certificate at all since I get the same error about having >> to add an exception whether or not I have a valid certificate in place on > the server. > > If you get that error then Tomcat has the certificate but the client doesn't > trust it. You need to check if: > > - Tomcat is supplying the full certificate chain > - If the client trusts the issuing CA > > Mark > > OK Mark can you explain to me why we get the same exact error condition with > no certificate in place at all as when we provide a certificate? That isn't possible. If no certificate is provided, Tomcat won't even open the port. I think you are going to need to provide more details about exactly how things are configured, how you are testing it and the log messages Tomcat provides when started (note you have to restart Tomcat after changing the connector configuration - or anything in server.xml) Mark > I'm not arguing that just doesn't make any sense to me but as I said before > I am not a programmer or developer or anything like that. > Thanks, > John > >> >> The lines we added to the server.xml file to get the secure port >> working >> are- >> >> >> >> > >> maxThreads="150" scheme="https" secure="true" >> >> clientAuth="false" sslProtocol="TLS" >> >> >> > keystoreFile="/home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jk > s" >> >> keystorePass="changeit" /> >> >> >> >> John Ellis >> >> >> >> 405.285.2500 office >> >> >> >> United States >> >> bize-logo-rgb-original_Ryan_Revised_portal size >> cid:image002.jpg@01CECFDA.65B42CD0 >> >> >> >> http://biz-e.io >> >> >> > > > - > 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat SSL issue
John Ellis 405.285.2500 office http://biz-e.io -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, October 9, 2017 12:33 PM To: Tomcat Users List Subject: Re: Tomcat SSL issue On 09/10/17 16:01, John Ellis wrote: > I posted questions about this a couple of weeks ago I think it was. I > have been trying to get Tomcat running on a secure port with a valid > SSL certificate. We finally got version 9.0.0.M20 setup successfully > on port > 9443 and I can go to that IP:port and get a Tomcat webpage but when I > go through all the steps using the keytool commands to submit a > certificate (we use Cacert.org) and try to plug that certificate into > the mix it doesnt work. I still get an error message telling me that > I will have to create an exception to go to that IP address and port. > Last Friday I even deleted the certificate and all the keystore file, > etc. and got the same exact error. So it appears that Tomcat is not > seeing the certificate at all since I get the same error about having > to add an exception whether or not I have a valid certificate in place on the server. If you get that error then Tomcat has the certificate but the client doesn't trust it. You need to check if: - Tomcat is supplying the full certificate chain - If the client trusts the issuing CA Mark OK Mark can you explain to me why we get the same exact error condition with no certificate in place at all as when we provide a certificate? I'm not arguing that just doesn't make any sense to me but as I said before I am not a programmer or developer or anything like that. Thanks, John > > The lines we added to the server.xml file to get the secure port > working > are- > > > > > maxThreads="150" scheme="https" secure="true" > > clientAuth="false" sslProtocol="TLS" > > > keystoreFile="/home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jk s" > > keystorePass="changeit" /> > > > > John Ellis > > > > 405.285.2500 office > > > > United States > > bize-logo-rgb-original_Ryan_Revised_portal size > cid:image002.jpg@01CECFDA.65B42CD0 > > > > http://biz-e.io > > > - 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: Tomcat SSL issue
On 09/10/17 16:01, John Ellis wrote: > I posted questions about this a couple of weeks ago I think it was. I > have been trying to get Tomcat running on a secure port with a valid SSL > certificate. We finally got version 9.0.0.M20 setup successfully on port > 9443 and I can go to that IP:port and get a Tomcat webpage but when I go > through all the steps using the keytool commands to submit a certificate > (we use Cacert.org) and try to plug that certificate into the mix it > doesn’t work. I still get an error message telling me that I will have > to create an exception to go to that IP address and port. Last Friday I > even deleted the certificate and all the keystore file, etc. and got the > same exact error. So it appears that Tomcat is not seeing the > certificate at all since I get the same error about having to add an > exception whether or not I have a valid certificate in place on the server. If you get that error then Tomcat has the certificate but the client doesn't trust it. You need to check if: - Tomcat is supplying the full certificate chain - If the client trusts the issuing CA Mark > > The lines we added to the server.xml file to get the secure port working > are- > > > > > maxThreads="150" scheme="https" secure="true" > > clientAuth="false" sslProtocol="TLS" > > > keystoreFile="/home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jks" > > keystorePass="changeit" /> > > > > John Ellis > > > > 405.285.2500 office > > > > United States > > bize-logo-rgb-original_Ryan_Revised_portal size > cid:image002.jpg@01CECFDA.65B42CD0 > > > > http://biz-e.io > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UpgradedServletInputStream.read EOF
On 09/10/17 15:51, Sergey Mashkov wrote: > Hi > > Could anybody explain me why UpgradedServletInputStream does fail with > EOFException in non-blocking mode instead of returning -1 ? I'm not sure why an EOFException is happening. My guess is multiple calls to read() without calling isReady() between them. Once an InputStream is in non-blocking mode, every call to read() should be preceded by a call to isReady(). Only if isReady() returns true should there be a read. If isReady() returns false you need to wait for onDataAvailable() or onAllDataRead(). If you try reading before onDataAvailable() fires you should see an ISE. > Where can I > find exact Servlet API specification about this async API behaviour? Section 3.7 of the Servlet spec + the relevant Javadoc. It is also possible some of the fine detail was discussed on the EG mailing list. Mark > > java.io.EOFException > at > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1159) > at > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1130) > at > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1067) > at > org.apache.coyote.http11.upgrade.UpgradeServletInputStream.read(UpgradeServletInputStream.java:150) > at java.io.InputStream.read(InputStream.java:101) > at io.ktor.servlet.Reader.loop(ServletReader.kt:38) > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Enforcing server preference for cipher suites
Hi All, Need your expert input here. Not sure what I am doing wrong, but I cannot get this server preference cipher suites feature working. My setup: Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute) Latest Java 1.8 build. No matter what value I set to this attribute (true OR false OR undefined which is by default), I always see the Clients preference picked. As an example, if clients order is ABCDEF, and servers order is DEFABC, no matter what value I set to this useServerCipherSuitesOrder attribute, always the order selected is ABC... Regard Harish Krishnan Sent from my iPhone - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat SSL issue
John Ellis 405.285.2500 office http://biz-e.io -Original Message- From: Jose María Zaragoza [mailto:demablo...@gmail.com] Sent: Monday, October 9, 2017 11:25 AM To: Tomcat Users List Subject: Re: Tomcat SSL issue 2017-10-09 17:01 GMT+02:00 John Ellis : > I posted questions about this a couple of weeks ago I think it was. I > have been trying to get Tomcat running on a secure port with a valid > SSL certificate. We finally got version 9.0.0.M20 setup successfully > on port > 9443 and I can go to that IP:port and get a Tomcat webpage but when I > go through all the steps using the keytool commands to submit a > certificate (we use Cacert.org) and try to plug that certificate into > the mix it doesn’t work. I still get an error message telling me that > I will have to create an exception to go to that IP address and port. > Last Friday I even deleted the certificate and all the keystore file, > etc. and got the same exact error. So it appears that Tomcat is not > seeing the certificate at all since I get the same error about having > to add an exception whether or not I have a valid certificate in place on the > server. > > The lines we added to the server.xml file to get the secure port > working > are- > > > > > maxThreads="150" scheme="https" secure="true" > > clientAuth="false" sslProtocol="TLS" > > keystoreFile="/home/tomcat9.0. > 0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jks" > > keystorePass="changeit" /> > Maybe you should use element, do you ? Read: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_SSLHostConfig Each secure connector must define at least one *SSLHostConfig* I thought that was only for version 9? However I believe we did try that and got the same result last week. > > > John Ellis > > > > 405.285.2500 office > > > > [image: United States] > > [image: bize-logo-rgb-original_Ryan_Revised_portal size][image: > cid:image002.jpg@01CECFDA.65B42CD0] > > > > http://biz-e.io > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat SSL issue
2017-10-09 17:01 GMT+02:00 John Ellis : > I posted questions about this a couple of weeks ago I think it was. I have > been trying to get Tomcat running on a secure port with a valid SSL > certificate. We finally got version 9.0.0.M20 setup successfully on port > 9443 and I can go to that IP:port and get a Tomcat webpage but when I go > through all the steps using the keytool commands to submit a certificate > (we use Cacert.org) and try to plug that certificate into the mix it > doesn’t work. I still get an error message telling me that I will have to > create an exception to go to that IP address and port. Last Friday I even > deleted the certificate and all the keystore file, etc. and got the same > exact error. So it appears that Tomcat is not seeing the certificate at all > since I get the same error about having to add an exception whether or not > I have a valid certificate in place on the server. > > The lines we added to the server.xml file to get the secure port working > are- > > > > > maxThreads="150" scheme="https" secure="true" > > clientAuth="false" sslProtocol="TLS" > > keystoreFile="/home/tomcat9.0. > 0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jks" > > keystorePass="changeit" /> > Maybe you should use element, do you ? Read: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_SSLHostConfig Each secure connector must define at least one *SSLHostConfig* > > > John Ellis > > > > 405.285.2500 office > > > > [image: United States] > > [image: bize-logo-rgb-original_Ryan_Revised_portal size][image: > cid:image002.jpg@01CECFDA.65B42CD0] > > > > http://biz-e.io > > >
Tomcat SSL issue
I posted questions about this a couple of weeks ago I think it was. I have been trying to get Tomcat running on a secure port with a valid SSL certificate. We finally got version 9.0.0.M20 setup successfully on port 9443 and I can go to that IP:port and get a Tomcat webpage but when I go through all the steps using the keytool commands to submit a certificate (we use Cacert.org) and try to plug that certificate into the mix it doesn't work. I still get an error message telling me that I will have to create an exception to go to that IP address and port. Last Friday I even deleted the certificate and all the keystore file, etc. and got the same exact error. So it appears that Tomcat is not seeing the certificate at all since I get the same error about having to add an exception whether or not I have a valid certificate in place on the server. The lines we added to the server.xml file to get the secure port working are- John Ellis 405.285.2500 office http://biz-e.io
UpgradedServletInputStream.read EOF
Hi Could anybody explain me why UpgradedServletInputStream does fail with EOFException in non-blocking mode instead of returning -1 ? Where can I find exact Servlet API specification about this async API behaviour? java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1159) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1130) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1067) at org.apache.coyote.http11.upgrade.UpgradeServletInputStream.read(UpgradeServletInputStream.java:150) at java.io.InputStream.read(InputStream.java:101) at io.ktor.servlet.Reader.loop(ServletReader.kt:38)
Tomcat APR / openssl
NONCONFIDENTIAL // EXTERNAL Hi I am looking openssl's SSL_CTX_set_psk_server_callback in APR & did not found it. Just wonder if there is way to set it. We need to use TLS-PSK. Thanks! Jennifer
Tomcat APR / openssl
NONCONFIDENTIAL // EXTERNAL Hi I am looking openssl's SSL_CTX_set_psk_server_callback in APR & did not found it. Just wonder if there is way to set it. We need to use TLS-PSK. Thanks! Jennifer
Re: ISAPI and IIS 10 Logging Issue
On 06/10/17 22:42, Mark Thomas wrote: > On 06/10/17 16:27, Mark Thomas wrote: >>> On 10.05.2017 8:54, Thomas, Michael wrote: >>> >>> Unfortunately I am not getting much traction with Microsoft. From the IIS >>> forum, it looks like they are pointing the finger in the direction of the >>> "third-party" that is writing the module. >> >> That is consistent with my experience with MS support. Looks like you'll need to go back to MS support. > I'll look at the IIS API docs next week and see if there is something > different we should be doing in IIS 10 compared to 8.5 and earlier. I can't find anything in the IIS API docs that indicates that this has changed in IIS 10 / Windows Server 2016. I've added some debug logging and I see the following: HttpFilterProc gets called with SF_NOTIFY_LOG The JK code sees the original path [/jakarta/isapi_redirect.dll] and replaces it with the correct one - [/examples/] in my case. The JK code sees the original [] query string and replaces it with the correct one - [foo=bar] in my case. Given that this works as expected in Windows Server 2012 with exactly the same code AND that no API changes (that I can find) are documented for IIS 10 AND that debug logging shows that the expected calls are taking place AND the IIS log is not updated, all the evidence we have at the moment points squarely to an IIS 10 bug (or possibly an undocumented IIS 10 API). Sorry it wasn't better news. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org