Re: [OT] Install Comodo SSL in Tomcat

2020-01-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 1/29/20 2:26 PM, logo wrote:
> Chris,
> 
>> Am 29.01.2020 um 16:59 schrieb Christopher Schultz
>> :
>> 
> Peter,
> 
> On 1/28/20 6:02 PM, logo wrote:
>  honorCipherOrder="true" protocols="TLSv1.2+TLSv1.3" 
> ciphers="HIGH:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POL
Y13
>
> 
05:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA
> -AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA2
56
>
> 
:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SH
> A256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-S
HA
>
> 
:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:D
> HE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-
AE
>
> 
S256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256
> :AES128-SHA:AES256-SHA:!DSS">
> 
> 
>  certificateKeystoreFile="${catalina.base}/conf/ssl/tomcat.p 12"
> certificateKeystorePassword="changeit" 
> certificateKeyAlias="tomcat" type="RSA" />
> 
 
> P12 is created with
 
> openssl pkcs12 -export -in tomcat.crt -inkey tomcat.key
> -certfile chain.pem -out tomcat.p12 -name tomcat -CAfile
> ca.crt -caname root -passout pass:changeit
 
 
> Seems to be valid and working ;-) .
> 
> Hmm. What version of Java? Perhaps Java has gotten better about 
> detecting the type of keystore? Also, Tomcat respects the value of 
> -Djavax.net.ssl.keyStoreType so if (a) you are explicitly setting
> it to PKCS12 or (b) your Java version is doing that, then you don't
> need to specify it, as it's the default.
> 
>> openjdk 11.0.6+10-post-Debian-1 and no JAVA_OPTS for certs…

It must just be the new default. :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4yELkACgkQHPApP6U8
pFgBfBAAvtW/NMZo/AVXYUFsA5GocrYfZDqwgE2B95M+9tFbBKTetuYBqzrOTKSx
AKiIU+0MGmqx0DUEPCgLh3prakJJtimhW+7JzM8i1nPEyhv242w8Y4+tsp9kwE5H
TQYsYhci3ydxQGP2QnwxbZdlxkgn4ngnEA1d6TuCp77E4Bi8rlglG7sB1IQhM3O9
yMY/60HBuIa3XTrdEdo2g5AKzQJ7AwjjWKpn3g0LtZBX0F3l/1S6jJIhCeLKHaWv
YbeIzJRUmGFE0XA6fTQXpN7XqWM617wlETdoSkWaGqUdAy2oHs6lO3mctqlQL4h6
TotSju1OKch7nbCntCludoNHVqawzSDSQSClkox3BnJ6jVIivVxUQ/8Ccs4opecv
XFChhCxBnnwd/rBwo1oNtP6K3/ekBtcHOIJhxtZ72BIhFbAT7PZeBstz4vN5isUQ
zzJo4prGhqd4CbgAKGvB5LtvpD3gltTgrtoKEz7k0XwMQ3AlqM2SjxE749HBeNlB
ZEeAIsrKTMzu+1UYXDOo2YOf7im8+5jCSuQJaL0DmgiLrIEEqi3hVPz3W07ZWAOh
766uqw0n7/HzTJ61bOO+gif3UGWS0b+fvLtNW+wHA6B0eMxgV9jWJudXtoOiRL8j
am6Ewv4dG6eJUlJcC2ZzHeLZMygoYbjY5rIBqb0o3O5CuiNNA3Q=
=Cz2L
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [Classpath] - Ordering issue

2020-01-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xavier,

