Re: installing certificates

2017-10-09 Thread Alex O'Ree
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:
>>

Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

2017-10-09 Thread 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'

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

2017-10-09 Thread Adam Pease

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/


Re: Enforcing server preference for cipher suites

2017-10-09 Thread 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.

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

2017-10-09 Thread Terence M. Bandoian

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.

2017-10-09 Thread Christopher Schultz
-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

2017-10-09 Thread Christopher Schultz
-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

2017-10-09 Thread Christopher Schultz
-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

2017-10-09 Thread Christopher Schultz
-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 

installing certificates

2017-10-09 Thread Adam Pease

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

2017-10-09 Thread Mark Thomas
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

2017-10-09 Thread John Ellis


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? 
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

2017-10-09 Thread Mark Thomas
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

2017-10-09 Thread Mark Thomas
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

2017-10-09 Thread Harish Krishnan
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

2017-10-09 Thread John Ellis


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 Thread Jose María Zaragoza
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

2017-10-09 Thread 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-

 



 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 



UpgradedServletInputStream.read EOF

2017-10-09 Thread Sergey Mashkov
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

2017-10-09 Thread Wang, Jennifer
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

2017-10-09 Thread Wang, Jennifer
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

2017-10-09 Thread Mark Thomas
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