On 1/29/20 3:23 PM, Xavier (Apache) wrote:
> Hello Tomcat list,
> 
> I’m struggling with a classpath problem. I have a webapp deployed
> under Tomcat. I have setup multiple tests (3 to be exact). They are
> all running 9.0.20, one under macOS, and the other 2 under Debian
> (same version for both). My app requires the jar lib to be loaded
> in a specific order. What I was able to gather so far is that I
> should do that customisation in myapp/WEB-INF/context.xml (it looks
> like I don’t need to tell Tomcat to look for that file)
> 
> I’m looking for some sample code to better understand how to do
> it.
> 
> So far I tried
> 
>   docBase="\webapps\CloudManager">  className="org.apache.catalina.loader.VirtualWebappLoader"/> 
> xx yy ... 
> 
> xx and yy are jar files in myapp/WEB-INF/lib/xx.jar
> 
> but without any luck.
> 
> I’m probably missing something obvious, but I just can’t find it.

Tomcat has no facility to force the loading of specific JARs in a
specific order. There has been no consensus that e.g. "alphabetic"
ordering should be enforced. There is no (servlet) spec-defined order,
either.

If you have some special libraries that must be loaded before others
(rather than a complete and total ordering), you can use the
[1] facility to establish a directory where some
libraries are loaded first. I suppose you could use many PreResources,
in order, to achieve a total ordering, but it will be a lot of typing.

The VirtualWebappLoader has been deprecated for a long time. I can't
even find the class in any currently-supported branch of Tomcat.

- -chris

[1]
http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html#Nested_Com
ponents
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4yEJMACgkQHPApP6U8
pFiUiw//ae5zTje1y7YE0wTnBxIVwlM7mz2KaGsZnONEUUMtGsscx7hfgHHIcs+j
R6mHSmeoH2YKlvG3qarcCvb0UpNXGjfORslbPcj1U4GQzUcftatcFPLGMejlWVBy
xFUcpmGe52zJ4NUWt0zW+3Bq8HfuD2eBJ+eUky9jQ5qS3sOFjrjafiWx2ftjvikd
E1qv1haoCq2Y9UwHq4K2gFoS8OTWvs3AHxZyrRYPoyKyQvSg3FTkNvy1DiNEeAqg
E6ZDl3FWryur/2PtOV4LhbRE/0UoifCIchrRomHxnbep4cqDx+DivLPgsG8ms4Iv
XQJiuWD3lWD3/GHm5ymEMgRNssZsO8EEIwoYkSk0ZueX4TaTWyYO4KEY4YHlukXt
igaGjZCcKUVfEJnS8ZcWOhViwn8qNbZHTHi12m/3w/So+TBvbYilcvgGSNf1B6LT
yqmPFccFuKYSGeiGhUxo0z0nYTbgXgR07Dwj82DzFmd0pOd8a+KLoYavLaWXnE2u
6oNWTtzXGfNjH0P0s4qqv0vSySxZZ/iP6NNIM0C2uJV4XtSeJGWCQ5R7ozAaNG9U
77VYBojXk/8LmO+asEeqFqex+vZAkVA/wpW1RW47NfgLhtnWY4LE3xeDuKLeclnM
EBwyA3DObWdRiqzXv+ydlF9fliQFVEgxD3EaO//vk32Uif0Zbeo=
=2Y4Q
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[Classpath] - Ordering issue

2020-01-29 Thread Xavier (Apache)
Hello Tomcat list,

I’m struggling with a classpath problem.
I have a webapp deployed under Tomcat. I have setup multiple tests (3 to be 
exact). They are all running 9.0.20, one under macOS, and the other 2 under 
Debian (same version for both).
My app requires the jar lib to be loaded in a specific order.
What I was able to gather so far is that I should do that customisation in 
myapp/WEB-INF/context.xml (it looks like I don’t need to tell Tomcat to look 
for that file)

I’m looking for some sample code to better understand how to do it.

So far I tried



  
  xx
  yy
...


xx and yy are jar files in myapp/WEB-INF/lib/xx.jar

but without any luck.

I’m probably missing something obvious, but I just can’t find it.


Thanks for your help,

Xavier
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Install Comodo SSL in Tomcat

2020-01-29 Thread logo
Chris,

> Am 29.01.2020 um 16:59 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
> On 1/28/20 6:02 PM, logo wrote:
>>> >> protocols="TLSv1.2+TLSv1.3" 
>>> ciphers="HIGH:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY13
> 05:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA
> - -AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
> :DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SH
> A256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA
> :ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:D
> HE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AE
> S256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256
> :AES128-SHA:AES256-SHA:!DSS">
>>> 
>>> 
> >> certificateKeystorePassword="changeit" 
>>> certificateKeyAlias="tomcat" type="RSA" /> 
>> 
>>> P12 is created with
>> 
>>> openssl pkcs12 -export -in tomcat.crt -inkey tomcat.key -certfile
>>> chain.pem -out tomcat.p12 -name tomcat -CAfile ca.crt -caname
>>> root -passout pass:changeit
>> 
>> 
>>> Seems to be valid and working ;-) .
> 
> Hmm. What version of Java? Perhaps Java has gotten better about
> detecting the type of keystore? Also, Tomcat respects the value of
> - -Djavax.net.ssl.keyStoreType so if (a) you are explicitly setting it
> to PKCS12 or (b) your Java version is doing that, then you don't need
> to specify it, as it's the default.

openjdk 11.0.6+10-post-Debian-1 and no JAVA_OPTS for certs…

> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xq8sACgkQHPApP6U8
> pFiQoBAAh85sDX5Q0aSMLyU5wQCsP2CPrA0iiaLwiU/rZ4Xr38mn8xW1lKAodjX8
> enLvHnRsfvQk+spXtNCsN4W0lh1ZCt2Y9bkO44AtlsCMHTaCgx3XgzuXUSxmkg1+
> ZsNv0jEWqslI0MwEZIzs8tlPbEg3EydjSF8kXf5fcygxA50FfR1o1ysY0cJNO2Z2
> 1pJDdueZPy0TzBquVAX9b+d9ElZk8QeavSJ4H8lFkj9Mjdj4XeqevuT/VayJKe34
> hBrdCJfXgLh+xq251eMxjSSIxXC5B3tK0SE5IeyZyBxd5KBq4HmN8q/rJcWmvfMd
> U+HUlvG0GugoodPnz2XklbJlW1J78uuhT81/sWp2PIiig7So/QSOJgpCuInJAdoh
> wCaO1aZfYABxJSCbbZGEtT22ybilgA9rnocsuGjI5Wrxo3dBxzMQ9Y0QB56/bkEN
> ZT2NnynXfEwVMlXqgnSqxga1hCW82wCfw8meZtye5Pc7QyvJDoEUqveakvNvjEIy
> 3OminOdu6KuIEjcLy2OJLs2voBqDuZToOwg3xSYEq07pPapd9xqnKcRGihv4j6aQ
> y5JZq+4oc0i4e286KB1OhDGposRcfWJfFWNSwk7ijKVlA6aAF/OfM9EAAlm3fWU7
> AkkpJslBQrxghCUhhPSrdUfNOCEQpHzOaCEUlyLRk1pY/52FGwQ=
> =ANtK
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 7: logs for failure request with unsupported cipher and unsupported SSL protocol

2020-01-29 Thread Mark Thomas
On 29/01/2020 16:02, Christopher Schultz wrote:
> Mark,
> 
> On 1/29/20 7:56 AM, Mark Thomas wrote:
>> On 29/01/2020 12:40, Palod, Manish wrote:
>>> Hi All,
>>>
>>>
>>> I am using tomcat 7 and in our server we support connection only
>>> with "TLSv1.2" and cipher
>>> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".
>>>
>>>
>>>
>>> Following is the Access valve pattern "%{E M/d/y @ hh:mm:ss.S a
>>> z}t %a (%{X-Forwarded-For}i) > %A:%p %r
>>> %{requestBodyLength}r %D %s %B %I %{Referer}i 
>>> %{User-Agent}i %u %{username}s %{sessionTracker}s
>>> with TLS protocol
>>> %{org.apache.tomcat.util.net.secure_protocol_version}r and Cipher
>>> %{javax.servlet.request.cipher_suite}r"
>>>
>>>
>>>
>>> and we are able to see following logs for successful connection:
>>>
>>>
>>>
>>> Wed 1/29/2020 @ 04:19:46.6 PM IST  (-) >
>>> :443  "GET /favicon.ico HTTP/1.1" - 1 404 66,
>>> "https://xx.xx.xx.xx/ /html/popCheck.html"  "Mozilla/5.0 (Windows
>>> NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>>> Chrome/79.0.3945.130 Safari/537.36" - - - with TLS protocol
>>> TLSv1.2 and Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>
>>>
>>> But in case when request is made with ex. SSLv3, TLSv1 or
>>> unsupported ciphers, Server is rejecting the request but no audit
>>> message is coming into the access logs.
>>>
>>> How can I get details about these requests with unsupported
>>> ciphers and unsupported SSL protocols?
> 
>> From Tomcat, you can't.
> 
>> If you upgrade to 8.5.x onwards you will get a 400 in the access
>> logs. You won't get the protocol or cipher information since that
>> requires a successful TLS connection before it is populated.
> 
> IIRC, we are parsing a little of the initial handshake packet for a
> few things. Would it be possible to snatch the protocol version from
> there and report it in the log file? The cipher suite of course is
> never going to exist because there was no overlap between the client
> and the server, but the protocol always has a single value for a
> handshake attempt.

Potentially. I haven't looked at how easy it would be to insert the
protocol in the right place so the access log valve picks it up.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8.5 disabling port 80 listening

2020-01-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nitin,

On 1/29/20 10:49 AM, Nitin Kadam wrote:
> I have a tomcat 8.5 server configured in the production
> environment. As per requirement, we need to disable all 80 port
> listening from the application and only https (443) to be allowed.

Requirements are requirements, but this one is a bad idea.

https://scotthelme.co.uk/why-closing-port-80-is-bad-for-security/

> I have implemented SSL and the same is working fine. however,
> still, tomcat is showing listening on 80. so can we disable
> (comment ) port 80 connector from server.xml which will only allow
> access to the portal with Https.
> 
> From :  connectionTimeout="2" redirectPort="443" /> To : 

Did you restart Tomcat?

Since you are binding to port 80, I have to ask if you are running as
root. If you have a "security" requirement for closing port 80, you
have  a MUCH MORE URGENT SECURITY REQUIREMENT TO NOT RUN AS root.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xsUAACgkQHPApP6U8
pFgHtQ//V4JVHP14XOESIvRt6tRorkeM1j8q+7nQ55NzQPZeUqFm80b0Xgp0wgQk
FbiKKKNmT93nKcGmJZzuzi9Vv67SDbxiyUztJUw6qcdfCm8tAuNgWMOwYC6alIZr
CLYsJ5QJuxEEAI6tSOcaZu6HQ5rL41XLo2rOYnPGOgxyLQuQBbGcp9o5vPsCJFbm
FH1TbYXllMUZPlUCvFktrePNu5l1sNOn5+3WRfkkGmnH1S8KN1udPQQytA7iLmGZ
/kAg/xP4Y6PuT1e0GjVHMd1KogtLsLZmNmuKOyMEiSQ4uXHc6BGUpZZMl+vi1MK+
0NN16xyNe+DkU8nwdT2zus8WGOW+3p441Zqn2GnOuZPVAqaTSQS/1jyHIOtHSWmR
6IpICCE5IFJIX4RRLwEErwG5moHSehkFuRPLUZj743meyZuu39iqqv5OfE+ctUyM
Tn/9QwIqrNIhKi9rgh5xU1X6lx4luVpWJLuXR1qBSjHiSkb1zouPxklFhSpo0b0K
QKeMIXTlc9UdUAUCGjcYcmVSb/BDDj0nMH0P+OgAzsHGZo1/XhVPdha8tqgVETCg
CytCSW4I0oxR/cS46EEJzYHERsYEG3573GY9QjcEASk/uRuLwO1noaRaPWFUHXkv
vLISdZYeU9VT7SfhulotPIDOV5y0DFXed5uJZ8o5xBeyO2oeXIc=
=SG7D
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Tomcat 8.5 disabling port 80 listening

2020-01-29 Thread jonmcalexander
>> -Original Message-
>> From: Nitin Kadam  
>> Sent: Wednesday, January 29, 2020 9:50 AM
>> To: Tomcat Users List >> 
>> Subject: Tomcat 8.5 disabling port 80 listening

>> Hi Team,

>> I have a tomcat 8.5 server configured in the production environment. As per 
>> requirement, we need to disable all 80 port listening from the application 
>> and only https (443) to be allowed.

>> I have implemented SSL and the same is working fine. however, still, tomcat 
>> is showing listening on 80. so can we disable (comment ) port 80 connector 
>> from  server.xml which will only allow access to the portal with Https.
>>
>>
>> From :
>>  >connectionTimeout="2"
>>redirectPort="443" />
>> To :
>> 
>> --
>> Regards
>> Nitin Kadam

By All means yes. :-)


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 
– 12/31

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.




Re: Tomcat 7: logs for failure request with unsupported cipher and unsupported SSL protocol

2020-01-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/29/20 7:56 AM, Mark Thomas wrote:
> On 29/01/2020 12:40, Palod, Manish wrote:
>> Hi All,
>> 
>> 
>> I am using tomcat 7 and in our server we support connection only
>> with "TLSv1.2" and cipher
>> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".
>> 
>> 
>> 
>> Following is the Access valve pattern "%{E M/d/y @ hh:mm:ss.S a
>> z}t %a (%{X-Forwarded-For}i) > %A:%p %r
>> %{requestBodyLength}r %D %s %B %I %{Referer}i 
>> %{User-Agent}i %u %{username}s %{sessionTracker}s
>> with TLS protocol
>> %{org.apache.tomcat.util.net.secure_protocol_version}r and Cipher
>> %{javax.servlet.request.cipher_suite}r"
>> 
>> 
>> 
>> and we are able to see following logs for successful connection:
>> 
>> 
>> 
>> Wed 1/29/2020 @ 04:19:46.6 PM IST  (-) >
>> :443  "GET /favicon.ico HTTP/1.1" - 1 404 66,
>> "https://xx.xx.xx.xx/ /html/popCheck.html"  "Mozilla/5.0 (Windows
>> NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/79.0.3945.130 Safari/537.36" - - - with TLS protocol
>> TLSv1.2 and Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>> 
>> 
>> But in case when request is made with ex. SSLv3, TLSv1 or
>> unsupported ciphers, Server is rejecting the request but no audit
>> message is coming into the access logs.
>> 
>> How can I get details about these requests with unsupported
>> ciphers and unsupported SSL protocols?
> 
> From Tomcat, you can't.
> 
> If you upgrade to 8.5.x onwards you will get a 400 in the access
> logs. You won't get the protocol or cipher information since that
> requires a successful TLS connection before it is populated.

IIRC, we are parsing a little of the initial handshake packet for a
few things. Would it be possible to snatch the protocol version from
there and report it in the log file? The cipher suite of course is
never going to exist because there was no overlap between the client
and the server, but the protocol always has a single value for a
handshake attempt.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xrIsACgkQHPApP6U8
pFgkNA/9FGRMi+DAxJVw8053fak0zPLbNsEHEdWmdtFI3NXIWpS8weMTEN2/RMM+
BA9pbkLvEk25+d8cWiCSIJWuhkB6chftwCdddKnFeIwhSgPl3hCG1qY3ruDEUj2y
/RpWObYXvQ+pbZoRGCHaTKg1pYL5ZJBvQMU+1qzivU0HViHbYa4PA2+NpNODmFgv
gVKuT/1UTH9rtTiDaBkAewJ+s9/wC2csQefZieIqP0WTnhC+ou26844WU1K+1uaV
i6S2YiMb7jP8dXD6QSUdbcFFmbC9ELIIXKp3b7X2nnSW6O4YWk8TYVAFLA9lhqvL
IKr6UtxfSLa+8CBrSdxYEdpT5tBcWtyERKyMuIlj/p2P445CfXkpR4Y4quTqULUZ
os7sR5AI20U9jsKhweDyBX6a8HxpGM+iAl+/GdUkMguflZSl1VNVfk1RcMNo2dCM
XqdIPSiqQBCIC1g/x6xKyU/g2J6NBtwCHuFzbYHxAP89zI1t5WZpyaM6eoB1G/wO
sFLHWgNzXAT3wCye+5c2g4S5QR/79HpOi1hnHduUymxI+Eax8jwE4Wa/XfubPICz
YXoT1fOcloWuFViRZi8qqviECzBEmw/RaJNGVK9yNf6E38N7ukJlWpn1fJi2rBh6
/Ztl6OijnH+25X8rFMPIbpdY04E3hQlw6Gqc7b+EBd6M8+hd1ZM=
=gYme
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Install Comodo SSL in Tomcat

2020-01-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 1/28/20 6:02 PM, logo wrote:
>> > protocols="TLSv1.2+TLSv1.3" 
>> ciphers="HIGH:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY13
05:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA
- -AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SH
A256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA
:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:D
HE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AE
S256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256
:AES128-SHA:AES256-SHA:!DSS">
>>
>> 
> certificateKeystorePassword="changeit" 
>> certificateKeyAlias="tomcat" type="RSA" /> 
> 
>> P12 is created with
> 
>> openssl pkcs12 -export -in tomcat.crt -inkey tomcat.key -certfile
>> chain.pem -out tomcat.p12 -name tomcat -CAfile ca.crt -caname
>> root -passout pass:changeit
> 
> 
>> Seems to be valid and working ;-) .

Hmm. What version of Java? Perhaps Java has gotten better about
detecting the type of keystore? Also, Tomcat respects the value of
- -Djavax.net.ssl.keyStoreType so if (a) you are explicitly setting it
to PKCS12 or (b) your Java version is doing that, then you don't need
to specify it, as it's the default.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xq8sACgkQHPApP6U8
pFiQoBAAh85sDX5Q0aSMLyU5wQCsP2CPrA0iiaLwiU/rZ4Xr38mn8xW1lKAodjX8
enLvHnRsfvQk+spXtNCsN4W0lh1ZCt2Y9bkO44AtlsCMHTaCgx3XgzuXUSxmkg1+
ZsNv0jEWqslI0MwEZIzs8tlPbEg3EydjSF8kXf5fcygxA50FfR1o1ysY0cJNO2Z2
1pJDdueZPy0TzBquVAX9b+d9ElZk8QeavSJ4H8lFkj9Mjdj4XeqevuT/VayJKe34
hBrdCJfXgLh+xq251eMxjSSIxXC5B3tK0SE5IeyZyBxd5KBq4HmN8q/rJcWmvfMd
U+HUlvG0GugoodPnz2XklbJlW1J78uuhT81/sWp2PIiig7So/QSOJgpCuInJAdoh
wCaO1aZfYABxJSCbbZGEtT22ybilgA9rnocsuGjI5Wrxo3dBxzMQ9Y0QB56/bkEN
ZT2NnynXfEwVMlXqgnSqxga1hCW82wCfw8meZtye5Pc7QyvJDoEUqveakvNvjEIy
3OminOdu6KuIEjcLy2OJLs2voBqDuZToOwg3xSYEq07pPapd9xqnKcRGihv4j6aQ
y5JZq+4oc0i4e286KB1OhDGposRcfWJfFWNSwk7ijKVlA6aAF/OfM9EAAlm3fWU7
AkkpJslBQrxghCUhhPSrdUfNOCEQpHzOaCEUlyLRk1pY/52FGwQ=
=ANtK
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Tomcat 8.5 disabling port 80 listening

2020-01-29 Thread Nitin Kadam
Hi Team,

I have a tomcat 8.5 server configured in the production environment. As per
requirement, we need to disable all 80 port listening from the application
and only https (443) to be allowed.

I have implemented SSL and the same is working fine. however, still, tomcat
is showing listening on 80. so can we disable (comment ) port 80 connector
from server.xml which will only allow access to the portal with Https.


>From :
 
To :

-- 
Regards
Nitin Kadam


Re: Tomcat 7: logs for failure request with unsupported cipher and unsupported SSL protocol

2020-01-29 Thread Mark Thomas
On 29/01/2020 12:40, Palod, Manish wrote:
> Hi All,
> 
> 
> I am using tomcat 7 and in our server we support connection only with 
> "TLSv1.2" and cipher "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".
> 
> 
> 
> Following is the Access valve pattern
> "%{E M/d/y @ hh:mm:ss.S a z}t %a (%{X-Forwarded-For}i) > %A:%p
> %r %{requestBodyLength}r %D %s %B %I %{Referer}i
> %{User-Agent}i %u %{username}s %{sessionTracker}s with TLS 
> protocol %{org.apache.tomcat.util.net.secure_protocol_version}r and Cipher 
> %{javax.servlet.request.cipher_suite}r"
> 
> 
> 
> and we are able to see following logs for successful connection:
> 
> 
> 
> Wed 1/29/2020 @ 04:19:46.6 PM IST  (-) > :443  "GET 
> /favicon.ico HTTP/1.1" - 1 404 66,  "https://xx.xx.xx.xx/ 
> /html/popCheck.html"  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" - 
> - - with TLS protocol TLSv1.2 and Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 
> 
> But in case when request is made with ex. SSLv3, TLSv1 or unsupported 
> ciphers, Server is rejecting the request but no audit message is coming into 
> the access logs.
> 
> How can I get details about these requests with unsupported ciphers and 
> unsupported SSL protocols?

>From Tomcat, you can't.

If you upgrade to 8.5.x onwards you will get a 400 in the access logs.
You won't get the protocol or cipher information since that requires a
successful TLS connection before it is populated.

You could enabled TLS handshake debugging at the JRE level but that will
probably generate far more data than you want.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Tomcat 7: logs for failure request with unsupported cipher and unsupported SSL protocol

2020-01-29 Thread Palod, Manish
Hi All,


I am using tomcat 7 and in our server we support connection only with "TLSv1.2" 
and cipher "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".



Following is the Access valve pattern
"%{E M/d/y @ hh:mm:ss.S a z}t %a (%{X-Forwarded-For}i) > %A:%p
%r %{requestBodyLength}r %D %s %B %I %{Referer}i
%{User-Agent}i %u %{username}s %{sessionTracker}s with TLS protocol 
%{org.apache.tomcat.util.net.secure_protocol_version}r and Cipher 
%{javax.servlet.request.cipher_suite}r"



and we are able to see following logs for successful connection:



Wed 1/29/2020 @ 04:19:46.6 PM IST  (-) > :443  "GET 
/favicon.ico HTTP/1.1" - 1 404 66,  "https://xx.xx.xx.xx/ /html/popCheck.html"  
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/79.0.3945.130 Safari/537.36" - - - with TLS protocol TLSv1.2 and 
Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256


But in case when request is made with ex. SSLv3, TLSv1 or unsupported ciphers, 
Server is rejecting the request but no audit message is coming into the access 
logs.

How can I get details about these requests with unsupported ciphers and 
unsupported SSL protocols?

Regards
Manish