Re: [EXT] Datadog _ JMX Integration facing connection issues.

[logo]

Sai Vamsi,

have you answered any of the questions Chris, Chuck and I asked?

Tomcat is NOT running, so please check "why" first.

We'd like to help, but can't see what is happening on your machine.

Kind regards

Peter

> Am 26.12.2023 um 12:02 schrieb Bodavula, Sai Vamsi Mohan Krishna (TR 
> Technology) :
> 
> by chance any findings on this.,
> 
> Thanks & Regards,
> --
> 
> SAI VAMSI .B
> Senior DevOps Engineer
> 
> 
> From: Bodavula, Sai Vamsi Mohan Krishna (TR Technology) 
> 
> Sent: Thursday, December 14, 2023 10:56
> To: Tomcat Users List 
> Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues.
> 
> Hai Chuck.,
> Thanks for jumping in.,
> 
> thats what my concern is.
> as previously added by Chris, I have added my annotations in Catalina_opts ., 
> Which is preferred by Java_Process for adding the annotations., But Here by 
> using catalina_opts., they are not reflecting.
> 
> where as adding them in java-tool-options., Makes a process with Tomcat and a 
> process that listens on the mentioned port., but throws port is already 
> binded., as its an environment variable, its already looking for a port, 
> where as its already created., throws binding error.
> 
> Yesterday ., I thought of adding both the formats, adding java_tool_opts and 
> Catalina opts., inorder to utilize the previous thigns., as below
> 
> - name: JAVA_TOOL_OPTIONS
>  value: {{ .Values.deployment.javaVMMemoryArgument }}
> 
>- name: POD_IP
>  valueFrom:
>fieldRef:
>  fieldPath: status.podIP
>- name: CATALINA_OPTS
>  value: >-
>-Dcom.sun.management.jmxremote
>-Dcom.sun.management.jmxremote.port=49151
>-Djava.rmi.server.hostname=$POD_IP
>-Dcom.sun.management.jmxremote.authenticate=false
>-Dcom.sun.management.jmxremote.ssl=false
>-Dcom.sun.management.jmxremote.local.only=false
>-Xms2048M -Xmx10240M
> 
> Java_tool_opts are as : -XX:+UseStringDeduplication -XX:+UseContainerSupport 
> -Dcom.sun.management.jmxremote
> 
> just added to initiate a JMX process.,
> 
> but nothing is working out.,
> I would like to request you for further inputs
> 
> 
> cc :chris
> 
> Thanks & Regards,
> --
> 
> SAI VAMSI .B
> Senior DevOps Engineer
> 
> 
> From: Chuck Caldarale 
> Sent: Thursday, December 14, 2023 00:28
> To: Tomcat Users List 
> Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues.
> 
> 
>> On Dec 13, 2023, at 10:36, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) 
>>  wrote:
>> 
>> as you just asked .,
>> I do have a process with Catalina.
>> 
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# netstat -tulpn
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address   Foreign Address State
>>PID/Program name
>> tcp6   0  0 :::34753:::*LISTEN   
>>1/java
>> tcp6   0  0 :::9109 :::*LISTEN   
>>1/java
>> tcp6   0  0 :::10109:::*LISTEN   
>>1/java
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ^C
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ps aux | grep 
>> catalina
>> root 744  0.0  0.0   6460   680 pts/1S+   11:47   0:00 grep 
>> --color=auto catalina
>> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/#
> 
> 
> That shows only the grep process looking for catalina, not anything using 
> catalina. If Tomcat were actually running, you’d see something like this 
> (slightly reformatted for clarity):
> 
> chuck@Chuck-MacBookPro apache-tomcat-9.0.83 > ps aux | grep catalina
> chuck16879   0.0  0.0 408626896   1376 s000  S+   12:53PM   
> 0:00.00 grep catalina
> chuck16874   0.0  0.9 415316912 153296 s000  S12:53PM   
> 0:02.66 
> /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/bin/java
> -Djava.util.logging.config.file=/Users/chuck/Downloads/apache-tomcat-9.0.83/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
> -Dtest_port=9090
> -Dignore.endorsed.dirs=
> -classpath
> /Users/chuck/Downloads/apache-tomcat-9.0.83/bin/bootstrap.jar:/Users/chuck/Downloads/apache-tomcat-9.0.83/bin/tomcat-juli.jar
> -Dcatalina.base=/Users/chuck/Downloads/apache-tomcat-9.0.83
> -Dcatalina.home=/Users/chuck/Downloads/apache-tomcat-9.0.83
> -Djava.io.tmpdir=/Users/chuck/Downloads/apache-tomcat-9.0.83/temp 
> org.apache.catalina.startup.Bootstrap
> start
> 
> 
>  - Chuck
> 


-
To unsubscribe, 

Re: [EXT] Datadog _ JMX Integration facing connection issues.

[logo]

Sai Vamsi,


> Am 08.12.2023 um 06:43 schrieb Bodavula, Sai Vamsi Mohan Krishna (TR 
> Technology) :
> 
> Hey Christopher.,
> Greetings of the day.
> 
> 
>  1.
> Might I have confused you with posting the arguments directly ., Yeah as i 
> just shared you the annotations with comments , to state you the stuff i am 
> using., But in my deployment ., I am using them in catalina opts., and trying 
> to call them from values.yaml., which looks like this :
> 
> javaVMMemoryArgument: "-Xms2048M -Xmx10240M -XX:+UseStringDeduplication 
> -XX:+UseContainerSupport -Dcom.sun.management.jmxremote 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dcom.sun.management.jmxremote.ssl=false 
> -Dcom.sun.management.jmxremote.local.only=false 
> -Dcom.sun.management.jmxremote.port=49151 
> -Djava.rmi.server.hostname=lab1workflow4scalsvc2zus1-service.hqm-lab1.svc.cluster.local
>  "
> 
>   and I am referring the word "javaVMMemoryArgument" from values yaml and 
> calling it in Catalina_opts, so that it would fetch all these 
> annotations as mentioned above, during the deployment. This is my deployment 
> part., where I am referring to the above values from values.yaml
> env:
>- name: CATALINA_OPTS
>  value: {{ .Values.deployment.javaVMMemoryArgument }}
> 
> 

I compare with my CATALINA_OPTS (and I noticed that some of my options were 
still in JAVA_OPTS boooh!) :

export CATALINA_OPTS="${CATALINA_OPTS} -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=10001 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false  
-Djava.rmi.server.hostname=${HOSTNAME} 
-Dcom.sun.management.jmxremote.local.only=false"

I see all my options in

root@tomcat:/usr/local/tomcat# ps -aef | less

UID  PIDPPID  C STIME TTY  TIME CMD
tomcat 1   0 71 10:42 ?00:04:02 /opt/java/openjdk/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat.base/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-agentlib:jdwp=transport=dt_socket,address=0.0.0.0:8000,server=y,suspend=n 
-XX:NativeMemoryTracking=summary -Dhostname= -Djava.awt.headless=true 
-Djavax.net.ssl.trustStore=/opt/apache-tomcat.base/conf/ssl/cacerts.jks 
-Xlog:gc:/opt/apache-tomcat.base/logs/gc.log 
-Djava.security.egd=file:/dev/urandom -Dsun.net.inetaddr.ttl=60 
-Djava.library.path=/usr/local/tomcat/native-jni-lib 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djdk.tls.rejectClientInitiatedRenegotiation=true 
-Djdk.tls.server.enableStatusRequestExtension=true 
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10001 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname= 
-Dcom.sun.management.jmxremote.local.only=false 
-javaagent:/opt/apache-tomcat.base/bin/jmx_prometheus_javaagent-0.12.0.jar=8080:/opt/apache-tomcat.base/bin/tomcat.yaml
 -Djava.net.debug=ssl -XX:+UnlockDiagnosticVMOptions -Dignore.endorsed.dirs= 
-classpath 
/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar 
-Dcatalina.base=/opt/apache-tomcat.base -Dcatalina.home=/usr/local/tomcat 
-Djava.io.tmpdir=/opt/apache-tomcat.base/temp 
org.apache.catalina.startup.Bootstrap start

Ports are opened

root@tomcat:/usr/local/tomcat# netstat -tulpn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
...
tcp0  0 0.0.0.0:10002   0.0.0.0:*   LISTEN  
-   
tcp0  0 0.0.0.0:10001   0.0.0.0:*   LISTEN  
-   
...
tcp2  0 0.0.0.0:84430.0.0.0:*   LISTEN  
-   
...


jconsole :10001   
  

> JMX connect success



> 
> 
> 
>  1.
> Coming to Process., I have searched for Java process that listens on my 
> mentioned port ie., 49151, but none of the process is listening to that 
> process.
> 
> I even tried with
> root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
> grep LISTEN
> tcp6   0  0 :::10109:::*LISTEN
>   1/java
> tcp6   0  0 :::9109 :::*LISTEN
>   1/java
> root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
> more
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State 
>   PID/Program name
> tcp6   0  0 :::10109  

Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast

[logo]

Chuck,

> Am 01.12.2023 um 16:07 schrieb Chuck Caldarale :
> 
> 
>> On Dec 1, 2023, at 02:27, Manak Bisht  wrote:
>> 
>> Hi, I am trying to implement non-sticky session replication using Delta
>> Manager with static membership. The nodes are across two different
>> machines. I am unable to discover members in the cluster with the following
>> logs on both machines -
>> 
>> org.apache.catalina.ha.session.DeltaManager.startInternal Register manager
>> localhost# to cluster element Engine with name Catalina
>> org.apache.catalina.ha.session.DeltaManager.startInternal Starting
>> clustering manager at localhost#
>> org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager
>> [localhost#]: skipping state transfer. No members active in cluster group.
>> 
>> Please find the cluster settings (inside the * *tag) below. I have
>> also added the * *tag to the *web.xml *files.
>> 
>> *Node_1*
> 
>  . . .
> 
>>   
>>   > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>   address="127.0.0.1"
>>   port="8090"
>>   autoBind="0"
>>   maxThreads="6”/>
> 
> 
> I’m not a clustering expert, but perhaps the address value needs to be an IP 
> address accessible to the other machine in the cluster. The above 127.0.0.1 
> (localhost) would appear to limit each receiver to the machine it’s running 
> on.
> 
> The second node has the same issue.

NICE find!

> 
>  - Chuck
> 


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

Re: Ciphers Warning in logfile for Tomcat 8.5.96 (with Adoptium jdk-8.0.392.8-hotspot)

[logo]

Hi

> Am 29.11.2023 um 11:46 schrieb Markus Schlegel :
> 
> Hi,
> This is a continuation of the discussion taken below
> https://bz.apache.org/bugzilla/show_bug.cgi?id=67628 where I asked about
> the following warning which appears in our log:
> 
> (29.11.2023 09:53:14 org.apache.tomcat.util.net.SSLUtilBase getEnabled
> WARNING T-19): Tomcat interprets the [ciphers] attribute in a manner
> consistent with the latest OpenSSL development branch. Some of the
> specified [ciphers] are not supported by the configured SSL engine for this
> connector (which may use JSSE or an older OpenSSL version) and have been
> skipped: [[TLS_DHE_PSK_WITH_AES_256_CCM, (... I am excluding 60 entries
> here...), TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256]]
> 
> After some discussion in the ASF bugzilla, Mark asked to move the
> discussion about the default ciphers configuration into this users
> mailing list.
> 
> We explicitly set the ciphers configuration since the default config
> which comes with Tomcat still includes the (normal) Diffie-Helman key
> exchange algorithm which are considered to be insecure (but not the
> ECDH's!). See https://weakdh.org/ for information about this.
> 
> We can't turn off that warning without getting other drawbacks as long
> as we use our custom ciphers configuration, which led "warnOnSkip"
> being set to true in the respective code section.
> Those skipped ciphers are of no interest for us or our customers since
> they appear only because Tomcat - as of my understanding - uses the
> ciphers-set from OpenSSL to build the complete list of theoretically
> available ciphers.
> 
> There is nothing wrong with our configuration, but having that warning
> in the log will cause each and every customer asking us why this
> warning ist there - since they will fear a configuration problem.
> 
> One question now is, if the default configuration of the ciphers in
> Tomcat 8.5.96 is still save or not.
> 
> I have re-run https://www.ssllabs.com/ssltest against our server setup.
> With the Tomcat default ciphers configuration
> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA" I get grade "B"
> because of the weak key exchange algorithm using DH. It lists 10 weak
> ciphers out of 12.
> 
Why are you saying that you get a weak Keyexchange with DH?  That is not per se 
the case. DH is still valid.

Did you set -Djdk.tls.ephemeralDHKeySize=2048 as CATALINA_OPTS ?

> If I run it with our configuration, which adds ":-DH:+ECDH", I get
> Grade "A" with 4 weak ciphers out of 6.
> 
> Changing the config to add ":-CBC" to the default config as suggested
> by Mark in bugzilla does not have any effect. Still Grade B, 10 weak
> out of 12. It seems to me that -CBC might not be a valid option at
> all?
> 
> Mark got different results when he run the ssllabs tests. That might
> be caused by different TLS certificates used? I am using a certificate
> created with a RSA-2048bits Key and SHA256withRSA signature algorithm.
> No clue if this causes any difference to Mark's setup.
> 
> Anyone which knows if and how the certificate influences the selection of
> possible ciphers?


> Anyone having similar problems?
> Anyone successful in excluding all ciphers with "CBC" ?
> 

In my case I was only successful to get the ciphers right by setting them 
manually:

ciphers="TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"

The result is A(+) and TLS is supported from Java 8, IE 11, iOS12.2, Android 6, 
Chrome 79, Firefox 66, Safari 13.0, which seems to be sufficient to me.

Maybe I could get even away from DH from the result of the client simulations. 
In the end it's up to you if you prioritize 128 or 256bit ciphers. BTW I use 
testssl.sh for local tests (and non 443 ports). 

From what I found elsewhere, ECDH+AES256:ECDH+AES128 are the culprits for the 
CBCs.

Regards

Peter

> Thanks,
> Markus Schlegel

Re: Wondering about tomcat-users.xml could not be found

[logo]

Hi Chris*,


> Am 16.11.2023 um 20:12 schrieb Christopher Schultz 
> :
> 
> Christoph,
> 
> On 11/15/23 10:32, Christoph Kukulies wrote:
>> I'm running tomcat9 under Ubuntu 22.04 with an haproxy 2.8 in front of it.
>> I'm wondering about the following in the logs:
>> Nov 15 16:19:23 mail tomcat9[832]: Reloading memory user database 
>> [UserDatabase] from updated source 
>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>> Nov 15 16:19:23 mail tomcat9[832]: The specified user database 
>> [conf/tomcat-users.xml] could not be found
>> Nov 15 16:19:33 mail tomcat9[832]: Reloading memory user database 
>> [UserDatabase] from updated source 
>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>> Nov 15 16:19:33 mail tomcat9[832]: The specified user database 
>> [conf/tomcat-users.xml] could not be found
>> Nov 15 16:19:43 mail tomcat9[832]: Reloading memory user database 
>> [UserDatabase] from updated source 
>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>> Nov 15 16:19:43 mail tomcat9[832]: The specified user database 
>> [conf/tomcat-users.xml] could not be found
>> Nov 15 16:19:53 mail tomcat9[832]: Reloading memory user database 
>> [UserDatabase] from updated source 
>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>> Nov 15 16:19:53 mail tomcat9[832]: The specified user database 
>> [conf/tomcat-users.xml] could not be found
>> File /var/lib/tomcat9/conf/tomcat-users.xml is definitely there.
>> It occurs every 10 seconds.
>> Don't know who is causing this and why. Permissions? Ownership wrong?
>> -rw-r- 1 root root   2756 Jan 15  2022 tomcat-users.xml
>> Believe the ownership was wrong. Maybe it came from migrating an old 
>> installation.
>> What are the correct perms/ownership in /var/lib/tomcat9 and below?
> 
> What is the user-owner of the JVM process?
> 
> Check that all of the above would be both readable and executable by that 
> user:
> 
> ls -ld /var
> ls -ld /var/lib
> ls -ld /var/lib/tomcat9
> ls -ld /var/lib/tomcat9/conf
> 
> ... and of course that the JVM user can read 
> /var/lib/tomcat9/conf/tomcat-users.xml which I assume is true since you said 
> you already checked it.
> 
> What is the cwd of the JVM process?
> 
> The first message ("reloading") has the full path, and the second message 
> ("file not found") only mentions a relative path. I wonder if that is the 
> difference.
> 


Could it be that the second path relates to a missing env-Variable 
$CATALINA_BASE or $CATALINA_HOME?

Peter

> -chris
> 
> -
> 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: Sharing catalina home among tomcat machines in a load balanced environment gives problems with log files

[logo]

Guiseppe,

did you consider the separation of CATALINA_HOME and CATALINA_BASE. Look at the 
RUNNING.txt file that describes the purpose...

Plus some symbolic links that have the really common files linked to the BASE 
directory?

HTH

Peter


Am 10.10.2023 um 09:53 schrieb Giuseppe Sacco :

Hello,
I am testing an environment with a load balancer and two machines that host
tomcat. The two machines should really be identical, and no tomcat cluster
is configured (no sessions are shared between the tomcats).

I would like to put the tomcat installation (catalina_home) in a shared
directory and have both tomcat use it. In a test installation I only have
some problems with log files, since they are shared and the tomcats write
concurrently to the same files, overlapping their text.

I set the property java.util.logging.config.file to a per tomcat properties
file, and this works for some of the files, but not for all. In fact, at
least the AccessLogValve does not have any way to specify a different
directory for each host, i.e., adding the hostname in the path.

So, these are my questions: is this way of sharing tomcat_home a viable
solution? Are there any way to store all log files in separate directories
based on the hostname or the ip address or a java parameter (using -D... on
the command line)? Is there a way to change log locking/buffering in a way
that written text does not overlap when two tomcats write concurrently?

Thank you,
Giuseppe

-
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: HSTS on 401 / error pages

[logo]

Chris,

this is what's happening with the globally configured HttpHeaderSecurityFilter:

curl -ik "https://localhost:8443/manager/;
HTTP/2 302 
x-frame-options: DENY
x-content-type-options: nosniff
strict-transport-security: max-age=31536000
x-xss-protection: 1; mode=block
location: /manager/html
content-type: text/html
content-length: 0
date: Thu, 14 Sep 2023 20:31:50 GMT


curl -ik "https://localhost:8443/manager/html/;
HTTP/2 401 
cache-control: private
www-authenticate: Basic realm="Tomcat Manager Application"
vary: accept-encoding
content-type: text/html;charset=ISO-8859-1
content-length: 2499
date: Thu, 14 Sep 2023 20:32:00 GMT

curl -ik "https://localhost:8443/xxx;
HTTP/2 404 
strict-transport-security: max-age=31536000
x-frame-options: DENY
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
content-type: text/html;charset=utf-8
content-language: en
content-length: 41
date: Thu, 14 Sep 2023 20:31:35 

I assume it's the order of the filters? Authentication before HeaderSecurity 
maybe? It's not HSTS only

What do you think?

Peter

> Am 14.09.2023 um 16:03 schrieb Thomas Hoffmann (Speed4Trade GmbH) 
> :
> 
> Hello Chris,
> 
>> -Ursprüngliche Nachricht-
>> Von: Christopher Schultz 
>> Gesendet: Donnerstag, 14. September 2023 15:26
>> An: users@tomcat.apache.org
>> Betreff: Re: HSTS on 401 / error pages
>> 
>> Thomas,
>> 
>> Please start a new thread next time.
> 
> Sorry, I thought removing all content and subject is sufficient. Maybe the 
> message-id header is used internally(?)
> 
>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello everyone,
>>> 
>>> I would like to get your opinion about the HttpHeaderSecurityFilter in
>> Tomcat.
>>> I configured HSTS in Tomcat and it works well.
>>> When I do a pen-test with burpsuite it complains that HSTS header is
>> missing on 401 responses.
>>> I couldn’t find much information about whether HSTS makes sense for
>> error pages.
>>> 
>>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
>> expects the header.
>>> Are there any pros and cons about sending HSTS on 401 response?
>> 
>> You should always return an HSTS header.
>> 
>> How have you configured your HttpHeaderSecurityFilter? What is causing the
>> 401 response? Which application is responding with that status?
>> 
>> -chris
>> 
> 
> Here are the requested details:
> 
> SecurityFilter is set in the web.xml of the application:
> 
>   httpHeaderSecurity
>   
> org.apache.catalina.filters.HttpHeaderSecurityFilter
>   true
>   
>hstsEnabled
>true
>   
> ...
> 
> Further down in the web.xml is a constraint:
>   
> 
> xxx
> /*
> 
> 
> 
> yyy
> 
> 
> 
> CONFIDENTIAL
> 
> 
> 
> 
> There is no frontend-server, tomcat is directly accessed from the browser.
> It seems that burpsuite didn’t send authentication in the first place and 
> this resulted in 401.
> 
> If I use curl https:///  I get similar result:
> < HTTP/1.1 401
> < WWW-Authenticate: Negotiate
> < Content-Type: text/html;charset=utf-8
> < Content-Language: de
> < Content-Length: 439
> < Date: Thu, 14 Sep 2023 13:58:10 GMT
> 
> When providing credentials to curl, the following headers are also included:
> < Strict-Transport-Security: max-age=31536000;includeSubDomains
> < X-Frame-Options: DENY
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
> 
> I hope this information helps.
> 
> Thanks in advance!
> Thomas
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Enable two way SSL in Apache Tomcat 10 Version 10.0.27

[logo]

Kaushal,

please check the new configuration method with SSLHostConfig - your's is 
probably from an older version, right? In the working version you already use 
it. 

see my (redacted) config:

 


  truststoreFile="${catalina.base}/conf/ssl/cacerts.jks"
  truststorePassword="changeit"
  
ciphers="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305: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-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">
   




Hope this helps

Peter


> Am 20.08.2023 um 05:47 schrieb Kaushal Shriyan :
> 
> Hi,
> 
> I am attaching both server.xml for one way SSL and Two Way SSL 
> 
> One way SSL /opt/tomcat10/conf/server.xml -> 
> tomcat10serverworkingonewaytls.xml (working)
> Two way SSL /opt/tomcat10/conf/server.xml -> 
> tomcat10serverworkingtwowaytls.xml (Not working) 
> 
> Please comment. Thanks in advance.
> 
> Best Regards,
> 
> Kaushal
> 
> On Sun, Aug 20, 2023 at 6:48 AM Kaushal Shriyan  > wrote:
>> 
>> 
>> On Thu, Aug 10, 2023 at 11:29 AM Christopher Schultz 
>> mailto:ch...@christopherschultz.net>> wrote:
>>> Kaushal,
>>> 
>>> On 8/7/23 22:23, Kaushal Shriyan wrote:
>>> > Hi,
>>> > 
>>> > I have gone through 
>>> > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html.
>>> > Is there a way to enable two way SSL (mutual) in Apache Tomcat 10 Version
>>> > 10.0.27?
>>> > 
>>> > Please guide me.
>>> > 
>>> > Thanks in Advance.
>>> 
>>> I see you have "gone through" the SSL Howto, but could you be specific 
>>> about what you have actually done? For example, what does your 
>>>  in server.xml look like, what does your web.xml look like, 
>>> and what files do you have on the disk?
>>> 
>>> -chris
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
>>> 
>>> For additional commands, e-mail: users-h...@tomcat.apache.org 
>>> 
>>> 
>> 
>> 
>> Hi Chris,
>> 
>> Apologies for the delay in replying. Thanks in advance. I am trying to 
>> enable Mutual two way SSL using tomcat 10.0.27 on Red Hat Enterprise Linux 
>> release 8.8 (Ootpa). Currently I am encountering the below issue. 
>> 
>> 20-Aug-2023 06:40:25.183 SEVERE [main] 
>> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to 
>> initialize component [Connector[HTTP/1.1-10443]]
>> org.apache.catalina.LifecycleException: Protocol handler initialization 
>> failed 
>> 
>> Caused by: java.lang.IllegalArgumentException: No SSLHostConfig element was 
>> found with the hostName [_default_] to match the defaultSSLHostConfigName 
>> for the connector [https-openssl-nio-10443] 
>> 
>> #cat /etc/redhat-release
>> Red Hat Enterprise Linux release 8.8 (Ootpa)
>> # /opt/tomcat10/bin/version.sh
>> Using CATALINA_BASE:   /opt/tomcat10
>> Using CATALINA_HOME:   /opt/tomcat10
>> Using CATALINA_TMPDIR: /opt/tomcat10/temp
>> Using JRE_HOME:/usr
>> Using CLASSPATH:   
>> /opt/tomcat10/bin/bootstrap.jar:/opt/tomcat10/bin/tomcat-juli.jar
>> Using CATALINA_OPTS:
>> Server version: Apache Tomcat/10.0.27
>> Server built:   Oct 3 2022 14:18:31 UTC
>> Server number:  10.0.27.0
>> OS Name:Linux
>> OS Version: 4.18.0-477.15.1.el8_8.x86_64
>> Architecture:   amd64
>> JVM Version:1.8.0_382-b05
>> JVM Vendor: Red Hat, Inc.
>> #
>> 
>> #cat catalina.out
>> 20-Aug-2023 06:40:24.753 WARNING [main] 
>> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
>> [Server/Service/Connector] failed to set property [clientAuth] to [want]
>> 20-Aug-2023 06:40:24.756 WARNING [main] 
>> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
>> [Server/Service/Connector] failed to set property [sslProtocol] to [TLS]
>> 20-Aug-2023 06:40:24.756 WARNING [main] 
>> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
>> [Server/Service/Connector] failed to set property [keystoreFile] to 
>> [/opt/tomcat10/ssl/keystore.jks]
>> 20-Aug-2023 06:40:24.756 WARNING [main] 
>> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
>> [Server/Service/Connector] failed to set property [keystorePass] to [apigee]
>> 20-Aug-2023 06:40:24.757 WARNING [main] 
>> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
>> [Server/Service/Connector] failed to set property [truststoreFile] to 
>> [/opt/tomcat10/ssl/clienttrustore.jks]
>> 

Re: Java Agent and Tomcat shutdown

[logo]

Hi Thomas

> Am 11.05.2023 um 16:05 schrieb Thomas Hoffmann (Speed4Trade GmbH) 
> :
> 
> Hello,
> 
> we are using a java agent to start a listening process (JMX proxy).
> 
> The systemd file for tomcat looks like (snippet):
> JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar 
> -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001


I do think that setting JAVA_OPTS is triggering this behavior: EVERY java 
process contains this rmi server with this conflicting port.

The way to go is using CATALINA_OPTS. The options go only into the 
start-process...

HTH 

Peter

> ExecStart=/opt/apache-tomcat/bin/catalina.sh run
> ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60
> 
> When starting the service, everything works fine and the java agent is 
> accessible via the opened port 15000.
> 
> However, when stopping tomcat, it seems that a java process is started and 
> tries to open the same port again:
> 2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException
>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>at 
> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:493)
>at 
> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503)
> Caused by: java.rmi.server.ExportException: Port already in use: 15000; 
> nested exception is:
>java.net.BindException: Address already in use
>at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
>at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
>at 
> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415)
>at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
>at 
> java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:235)
>at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223)
>at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:208)
>at 
> java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203)
>at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33)
>... 6 more
> Caused by: java.net.BindException: Address already in use
>at java.base/sun.nio.ch.Net.bind0(Native Method)
>at java.base/sun.nio.ch.Net.bind(Net.java:555)
>at java.base/sun.nio.ch.Net.bind(Net.java:544)
>at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
>at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
>at java.base/java.net.ServerSocket.(ServerSocket.java:274)
>at java.base/java.net.ServerSocket.(ServerSocket.java:167)
>at 
> java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45)
>at 
> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:673)
>at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
>... 14 more
> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent 
> load/premain call failed at 
> src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
> 
> The premain method is entered again and of course the port is already used.
> Is there a way to stop tomcat without re-entering the java agent?
> Using shutdown.sh shows the same problem.
> 
> Thanks in advance!
> Thomas
> 
> -
> 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: OT: hsts in Tomcat 9.0.73

[logo]

Jon,


Oh, I see there is a redirect. I do see a similar behavior on redirects (302) 
or auth (401 eg. on the manager app). But HSTS on 200, 404 or 403.

What happens if you call "/c/portal/license" ?

Peter

> Am 21.04.2023 um 23:05 schrieb jonmcalexan...@wellsfargo.com.invalid 
> :
> 
> Here is the output from a powershell command:
> 
> Invoke-WebRequest -Uri https://ldvwa00a0010.wellsfargo.com:8443 
> -MaximumRedirection 0 | Select-Object -ExpandProperty Headers
> 
> KeyValue
> ----
> X-Content-Type-Options nosniff
> X-Frame-OptionsSAMEORIGIN
> X-XSS-Protection   1
> Set-Cookie JSESSIONID=E60F2DA9B666966565C8076FE5C47226.wfig1; 
> Path=/; Secure; HttpOnly,COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069 
> 23:39:55 GMT; Path=/; Secure; HttpOnly,GU...
> Location   
> https://ldvwa00a0010.wellsfargo.com:8443/c/portal/license
> Content-Length 0
> Date   Fri, 21 Apr 2023 20:57:47 GMT
> Keep-Alive timeout=60
> Connection keep-alive
> 
> 
> Here is curl
> 
> curl -ikl --verbose https://HOST:8443 > op.txt
> 
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
> 0*   Trying IP:8443...
> * TCP_NODELAY set
> * Connected to HOST (IP) port 8443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> } [5 bytes data]
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> } [512 bytes data]
>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
> 0* TLSv1.3 (IN), TLS handshake, Server hello (2):
> { [85 bytes data]
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> { [3806 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> { [300 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> { [4 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> } [37 bytes data]
> * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
> } [1 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> } [16 bytes data]
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> { [16 bytes data]
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> * ALPN, server did not agree to a protocol
> * Server certificate:
> *  subject: C=US; O=; OU=; CN=
> *  start date: Aug 10 16:35:12 2022 GMT
> *  expire date: Aug  9 16:35:12 2024 GMT
> *  issuer: C=US; O=; OU=; CN=
> *  SSL certificate verify result: self signed certificate in certificate 
> chain (19), continuing anyway.
>  0 00 00 0  0  0 --:--:--  0:00:02 --:--:-- 
> 0} [5 bytes data]
>> GET / HTTP/1.1
>> Host: HOST:8443
>> User-Agent: curl/7.65.3
>> Accept: */*
>> 
> { [5 bytes data]
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 302
> < X-Content-Type-Options: nosniff
> < X-Frame-Options: SAMEORIGIN
> < X-XSS-Protection: 1
> < Set-Cookie: JSESSIONID=CB5FFB977D92D0CB953AE651014CD048.wfig1; Path=/; 
> Secure; HttpOnly
> < Set-Cookie: COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069 23:42:52 GMT; 
> Path=/; Secure; HttpOnly
> < Set-Cookie: GUEST_LANGUAGE_ID=en_US; Expires=Tue, 03 Dec 2069 23:42:52 GMT; 
> Path=/; Secure; HttpOnly
> < Location: https://HOST:8443/c/portal/license
> < Content-Length: 0
> < Date: Fri, 21 Apr 2023 21:00:44 GMT
> <
>  0 00 00 0  0  0 --:--:--  0:00:03 --:--:-- 0
> * Connection #0 to host left intact
> 
> Thanks,
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Senior Infrastructure Engineer
> Asst. Vice President
> He/His
> 
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> 
> 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.
> 
> 
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Friday, April 21, 2023 1:17 PM
>> To: users@tomcat.apache.org
>> Subject: Re: OT: hsts in Tomcat 9.0.73
>> 
>> Jon,
>> 
>> On 4/21/23 11:47, jonmcalexan...@wellsfargo.com.INVALID wrote:
>>> Thank you Olaf, however, the connection was made over https directly
>>> to Tomcat on port 8443.
>> Sample curl with secrets removed?
>> 
>> -chris
>> 
 -Original Message-
 From: Olaf Kock 
 Sent: Friday, April 21, 2023 1:48 AM
 To: users@tomcat.apache.org
 Subject: Re: OT: hsts in Tomcat 9.0.73
 
 
 Am 21.04.23 um 07:03 

Re: OT: hsts in Tomcat 9.0.73

[logo]

Jon,

again, the Qualys Scanner usually does not know any other webcontexts than 
root, manager and examples. So if you don't have a root context, it may well 
end up in the woods and the result will not have a HSTS-Header. Can you verify 
the requested resource?

Best regards

Peter

> Am 21.04.2023 um 17:47 schrieb jonmcalexan...@wellsfargo.com.invalid 
> :
> 
> Thank you Olaf, however, the connection was made over https directly to 
> Tomcat on port 8443.
> 
> Thanks,
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Senior Infrastructure Engineer
> Asst. Vice President
> He/His
> 
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> 
> 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.
> 
> 
>> -Original Message-
>> From: Olaf Kock 
>> Sent: Friday, April 21, 2023 1:48 AM
>> To: users@tomcat.apache.org
>> Subject: Re: OT: hsts in Tomcat 9.0.73
>> 
>> 
>> Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID:
>>> No, there is no error and no stack trace. Everything works, just the hsts
>> header isn't in the list of headers.
>>> 
>> The lowest hanging fruit: HSTS is only defined on https - on http it doesn't
>> have any meaning and Tomcat would be correct in not sending it (I haven't
>> looked at the source if it does, but it should be easy to test)
>> 
>> If you have a reverse proxy handling https & proxying through http, Tomcat
>> might not know that it'd be fine to send the header. (If that is your case,
>> there is the brute force "secure" attribute on the connector
>> - use it only when there's no way to connect through http from anywhere
>> but your reverse proxy)
>> 
>> This has bitten me a few times
>> 
>> Olaf
>> 
>> 
>> -
>> 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: sslHostConfig and ciphers

[logo]

Beware Jon,

> Am 08.03.2023 um 07:56 schrieb jonmcalexan...@wellsfargo.com.invalid 
> :
> 
> Fwiw, this is happening in an outbound connection originated by a springboot 
> app hosted in Tomcat. Any known issues with this and handshake issues?
> 

Then the tomcat sslHostConfig does not matter at all, only the one on the java 
options (or security config) "jdk.tls.client.cipherSuites".


Peter


> 
> Thanks,
> 
> 
> Sent with BlackBerry Work (www.blackberry.com)
> 
> From: jonmcalexan...@wellsfargo.com.INVALID
> Sent: Mar 4, 2023 3:08 AM
> To: users@tomcat.apache.org
> Subject: RE: sslHostConfig and ciphers
> 
> Thank you!!!
> 
> 
> Thanks,
> 
> 
> Sent with BlackBerry Work 
> (https://urldefense.com/v3/__http://www.blackberry.com__;!!F9svGWnIaVPGSwU!sOH_wTKBGJ6Btc-RekE10jWwQ85jkQkEltIWa0AaoIbooX5UMGSH88GoLuiVcjYRxEg9wZBM3INUA8zBXKbc56z70yYUpimTy-zbVbi6bbQ$
>  )
> 
> From: "Thomas Hoffmann (Speed4Trade GmbH)" 
> 
> Sent: Mar 4, 2023 1:22 AM
> To: Tomcat Users List 
> Subject: AW: sslHostConfig and ciphers
> 
> Hello,
> 
> this message originates from your used java. It's not from tomcat.
> Java doesn't know this cipher-suite or is disabled in java.security
> 
> You can list the supported ciphers via some code lines like 
> https://urldefense.com/v3/__https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms__;!!F9svGWnIaVPGSwU!ok1eVR9QoczE-D4sspGE5zZh3h7aTnNIrKfVfkKUC4CSWI-99BHQNKZNO1VwWMhDzKjxpRQIsilgijmwV8_swl6-GicjRiAnIId8fctCkh9Xjg$
> 
> Greetings, Thomas
> 
>> -Ursprüngliche Nachricht-
>> Von: jonmcalexan...@wellsfargo.com.INVALID
>> 
>> Gesendet: Freitag, 3. März 2023 18:38
>> An: users@tomcat.apache.org
>> Betreff: sslHostConfig and ciphers
>> 
>> Ok, I don't know if I'm doing something wrong, or if I'm just not reading the
>> output correctly.
>> 
>> I have JSSE connector using sslHostConfig and in there I have defined 
>> ciphers,
>> as below:
>> 
>> > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="150"
>> maxHttpHeaderSize="16384"
>> compression="on"
>> scheme="https"
>> SSLEnabled="true"
>> secure="true"
>> defaultSSLHostConfigName="test.test">
>> > hostName="test.test"
>> protocols="TLSv1.2"
>> ciphers="TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH
>> _AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_C
>> CM,TLS_ECDHE_ECDSA_WITH_AES_256_CCM,TLS_DHE_RSA_WITH_AES_256_
>> CCM_8,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,TLS_DHE_RSA_WITH_AES_128_G
>> CM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_1
>> 28_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_CCM,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CCM,TLS_DHE_RSA_WITH_AES_128_CCM
>> _8,TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
>> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_
>> CHACHA20_POLY1305_SHA256,
>> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"
>> > certificateKeystoreFile=""
>> certificateKeystorePassword ="${keystore.pass}"
>> certificateKeyPassword="${keystore.pass}"
>> certificateKeyAlias=""
>> />
>> 
>> 
>> 
>> However, if I enable ssl debugging, I am getting the following messages in my
>> catalina.out file.
>> 
>> 03-Mar-2023 16:43:22.120 INFO [main] org.apache.coyote.AbstractProtocol.init
>> Initializing ProtocolHandler ["https-jsse-nio-9443"]
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.146
>> UTC|SSLContextImpl.java:425|System property jdk.tls.client.cipherSuites is 
>> set
>> to 'null'
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.150
>> UTC|SSLContextImpl.java:425|System property jdk.tls.server.cipherSuites is 
>> set
>> to 'null'
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.161
>> UTC|SSLCipher.java:438|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
>> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.201
>> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.201
>> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.202
>> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.202
>> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.202
>> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.202
>> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.203
>> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
>> 

Re: [EXTERNAL EMAIL] Please help me install Tomcat

[logo]

Amn,

Am 2023-01-20 02:45, schrieb Niranjan Rao:
Do you absolutely need to have it as a service? If not, just expand the 
tarball and run catalina.sh start from bin directory. Works perfectly


Any information in catalina.out? We need to figure out at what point 
it's failing and that will send us in right direction.



Regards,

Niranjan

On 1/19/23 16:58, Amn Ojee Uw wrote:
I've tried to install Tomcat, different version, like so : /# Download 
the
latest release of tomcat 10. 1. 5// //wget 
https: //urldefense. com/v3/__https:

 //downloads. apache. org/tomcat/tomcat-8/v8. 5. 85/bin/apache-tomcat-8. 5. 85.
 tar.
 
gz/*__;Lw!!CbU71lC5478d!PQG2f-qpzolvTEMMw0ilGWqdDBsGaYhVA-jquU1JJWgTwYB2s-Ufj0gDHfpQ_FIqwWs1jdhmY2SJyf-2$
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd

I've tried to install Tomcat, different version, like so :
/# Download the latest release of tomcat 10.1.5//
//wget
https://urldefense.com/v3/__https://downloads.apache.org/tomcat/tomcat-8/v8.5.85/bin/apache-tomcat-8.5.85.tar.gz/*__;Lw!!CbU71lC5478d!PQG2f-qpzolvTEMMw0ilGWqdDBsGaYhVA-jquU1JJWgTwYB2s-Ufj0gDHfpQ_FIqwWs1jdhmY2SJyf-2$ 
  


//
//# Create tomcat directory//
//sudo mkdir /opt/tomcat//
//
//# Extract the binary file with tar command in the /opt/tomcat path//
//sudo tar -xvf apache-tomcat-8.5.85.tar.gz -C /opt/tomcat
--strip-components=1//
//
//# Create a group called tomcat//
//sudo groupadd tomcat//
//
//# Set the following ownership and permissions to the /opt/tomcat //
//sudo chown -R jamiil /opt/tomcat//


that may be already the problem, as the tomcat user does not have 
permissions for the installation directories (log, work, temp)




//sudo sh -c 'chmod +x /opt/tomcat/bin/*.sh'//
//
//# Create a systemd file for Apache Tomcat//
//sudo gedit /etc/systemd/system/tomcat.service//
//
//[Unit]//
//Description=Tomcat webs servlet container//
//After=network.target//
//[Service]//
//Type=forking//
//User=tomcat//
//Group=tomcat//
//RestartSec=10//
//Restart=always//
//Environment="JAVA_HOME=/usr/lib/jvm/java-1.17.0-openjdk-amd64"//
//Environment="JAVA_OPTS=-Djava.awt.headless=true
-Djava.security.egd=file:/dev/./urandom"//
//Environment="CATALINA_BASE=/opt/tomcat"//
//Environment="CATALINA_HOME=/opt/tomcat"//
//Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"//
//Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server
-XX:+UseParallelGC"//
//ExecStart=/opt/tomcat/bin/startup.sh//
//ExecStop=/opt/tomcat/bin/shutdown.sh//
//[Install]//
//WantedBy=multi-user.target//
//
//
//# Reload all the unit files//
//sudo systemctl daemon-reload//
//
//# Start the Apache Tomcat daemon and enable it to start on system
startup.//
//sudo systemctl daemon-reload/

But, every time I try to start tomcat this happens

/sudo systemctl start tomcat/
*/Job for tomcat.service failed because the control process exited 
with

error code/*.
See "systemctl status tomcat.service" and "journalctl -xe" for 
details.



systemctl status tomcat.service reports

/● tomcat.service//
// Loaded: loaded (/etc/systemd/system/tomcat.service; disabled;
vendor preset: enabled)//
// Active: activating (auto-restart) (Result: exit-code) since Thu
2023-01-19 19:43:51 EST; 8s ago//
//Process: 5789 ExecStart=/opt/tomcat/bin/startup.sh
//*(code=exited, status=217/USER)*//
//CPU: 2ms/

and

journalctl -xe reports
/Hint: You are currently not seeing messages from other users and the
system.//


you need to run this with sudo right, as you don't see the service logs 
from other users


I agree with Niranjan, that it is in this early stage not nescessary to 
run tomcat as a service. Makes it far more complicated to get it 
running.


Run as a dedicated tomcat user is recommended, so run it with sudo -u 
tomcat /opt/tomcat/bin/startup.sh


Please consider separating CATALINA_HOME (installation) from 
CATALINA_BASE (config and dynamic data). That makes upgrading much 
easier.


see RUNNING.txt

Hope this helps

Peter

//  Users in groups 'adm', 'systemd-journal' can see all 
messages.//

//  Pass -q to turn off this notice.//
//Jan 19 19:38:06 arbolone sudo[5537]: pam_unix(sudo:session): session
opened for user root(uid=0) by (uid=1000)//
//Jan 19 19:38:06 arbolone sudo[5537]: pam_unix(sudo:session): session
closed for user root//
//Jan 19 19:38:12 arbolone gnome-software[1607]: Only 0 apps for 
recent

list, hiding//
//Jan 19 19:38:12 arbolone gnome-software[1607]: hiding category
graphics featured applications: found only 0 to show,>//
//Jan 19 19:38:12 arbolone gnome-software[1607]: hiding category
productivity featured applications: found only 0 to s>//
//Jan 19 19:38:12 arbolone gnome-software[1607]: automatically 
prevented

from changing kind on system/package/debian-s>//
//Jan 19 19:38:58 

Re: Prometheus on Apache Tomcat multiple tomcat Instances

[logo]

Melvin,


> Am 16.01.2023 um 14:52 schrieb Melvin Oosterveen 
> :
> 
> 
> Hi all,
> 
> I'm currently working on Apache Tomcat stacks within my company and I would 
> like to integrate Prometheus into our deployments. We have decided to go for 
> the Advanced Configuration - Multiple Tomcat Instances on UNIX systems 
> described in the RUNNING.txt.
> 
> Does anyone have some experience with the setup of the JMX Prometheus 
> exporter using multiple Tomcat instances? My goal is to have a separate Java 
> process (Prometheus) started when I start an Apache Tomcat instance.
> 

in my case the prometheus java agent is tied 1:1 to a tomcat process. In my 
understanding, that would mean 1 prometheus exporter per tomcat (each on a 
different port of course).


> So far I have downloaded the JMX 
> exporter and added it to the 
> created Tomcat Instance with a minimal Prometheus configuration.
> 

As per the github page jmxagent is the recommended way and not the standalone 
http server (which queries tomcat remotely on the jmx port).
Can you explain which one you are really trying to use?

> ```bash
> 
> [root@melvin prometheus]# cat config.yml
> 
> hostPort: localhost:

is tomcat listening on this port with jmx? You are trying to query jmx on this 
host on this port (your tomcat process). But did you start the prometheus 
exporter as a separate java process?
java -jar jmx_prometheus_httpserver-0.17.2.jar 12345 config.yaml
prometheus >> exporter:12345 >> tomcat: (jmx)
> 
> rules:
> 
> - pattern: ".*"
> 
> ```
> 

> I have created a service file which allows me to start the Apache Tomcat 
> instances separately from each other. Inside this configuration I tried to 
> start the Prometheus Java process, but so far I have failed and the Java 
> process won't expose itself on the configured port.
> ```bash
> 
> [root@melvin prometheus]# cat /etc/systemd/system/tomcat-10@.service
> 
> [Unit]
> 
> Description=Tomcat - instance %i
> 
> After=syslog.target network.target
> 
> 
> [Service]
> 
> Type=forking
> 
> 
> User=tomcat
> 
> Group=tomcat
> 
> 
> WorkingDirectory=/var/tomcat/%i
> 
> 
> Environment="JAVA_HOME=/etc/alternatives/jre_openjdk"
> 
> Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom 
> -Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml"

At this point you are using the jmxagent - inside the tomcat process. Then you 
MUST leave out the hostPort. Did you try to curl localhost:10080 ? 

prometheus >> tomcat:10080 >> internal jmx lookup
If you really want to use the external exporter, you will have to configure jmx 
in JAVA_OPTS instead to run on port . I'm not sure if the following is 
enough or too much:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port= 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

> Environment="CATALINA_PID=/var/tomcat/%i/run/tomcat.pid"
> 
> Environment="CATALINA_BASE=/var/tomcat/%i/"
> 
> Environment="CATALINA_HOME=/opt/tomcat/10/"
> 
> Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
> 
> 
> ExecStart=/opt/tomcat/10/bin/startup.sh
> 
> ExecStop=/opt/tomcat/10/bin/shutdown.sh
> 
> 
> #RestartSec=10
> 
> #Restart=always
> 
> 
> [Install]
> 
> WantedBy=multi-user.target
> 
> ```
> 
> The instance then starts without errors and starts my sample.war application 
> which I have downloaded from Apache.org. The initiated Java process is even 
> shown.
> ```bash
> 
> tomcat115910   1  0 Jan12 ?00:02:24 
> /etc/alternatives/jre_openjdk/bin/java 
> -Djava.util.logging.config.file=/var/tomcat/tomcat10//conf/logging.properties 
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
> -Djava.security.egd=file:///dev/urandom 
> -Djavaagent:/var/tomcat/tomcat10/lib/jmx_prometheus_javaagent-0.17.2.jar=10080:/var/tomcat/tomcat10/prometheus/config.yml
>  -Djdk.tls.ephemeralDHKeySize=2048 
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M -Xmx1024M 
> -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath 
> /opt/tomcat/10//bin/bootstrap.jar:/var/tomcat/tomcat10//bin/tomcat-juli.jar 
> -Dcatalina.base=/var/tomcat/tomcat10/ -Dcatalina.home=/opt/tomcat/10/ 
> -Djava.io.tmpdir=/var/tomcat/tomcat10//temp 
> org.apache.catalina.startup.Bootstrap start
> 
> ```
> 

> I wonder if anyone could help me out with the right setup of Prometheus on 
> Apache Tomcat multiple tomcat Instances.
> 

I would go the javaagent route and get one tomcat fixed - then all others will 
work easily. To get authentication right, put a haproxy (or an Apache httpd if 
it already exists) in front of your exporter, so you can limit queries to your 
prometheus host.

> Thanks in advance,
> 
> Melvin Oosterveen


Hope this helps.

Peter

Re: certificate re-loading for apache tomcat without the apache restart

[logo]

Raghavendran,

> Am 26.09.2022 um 08:54 schrieb Ragavendhiran Bhiman (rabhiman) 
> :
> 
> Hi All,
> 
> I have a scenario where I need to reload the certificates which are newly 
> updated in the NSS DB without restarting the apache – tomcat.
> Is there any way to do it?
> 
> Kindly share some piece of code to achieve the reloading of the certificates 
> without restarting the apache tomcat service itself.
> 
> 

curl -u  -p  
"https://myserver.mydomain/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port==reloadSslHostConfig="

you need that  with at least roles="manager-jmx" in tomcat-users.xml


> 
> Note : Trial from my side : Tried to restart the Apache connector, but still 
> it is reloading the old certificates only and not the new certificates.
> If possible how to achieve the loading of the new one?
> 
> 
> Many Thanks for your help.
> 
> Regards,
> 
> Raghavendran
> 

Hope this helps

Peter

Re: Simple SSL question

[logo]

Jon,

I extracted a part of my test-server.xml. This for the JSSE Implementation.


   
   
  
   
   
  
  
   


If you have separate crt and key files in pem-format the Certificate-section 
looks like this:



We could start from there - I have no "old style" config to match against.


Peter



> Am 11.08.2022 um 23:10 schrieb jonmcalexan...@wellsfargo.com.invalid 
> :
> 
> Peter,
> 
> Yes, that WOULD be a good thing. That and some examples of implementing the 
> new COOL stuff like configure TLS virtual hosting with SNI, would be very 
> helpful.
> 
> 
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Senior Infrastructure Engineer
> Asst. Vice President
> He/His
> 
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> 
> 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.
> 
> 
>> -Original Message-
>> From: Peter Kreuser 
>> Sent: Thursday, August 11, 2022 4:00 PM
>> To: Tomcat Users List 
>> Subject: Re: Simple SSL question
>> 
>> 
>> Jon and Chris,
>> 
>> 
>>> Am 11.08.2022 um 19:33 schrieb Christopher Schultz
>> :
>>> 
>>> Jon,
>>> 
 On 8/11/22 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:
 I was just wondering if there was a vanity name for the "new" structure is
>> all, to differentiate in documentation.
>>> 
>>> *shrug*
>>> 
>>> "New"?
>>> 
>>> That kind of loses its lustre after a while. Today, that's just "the way 
>>> you do
>> it". So the "new" way is The Way and the old way is ... the Old Way.
>>> 
>>> Use SSLHostConfig. I'm sure you'll sleep better at night after you've
>> switched.
>>> 
>>> -chris
>>> 
> -Original Message-
> From: Christopher Schultz 
> Sent: Thursday, August 11, 2022 11:29 AM
> To: users@tomcat.apache.org
> Subject: Re: Simple SSL question
> 
> Jon,
> 
> On 8/11/22 11:22, jonmcalexan...@wellsfargo.com.INVALID wrote:
>> Is there a "name" for the new connector style? The old is known as
>> the Coyote Connector.
> Coyote is just the name of the connector itself, for whatever reason.
> Both the new and old-style configuration is using the same connector
> underneath. When you configure everything on the ,
>> Tomcat
> still creates an SSLHostConfig object under the covers and fills it
> with that same data.
> 
> Why should you bother migrating? Two reasons:
> 
> 1. The new configuration is easier to read IMO. It separates the TLS
> host/key/certificate and all that associated stuff from the more
> basic socket- type stuff for the 
> 
> 2. It allows for more options such as proper name-based
> virtual-hosting with TLS. It also allows multiple types of keys and
> certificates to be used. For example, you can configure both RSA and EC
>> certificates for a single host.
> That's just not possible with the one-attribute-to-rule-them-all
> configuration where everything is on the  element.
> 
>> 
>> I have tried all the fancy new cert options and they are cool.
>> 
>> And I do agree that it's more readable.
>> 
>> What would be useful would be one sample how to transfer a simple "old"
>> config to SSLHostConfig.
>> That would take away the fear to get going. In another thread I said, that it
>> may be a lot of work to migrate a lot of tomcat instances. But I guess most
>> people would only need a single SSLHostConfig  to add to their one
>> connector...
>> 
>> Peter
> -chris
> 
>>> -Original Message-
>>> From: Mark Thomas 
>>> Sent: Wednesday, August 10, 2022 2:43 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: Simple SSL question
>>> 
>>> On 10/08/2022 19:22, jonmcalexan...@wellsfargo.com.INVALID
>> wrote:
 Ok, I'm asking a rather simple, stupid (in my opinion) question,
 but here
>>> goes:
 
 What is the best practice form of connector for SSL. Is it the
 old-school
>>> coyote connector or the connector with the 
>> section?
>>> 
>>> 
>>> 
>>> The old style isn't supported in Tomcat 10.0.x onwards.
>>> 
 Are the two interchangeable, or does the SSLHostConfig one rely
 on
>>> openssl and won't work without it? The documentation is confusing
>>> me on a hump day afternoon.
>>> 
>>> They are interchangeable. However, if you want to configure TLS
>>> virtual hosting with SNI you'll need to use SSLHostConfig.
>>> 
>>> Both 

Re: AW: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"

[logo]

Thomas,

Am 2022-08-10 08:59, schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,


-Ursprüngliche Nachricht-
Von: Peter Kreuser 
Gesendet: Mittwoch, 10. August 2022 08:44
An: Tomcat Users List 
Betreff: Re: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have
sslProtocol="TLSv1.2"



James,

the most recent connector attribute is "protocols". The documentation 
is a bit
vague on this saying there is an overlap between the two, yet I don't 
know if the

overlap is there if protocols is unset and defaults to "all"
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support

Peter

> Am 10.08.2022 um 00:15 schrieb James H. H. Lampert
:
>
> I think this may have come up before, but I don't recall how it was resolved.
>
> On customer box #1, I have:
>maxThreads="400" SSLEnabled="true" scheme="https" secure="true"
>   keystoreFile="/tomcat/wttomcat.ks"
keyAlias=""
>
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WI
TH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
>   clientAuth="false" sslProtocol="TLSv1.2" />
>
> and an SSLLabs scan shows it accepting only TLSv1.2, as it should.
>
> But on customer box #2, I have:
>
>maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>   keystoreFile="/tomcat/wttomcat.ks"
keyAlias=""
>   clientAuth="false" sslProtocol="TLSv1.2" />
>
> and an SSLLabs scan shows it accepting TLSv1.0, TLSv1.1, and TLSv1.2.
>
> What could be wrong here? I vaguely recall seeing something like this before.
>
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


I have configured my connector as follows:
protocol="org.apache.coyote.http11.Http11NioProtocol"


sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
   maxThreads="150" minSpareThreads="25"
   URIEncoding="UTF-8" useBodyEncodingForURI="false"
   enableLookups="false" disableUploadTimeout="true"
   acceptCount="100" scheme="https" secure="true"
   SSLEnabled="true"
   compression="off" >






This gives a good grade when checking with ssllabs.
Only TLS 1.2 and 1.3 are enabled.



of course SSLHostConfig is the modern and preferred way. But unless you 
have plenty of time, it's a hassle to migrate many boxes to the new 
way...


Peter


Greetins, Thomas

-
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: Need remedy for the Vulnabilities

[logo]

Koustav,

Am 2022-07-19 11:49, schrieb Naha, Koustav:

Hi,


We have the below vulnerability in recent scan, mentioned below.



Environment details:


Apache - 2.4.25 version



Tomcat - 8.5.5 version





given the age of the versions I guess you only have the option to update 
to the latest versions.


How did you install those? If they come from the package list of your 
OS, do the update from there.

But Tomcat can be easily installed from tar or zip.
You should review changes in config from 8.5.5 to 8.5.6x. In the long 
time things may have changed a bit, though not severly.
For Apache httpd that may be different and you should check on their 
mailing list.




Can anyone take a look at the CVEs associated with the scan findings
and see if there are workarounds, rather than upgrading.



There aren't any workarounds that cover ALL of the vulnerabilities. Plus 
it seems less costly to upgrade instead of review each and every CVE.


My 2cts

Peter


CVE-2022-26377
Inconsistent Interpretation of HTTP Requests ('HTTP Request
Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server
allows an attacker to smuggle requests to the AJP server it forwards
requests to. This issue affects Apache HTTP Server Apache HTTP Server
2.4 version 2.4.53 and prior versions.
CVE-2017-7679
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime
can read one byte past the end of a buffer when sending a malicious
Content-Type response header.
CVE-2022-0778
The BN_mod_sqrt() function, which computes a modular square root,
contains a bug that can cause it to loop forever for non-prime moduli.
Internally this function is used when parsing certificates that
contain elliptic curve public keys in compressed form or explicit
elliptic curve parameters with a base point encoded in compressed
form. It is possible to trigger the infinite loop by crafting a
certificate that has invalid explicit curve parameters. Since
certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate
may thus be subject to a denial of service attack. The infinite loop
can also be reached when parsing crafted private keys as they can
contain explicit elliptic curve parameters. Thus vulnerable situations
include: - TLS clients consuming server certificates - TLS servers
consuming client certificates - Hosting providers taking certificates
or private keys from customers - Certificate authorities parsing
certification requests from subscribers - Anything else which parses
ASN.1 elliptic curve parameters Also any other applications that use
the BN_mod_sqrt() where the attacker can control the parameter values
are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the
public key is not parsed during initial parsing of the certificate
which makes it slightly harder to trigger the infinite loop. However
any operation which requires the public key from the certificate will
trigger the infinite loop. In particular the attacker can use a
self-signed certificate to trigger the loop during verification of the
certificate signature. This issue affects OpenSSL versions 1.0.2,
1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on
the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1).
Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL
1.0.2zd (Affected 1.0.2-1.0.2zc).
CVE-2020-1934
In Apache HTTP Server 2.4.0 to 2.4.41, mod_proxy_ftp may use
uninitialized memory when proxying to a malicious FTP server.
CVE-2018-17189
In Apache HTTP server versions 2.4.37 and prior, by sending request
bodies in a slow loris way to plain resources, the h2 stream for that
request unnecessarily occupied a server thread cleaning up that
incoming data. This affects only HTTP/2 (mod_http2) connections.
CVE-2017-9798
Apache httpd allows remote attackers to read secret data from process
memory if the Limit directive can be set in a user's .htaccess file,
or if httpd.conf has certain misconfigurations, aka Optionsbleed. This
affects the Apache HTTP Server through 2.2.34 and 2.4.x through
2.4.27. The attacker sends an unauthenticated OPTIONS HTTP request
when attempting to read secret data. This is a use-after-free issue
and thus secret data is not always sent, and the specific data depends
on many factors including configuration. Exploitation with .htaccess
can be blocked with a patch to the ap_limit_section function in
server/core.c.
CVE-2019-10082
In Apache HTTP Server 2.4.18-2.4.39, using fuzzed network input, the
http/2 session handling could be made to 

Re: enabling ssl debug on tomcat

[logo]

Shawn,


> Am 06.06.2022 um 22:49 schrieb Beard, Shawn :
> 
> Im adding this -Djavax.net.debug=ssl:handshake:verbose 
> SSLSocketClientWithClientAuth
>  

I assume that you copied this from the SSL-Samples App (where the class file is 
SSLSocketClientWithClientAuth).

You have to add only -Djavax.net.debug=ssl:handshake:verbose to CATALINA_OPTS 
(or JAVA_OPTS).

Peter

> To the java options of Tomcat, however the SSLSocketClientWithClientAuth is 
> causing tomcat not start saying it cant find the 
> SSLSocketClientWithClientAuth class. I need to debug socket issues on a ssl 
> client connection. Any ideas?
>  
>  
>  
>  
> Shawn Beard • Sr. Systems Engineer
> Middleware Engineering
> 
> 
>  3840 109th Street Urbandale, IA 50322
>  Phone: +1-515-564-2528
>  Email: sbe...@wrberkley.com 
>  Website: berkleytechnologyservices.com 
> 
> Technology Leadership Unleashing Business Potential
>  
>  
> 
> Shawn​Beard
> Sr. Systems Engineer   | 
> BTS
> Middleware Engineering |  +1-515-564-2528
>  |  sbe...@wrberkley.com 
> 
>  
> CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
> private, privileged and confidential information belonging to the sender. The 
> information therein is solely for the use of the addressee. If your receipt 
> of this transmission has occurred as the result of an error, please 
> immediately notify us so we can arrange for the return of the documents. In 
> such circumstances, you are advised that you may not disclose, copy, 
> distribute or take any other action in reliance on the information 
> transmitted.

Re: Catalina.policy for SAP BO

[logo]

Oscar,

> Am 11.05.2022 um 10:14 schrieb Chavez Ortiz, Oscar (Externo) 
> :
> 
> Hello group.
> 
> Our system is a SAP Business Object 4.2 server wich uses Tomcat 9.0.58 as web 
> container.
> 
> We’re implementing Security Hardening for Tomcat in our BO Server server, 
> thus, i’ve configured starting configuration in java options with “– Security 
> Manager” option.
> 

as an InfoSec and OpSec Manager in my company and a hardening fetishist I would 
recommend to review the recent comments of Marc...

In you situation I'd try to dispute the need for the implementation of Tomcat 
with Security Manager and focus on the hardening of the underlying OS/machine 
and used services. That would lead to a more substantial and durable result.

Java Security Manager has been a pain for a long time and if you don't want to 
put effort in now and then after every update of BO (or any other software), 
don't do it.

In my opinion the requirements of your hardening guidelines may be not 
appropriate for the risk level of your application (SAP BO vs. health data in 
hospitals eg). In our company I would go with a risk acceptance or even change 
the requirements - if I read about the future removal of the security manager 
functionality.


Just my 2ct.

Peter

> Now, the problem is when opening SAP BO Launch Pad tool in web browser i’m 
> gettint the HTTP 500 error.
> 
> I think that the catalina.policy file isn’t accordingly configurated and 
> there are some permissions left that aren’t implemented.
> 
> My request is: If you have any template of catalina.policy that implements 
> Security Manager for SAP BO and you can share it i’d compare it against the 
> ours one.
> 
> SAP Support said that Tomcat is not part of their duties because it’s a third 
> software.
> 
> Thank you in advance.
> Best regards.
> Oscar.
> AVISO LEGAL
> 
> Este mensaje y su contenido está dirigido únicamente a su destinatario y es 
> confidencial. Por ello, se informa a quien lo reciba por error o tenga 
> conocimiento del mismo sin ser su destinatario, que la información contenida 
> en él es reservada y su uso no autorizado, por lo que en tal caso le rogamos 
> nos lo comunique por la misma vía o por teléfono 91.427.99.03, así como que 
> se abstenga de reproducir el mensaje mediante cualquier medio o remitirlo o 
> entregarlo a otra persona, procediendo a su destrucción de manera inmediata.
> 
> VOLKSWAGEN RENTING SA se reserva las acciones legales que le correspondan 
> contra todo tercero que acceda de forma ilegítima al contenido de cualquier 
> mensaje externo procedente del mismo.
> 
> VOLKSWAGEN FINANCIAL SERVICES es una marca comercializada por Volkswagen 
> Renting SA
> 
> Se le informa que sus datos personales son tratados por Volkswagen Renting 
> S.A., con domicilio social en Avda. de Bruselas, nº 34, 28108, Alcobendas 
> (Madrid).
> 
> Ud. podrá ejercitar los derechos de acceso, rectificación o supresión, 
> oposición y portabilidad de los datos, bien por correo postal a VOLKSWAGEN 
> RENTING S.A. a la dirección indicada arriba o por correo electrónico a 
> clientes.rent...@vwfs.com. Asimismo, y en 
> las mismas direcciones, Ud. podrá solicitar la limitación del tratamiento de 
> sus datos en los casos legalmente previstos. Igualmente, puede contactar con 
> nuestro Delegado de Protección de Datos en la siguiente dirección 
> dpo...@vwfs.com. Asimismo, podrá dirigirse a la 
> Agencia Española de Protección de Datos.
> 
> -
> 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: handling invalid URL

[logo]

> Am 02.04.2022 um 10:04 schrieb l...@kreuser.name:
> 
> Joe,
> 
>> Am 02.04.2022 um 00:53 schrieb Joseph Michaud :
>> 
>> As I understand it, an ErrorReportValve is an application-level filter. An 
>> HTTP request error (like an unknown URL) that reaches it will be processed. 
>> With the ErrorReportValve I can modify the information presented in the 
>> report. However, an *invalid* URL is not assignable to any application. No 
>> ErrorReportValve would apply to it.
>> 
>> An invalid URL generates a 400 response. In Tomcat 8.5, there was no error 
>> report included in that response. In Tomcat 9.0, the default error report is 
>> included. The default error report includes Tomcat version information. Some 
>> security-conscious customers don't want version information displayed but 
>> now, with Tomcat 9.0, I cannot remove that information.
>> 
>> I think the answer is 'no', but I'll ask anyway Is there a global-level 
>> ErrorReportValve capability? Or some facility to easily remove the version 
>> information from an 'invalid URL' error report? (I'm aware of modifying the 
>> ServerInfo.properties file, but that affects more than just the error 
>> report...)
>> 
> 
> this goes in server.xml like this
> 
>  unpackWARs="false" autoDeploy="false" deployXML="true">
> 
>  showReport="false" showServerInfo="false" />
> 
> 
> 
> you may also add 
> errorReportValveClass="com.logo.tomcat.valves.CustomErrorReportValve" to the 
> host attributes.
> 

to add your own ErrorReportValve I wanted to add :-)

> Hope this helps
> 
> Peter
> 
>> Joe
>> 
>> We hope you found this email of interest; however, click here if you wish to 
>> unsubscribe
>>  or manage your email preferences. Privacy 
>> Policy.
>> 
>> Disclaimer
>> 
>> The information contained in this communication from the sender is 
>> confidential. It is intended solely for use by the recipient and others 
>> authorized to receive it. If you are not the recipient, you are hereby 
>> notified that any disclosure, copying, distribution or taking action in 
>> relation of the contents of this information is strictly prohibited and may 
>> be unlawful.

Re: handling invalid URL

[logo]

Joe,

> Am 02.04.2022 um 00:53 schrieb Joseph Michaud :
> 
> As I understand it, an ErrorReportValve is an application-level filter.  An 
> HTTP request error (like an unknown URL) that reaches it will be processed.  
> With the ErrorReportValve I can modify the information presented in the 
> report.  However, an *invalid* URL is not assignable to any application.  No 
> ErrorReportValve would apply to it.
> 
> An invalid URL generates a 400 response.  In Tomcat 8.5, there was no error 
> report included in that response.  In Tomcat 9.0, the default error report is 
> included.  The default error report includes Tomcat version information.  
> Some security-conscious customers don't want version information displayed 
> but now, with Tomcat 9.0, I cannot remove that information.
> 
> I think the answer is 'no', but I'll ask anyway Is there a global-level 
> ErrorReportValve capability?  Or some facility to easily remove the version 
> information from an 'invalid URL' error report?  (I'm aware of modifying the 
> ServerInfo.properties file, but that affects more than just the error 
> report...)
> 

this goes in server.xml like this

  



  

you may also add 
errorReportValveClass="com.logo.tomcat.valves.CustomErrorReportValve" to the 
host attributes.

Hope this helps

Peter

> Joe
> 
> We hope you found this email of interest; however, click here if you wish to 
> unsubscribe
>  or manage your email preferences. Privacy 
> Policy.
> 
> Disclaimer
> 
> The information contained in this communication from the sender is 
> confidential. It is intended solely for use by the recipient and others 
> authorized to receive it. If you are not the recipient, you are hereby 
> notified that any disclosure, copying, distribution or taking action in 
> relation of the contents of this information is strictly prohibited and may 
> be unlawful.
> 

Re: Issue running Tomcat-8.5.72 with JDK15 under windows as a service

[logo]

Hi Jean Pierre,


Am 2021-10-19 14:57, schrieb Jean-Pierre Urkens:
I am verifying a migration from JDK8 to JDK15 and wanted to setup a 
Tomcat
8.5 server environment for this test (similar to the Tomcat8.5 with 
JDK8

we have running for the moment).


certainly not related to your problem, but why are you trying an EOL 
version?


Java 15 is out of support since September 2020. Java 17 is out now and 
the new LTS version.


Just my 2cts.

Peter


I installed the instance as a service under my local (test) windows
environment and configured the JVM  through the java tab. When starting
the service the tomcat deamon fails with:

   CreateJavaVM Failed with error [-6], The system cannot find the
file specified.

References on the net seem to indicate that the problem is with the JVM
setting but the location ' C:\Program
Files\Java\jdk-15.0.1\bin\server\jvm.dll' is correct.
Below the daemon log which shows all JVM options and -D environment
variables set:

[2021-10-19 14:35:23] [debug] ( prunsrv.c:1892) [61340] Apache Commons
Daemon procrun log initialized.
[2021-10-19 14:35:23] [info]  ( prunsrv.c:1896) [61340] Apache Commons
Daemon procrun (1.2.4.0 64-bit) started.
[2021-10-19 14:35:23] [info]  ( prunsrv.c:1806) [61340] Running Service
'T8N6'...
[2021-10-19 14:35:23] [debug] ( prunsrv.c:1577) [59044] Inside
ServiceMain...
[2021-10-19 14:35:23] [debug] ( prunsrv.c:1032) [59044]
reportServiceStatusE: dwCurrentState = 2, dwWin32ExitCode = 0, 
dwWaitHint

= 3000, dwServiceSpecificExitCode = 0.
[2021-10-19 14:35:23] [info]  ( prunsrv.c:1325) [59044] Starting
service...
[2021-10-19 14:35:23] [debug] ( prunsrv.c:496 ) [59044] Checking Java
options for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Dcatalina.home=f:\Tools\apache-tomcat-8.5.72' for environment 
variable

requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Dcatalina.base=f:\Tools\apache-tomcat-8.5.72\nodes\node6' for
environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Dprofile=local' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Dspring.profiles.active=local' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djava.endorsed.dirs=' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djava.io.tmpdir=f:\Tools\apache-tomcat-8.5.72\nodes\node6\temp' for
environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager' for
environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djava.util.logging.config.file=f:\Tools\apache-tomcat-8.5.72\nodes\node6
\conf\logging.properties' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.inte
rnal.jaxp.DocumentBuilderFactoryImpl' for environment variable
requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.j
axp.SAXParserFactoryImpl' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.interna
l.xsltc.trax.TransformerFactoryImpl' for environment variable 
requirements

[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djdk.tls.ephemeralDHKeySize=2048' for environment variable 
requirements

[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djdk.tls.useExtendedMasterSecret=false' for environment variable
requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djdk.tls.allowLegacyResumption=true' for environment variable
requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Djdk.tls.allowLegacyMasterSecret=false' for environment variable
requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Xms512m' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-Xmx1024m' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-XX:CompileThreshold=8000' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-XX:+UseConcMarkSweepGC' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-XX:+CMSParallelRemarkEnabled' for environment variable requirements
[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking
'-XX:+UseCMSInitiatingOccupancyOnly' for environment variable 
requirements

[2021-10-19 14:35:23] [debug] ( prunsrv.c:500 ) [59044] Checking

Re: Connector Port Issue

[logo]

Chris,

> Am 11.08.2021 um 16:40 schrieb Chris Strickland 
> :
> 
> 
> Anyone happen to know where in the server.xml file the attributes go for 
> clientAuth and sslEnabledProtocols?

They goes in "protocols" and  "certificateVerification" attributes of 
SSLHostConfig.

Like this:



 


> I'm running Tomcat 10. Seems like I tried putting them under everything 
> (Connector, SSLHostConfig, Certificate) but still get the warning in the 
> logs: failed to set property.
> Thanks,ChrisOn Thursday, August 5, 2021, 03:37:54 PM EDT, Peter Kreuser 
>  wrote:  
> 
> Chris,
> 
>> Am 05.08.2021 um 18:32 schrieb Rob Sargent :
>> 
>> 
>>> Caused by: java.lang.IllegalArgumentException: No SSLHostConfig 
>>> element was found with the hostName [_default_] to match the 
>>> defaultSSLHostConfigName for the connector [https-jsse-nio-9443]
>>> 
>> 
> 
> The ssl-Options are not attributes on the connector, but the SSLHostConfig
> 
> http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#Common_Attributes
> 
> http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
> 
> Peter
> 
>> Isn’t that the real issue?
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 

Re: Trouble with HTTP/2 during concurrent bulk data transfer (server -> client)

[logo]

Magic Mark,

> Am 17.06.2021 um 23:20 schrieb Mark Thomas :
> 
> On 17/06/2021 09:26, Mark Thomas wrote:
> 
>> I think I might have found one contributing factor to this bug. I need to 
>> run a series of tests to determine whether I am seeing random variation in 
>> test results or a genuine effect.
> 
> It was random effects but I believe I have now found the bug.
> 
> Consider two threads, T1 and T2 writing HTTP/2 response bodies concurrently 
> in the same HTTP/2 Connection.
> 
> You'll need to have the code in front of you to follow what is going on
> 
> The write:
> 
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SocketWrapperBase.java#L1364
> 
> and the associated completion handler
> 
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/SocketWrapperBase.java#L1044
> 
> 
> The detail of the code is fairly complex but all you really need to keep in 
> mind is the following:
> 
> - the writePending semaphore ensures only one thread can write at a time
> 
> - the state of the write is maintained in a OperationState instance that is 
> stored in SocketWrapperBase.writeOperation (L1390)
> 
> - the completion handler clears this state (L1050) and releases the
>  semaphore (L1046)
> 
> 
> The sequence of events for a failure is as follows:
> 
> - T1 obtains the write semaphore (L1366)
> - T1 creates an OperationState and sets writeOperation (L1390)
> - the async write for T1 completes and the completion handler is called
> - T1's completion handler releases the semaphore (L1046)
> - T2 obtains the write semaphore (L1366)
> - T2 creates an OperationState and sets writeOperation (L1390)
> - T1's completion handler clears writeOperation (L1050)
> - the async write for T2 does not complete and the socket is added to
>  the Poller
> - The Poller signals the socket is ready for write
> - The Poller finds writeOperation is null so performs a normal dispatch
>  for write
> - The async write times out as it never receives the notification from
>  the Poller
> 
> The fix is to swap the order of clearing writeOperation and releasing the 
> semaphore.
> 
> Concurrent reads will have the same problem and will be fixed by the same 
> solution.
> 

Thread handling and synchronizing at the max!

Thanks for the insight and your hard work finding this!


> Fix will be applied shortly.
> 
> Mark
> 
> -
> 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: [OT] programming style or mental process ?

[logo]

Guten Morgen Carsten and All

> Am 08.04.2021 um 07:20 schrieb Carsten Klein :
> 
> 
>> (And dutch people. Where are they in this discussion by the way ? (but they 
>> have only one type of coffee I think)).
> 
> Dutch people may only have one type of coffee (actually I don't know). But 
> remember, Dutch people have 'Coffee Shops' offering stuff far beyond 
> coffee... :) Is there a relation between that and usage of Yoda style?
> 
> Germans used to drink so called 'filter coffee' for decades, which today, 
> even if served hot, many people would call 'cold coffee' ('kalter Kaffee' in 
> German), an idiom that could be translated to English as 'an old hat').
> 
> Now, thanks to companies like De'Longhi or Seaco (which is now owned by 
> Philips and so is actually Dutch), most of us prefer Italian coffee types 
> like Espresso, Cappuccino or Latte Macchiato.
> 
> 

I may add, that a French Café au lait (pronounced Olé, which is not French :-O 
) is also an option.

Peter

> -
> 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: How to completely deactivate JSESSIONID cookie entry (in Chrome's Cookie list)

[logo]

Hi Tillmann,

Am 2021-01-29 11:00, schrieb Tillmann Schulz:

Hi there,

I am using Tomcat 8.5.58 and have a problem with JSESIONID cookie.
It should be possible to completly deactivate the jsessionid cookie
with the following code:

<%@ page session="false" %>

If you do that and call the JSP, there is in no entry under cookies in
google chrome's cookie list (if you press F12 in chrome) .
But in chrome's cookie list there is a host entry for the hostname of 
the JSP.

This is confusing, because there are no cookies set.

I am not sure if this is a tomcat issue, but under firefox it also
looks simular.

Is it possible to completly deactivate cookies? There shouldn't be any
hostname visible in the cookie view.

I doubt that this is a matter of the usage of cookies. That's default 
behaviour of the browser, that will create that per site. Go to a site 
that does not use sessions (and tomcat) and it will have that entry.


Peter


Thank you for your help in advance

Tillmann


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

Re: Let's encrypt SSL config

[logo]

Hi Ivan,



> Am 07.01.2021 um 20:42 schrieb i...@wordme.app:
> 
> Hi,
> 
> It drives me nuts now.
> 
> I have created sym links to the PEM files. I made the PEM files readable for
> the tomcat user. I set the server.xml to use SSL. And the connector fails to
> start.
> 
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> 
>  maxThreads="200"
> 
>  scheme="https"
> 
>  secure="true"
> 
>  SSLEnabled="true"
> 
>  clientAuth="false"
> 
>  sslProtocol="TLS"
> 
> 
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementat
> ion"
> 
>  defaultSSLHostConfigName="mydomain.com"
> 
>> 
> 
>protocols="+TLSv1,+TLSv1.1,+TLSv1.2">
> 
>
>   certificateKeyFile="conf/privkey.pem"
> 
>   certificateFile="conf/cert.pem"
> 
>   certificateChainFile="conf/chain.pem"
> 
>   type="UNDEFINED"
> 
>   />
> 
>   
> 
>   
> 
> 

Maybe want to try an absolute path like so: ${catalina.base}/conf/ or 
${catalina.home}/conf/ ?

Peter
> 
> I did try to change the type to RSA, to no avail. All I see in the log is:
> 
> 02-Jan-2021 17:40:54.398 INFO [main] org.apache.coyote.AbstractProtocol.init
> Initializing ProtocolHandler ["https-openssl-nio-8443"]
> 
> 02-Jan-2021 17:40:54.466 SEVERE [main]
> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> initialize component [Connector[HTTP/1.1-8443]]
> 
>   org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> 
>   at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1013)
> 
>   ... some lines removed
> 
>   at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
> 
>   Caused by: java.lang.IllegalArgumentException
> 
>   at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
> eEndpoint.java:99)
> 
>   ... some lines are removed
> 
>   at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
> 
>   ... 13 more
> 
>   Caused by: java.io.IOException
> 
>   at
> org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:302)
> 
>   at
> org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.ja
> va:98)
> 
>   at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
> )
> 
>   at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
> eEndpoint.java:97)
> 
>   ... 20 more
> 
> 
> 
> I've checked the SSLUtilBase.java code (tomcat 9.0.33):
> 
>   if (certificate.getCertificateFile() == null) {
> 
>   throw new IOException(sm.getString("jsse.noCertFile"));
> 
>   }
> 
> 
> 
> I did try to copy the files instead of using sym links. No avail. Removed
> the comments from the cert files. No avail. It seems tomcat cannot find the
> files I've specified in the server.xml.
> 
> What do I miss?
> 
> 
> 
> Best Regards,
> 
> Ivan

Re: Recognizing Certificate Updates

[logo]

Jerry,

the quotes were messed up.

See the correct command below inline.

> Am 28.12.2020 um 11:10 schrieb logo :
> 
> Jerry,
> 
> Try this after regenerating the LE certs
> 
> curl -u  
> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs
>  
> <https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs>"
> 
> for all domains or
> 
> curl -u  
> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=  to reload>"
> 
> for just the needed domain.
> 
> Adjust the port to your SSL-Connector.
> 
> Add a  to tomcat-users.xml
>
> 
> Beware not to open the Manager App to the public - just localhost. 
> 
> HTH
> 
> Peter
> 
> 
>> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :
>> 
>> We have a production environment where we rarely reboot Tomcat. LetsEncrypt 
>> auto-updates the certificates every couple of months. But the new 
>> certificates are not loaded into Tomcat.  So when the original expiration 
>> date of the certs arrives, users get "certificate expired" even though new 
>> certs exist.  A simple reboot to load the new certs fixes it.  But we want 
>> to avoid reboots.  Are there any config parameters that tell TC to check for 
>> cert updates and reload the new certs?  Thx
>> 
>> 
>> -
>> 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: Recognizing Certificate Updates

[logo]

Jerry,

Try this after regenerating the LE certs

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs“

for all domains or

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=“

for just the needed domain.

Adjust the port to your SSL-Connector.

Add a  to tomcat-users.xml


Beware not to open the Manager App to the public - just localhost. 

HTH

Peter


> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :
> 
> We have a production environment where we rarely reboot Tomcat. LetsEncrypt 
> auto-updates the certificates every couple of months. But the new 
> certificates are not loaded into Tomcat.  So when the original expiration 
> date of the certs arrives, users get "certificate expired" even though new 
> certs exist.  A simple reboot to load the new certs fixes it.  But we want to 
> avoid reboots.  Are there any config parameters that tell TC to check for 
> cert updates and reload the new certs?  Thx
> 
> 
> -
> 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 v9 - Insecure transport vulnerability reported by Qualys

[logo]

Pratik,


> Am 26.08.2020 um 06:52 schrieb Pratik Shrestha :
> 
> Thanks for reply,
> 
> Hi Peter - it complains on port 8443 which belongs to Tomcat.
> 
> Hi Mark - Yes. making HTTP request on HTTPS is wrong. But this security 
> vulnerability is given to us by Qualys scan. It tries to post plain HTTP 
> request on HTTPS port and then gets error message "Bad Request. This 
> combination of host and port requires TLS." which is security loop hole for 
> Qualys. This is behaviour of Apache HTTP server also. But in Apache though, 
> we can get rid of this by using "ErrorDocument 400" directive. Do we have 
> similar in Tomcat? I have already tried using 
> 
> 
>400
>/error.jsp
>  
> 

I see an error 400 on 8443 (8.5.57). As it is on Nginx or Apache. So I don’t 
see why this would be a problem. False Positive one could address with Qualys?

Regards

Peter

> Not sure, but my idea was to add redirect code on error.jsp page. But above 
> never works. It never reaches error.jsp page. Just sticks in default error 
> message page mentioned above.
> 
> Btw..you can see the result from Qualys attached.  
> 
> Thanks again guys for getting back.
> 
> Regards,
> Pratik 
> 
> On Tue, Aug 25, 2020 at 5:36 PM Mark Thomas  > wrote:
> On 25/08/2020 11:14, Pratik Shrestha wrote:
> > Hi all,
> > 
> > Tomcat version: 9.0.37
> > 
> > Our website is running on Tomcat. We did Qualys vulnerability scan on our
> > site. Scan shows below vulnerability.
> > 
> > Insecure transport
> > Group: Information Disclosure
> > CWE CWE-319
> > OWASP A3 Sensitive Data Exposure
> > WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> > 
> > Please note
> > 1. HTTP port is not enabled.
> > 2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
> > with HTTP (http://www.oursite.com:8443/ ), we 
> > get an error "Bad Request. This
> > combination of host and port requires TLS."
> > 3. Due to the above error message, we get this vulnerability error from
> > Qualys.
> > 4. We have already enabled HSTS.
> > 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> > never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
> > finds someone is accessing HTTPS port with HTTP protocol and then just
> > throws error 400 'Bad Request'
> > 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
> > should still be okay.
> > 
> > We already tried to find the fix for this issue on the web but in vain.
> > 
> > Kindly help if anyone has found a way to fix it.
> 
> Fix what?
> 
> If you make an HTTP request to an HTTPS port, Tomcat provides a helpful
> error message.
> 
> I don't see any security issues here.
> 
> (And before anyone claims the request sent in the clear is insecure I'll
> point out that the request is sent in the clear irrespective of whether
> Tomcat responds with an HTTP/1.1 clear text error message or a cryptic
> TLS failure).
> 
> Mark
> 
> -
> 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: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

[logo]

Chris

> Am 21.08.2020 um 18:30 schrieb Christopher Schultz 
> :
> 
> Signierter PGP-Teil
> James,
> 
> On 8/18/20 19:47, James H. H. Lampert wrote:
> > Something just worked, that I wasn't expecting to work. Or rather,
> > I was expecting it to work, but kill cert renewal.
> >
> > The port 80 virtual host had
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI}
> >> [R=301,L]
> >
> > which I commented out, because https for that virtual host is a
> > pure front-end for Tomcat, and of course, Certbot needs to stick
> > something on the server that Let's Encrypt is expecting to be able
> > to find.
> >
> > So a few minutes ago, just for test purposes, I uncommented the
> > above lines. Initially, it didn't work (it redirected the browser
> > from http://foo.bar.com to a nonexistent https://www.foo.bar.com),
> > but when I removed the "www" in the RewriteRule, changing the block
> > to
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
> >
> > it worked just fine.
> >
> > So then, I did a "certbot renew --force-renewal" (expecting it to
> > fail on the relevant cert, but in fact, it renewed just fine.
> >
> > Not to look a gift equine in the masticatory orifice, but what am
> > I missing here? What went right, when I was expecting it to go
> > wrong? Why didn't the "rewrite" lines break renewal?
> 
> Why would you think that redirecting from http -> https would block
> renewal?
> 

From my experience I have excluded .well-known from the redirect.

LE will request initially on port 80.

And if the cert hast expired it may  be happier when renewing on port 80.

Peter

> -chris
> 
> 


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

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[logo]

Madhan,


> Am 04.06.2020 um 18:41 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Madhan,
> 
> On 6/3/20 21:08, Madhan Raj wrote:
>> OS - CentOS 7.6.1810( Core)
>> 
>> Below connector doesn't load my EC keystore whereas it works with
>> RSA . Any insights please .

Try to update to the latest version. Check the change log. In 9.0.31 support 
for EC keys was at least updated. Maybe this will work. I had problems using 
unencrypted EC keys in Tomcat 8.5.50 in JSSE connectors - however with pem 
encoded cert files (fixed in 8.5.51). But yours may be a similar problem.

Regards

Peter

> 
> When you say "doesn't load", what do you mean? Possible reasonable
> responses are:
> 
> 1. I can only complete a handshake with RSA cert, not ECDSA cert
> 2. Error message (please post)
> 3. JVM crashes
> 4. OS crashes
> 5. Universe ends (possible, but unlikely to be reproducible)
> 
>> this is my connector tag  in server.xml > SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200" port="443"
>> scheme="https" secure="true"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
> ion"
>> 
>> 
> disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="819
> 2"
>> minSpareThreads="25"> > certificateVerification="none" sessionTimeout="1800"
>> protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
>> ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
> HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
> S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>> 
>> 
> sessionCacheSize="1">
>> > certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
> rts/tomcat-ECDSA.keystore"
>> 
>> 
> certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
>> certificateKeystoreType="PKCS12" type="EC"/> 
>> 
>> 
>> tomcat start up command used :- /home/tomcat/tomcat -user tomcat
>> -home /usr/local/thirdparty/java/j2sdk -pidfile
>> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
>> /home/tomcat/tomcat -outfile
>> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
>> -Djdk.tls.ephemeralDHKeySize=2048
>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
>> -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
> onf/logging.properties
>> 
>> 
> - -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,suspe
> nd=n
>> -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
>> -Xmx1824m -Xms256m
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> -cp
>> /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
> dparty/jakarta-tomcat/bin/tomcat-juli.jar
>> 
>> 
> - -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catali
> na.policy
>> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
>> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
>> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
>> org.apache.catalina.startup.Bootstrap start'
>> 
>> JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
>> -Djavax.net.ssl.sessionCacheSize=1
>> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-
> certs/tomcat-trust.keystore
>> 
>> 
> - -Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
>> -XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.
> txt
>> 
>> 
> - -Dsun.zip.disableMemoryMapping=true
>> -XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
>> -XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS
>> 
>> Also can i have both RSA and ECDSA in a single keystore. Will that
>> work in tomcat 9?
> 
> Yes. You have to use two  elements each with a different
> "type" and "certificateKeyAlias"
> 
>> it used to work with tomat 7
> 
> It still works with Tomcat 9.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ZJEwACgkQHPApP6U8
> pFg/Tg/9El60qkdMWwk6SpBiKjy0rgQEYgmdv2hkVQXmfX4uaWHZuEBDydX/xQ9L
> 3JaS+rDeM/4Z6Y7HrKqLGQ0Q+mtgWSoXohhGAqZMcsaGtdiz9oBYukRW7e0JG4Hv
> OZgmyPUifLH0kPDyrql3feLQL9TW7G998rR9+N2BsFWnyVdaHYIWt2vSu+/vak7T
> OqqNj0Wze9G8/OudKXCEQBi1ADql8XAt7hRCaQLHRcaDLEVLnULq6lgol0dV9qXM
> suzNGud9VWNUgsoNX7wZDmx2xYnvDUfOnUJSEYLfRV6zFHOJOLiKLk8GBjymLVt3
> PEW3EXlJpq2rQo++s4tNhJGjZRR7yEGNRUO1bl/eB7O4MZrwpZyV9lmy2TN2Im5g
> LsMas3p3m87vz8ajafo9SDSZkmXmJ270dUZd8MAxxIvDSCnhw0trSTxbppgeb7p4
> LGn/gA9igAY9S9PUKkyLocKVW9XpRg1v21WCSyifKzM7b0787e1EFx6rhxBTsZAk
> 7D7nL+0Em61LRQKaM3noDtyofEzYGoUtaRwv5gx+dCfF5huDCKvkhWxGQfAwiE/3
> fRHCZK1la1Jn3wikApLXU6iEjXV33TmF/hAjLOPaizl90AYxR6O4pvwRKOF+9+fV
> Z4CO1ysmLK/WHTYXcpZ8/zPEo9EgXbTULU9DiDu3N6+LKrUFQcc=
> =L+y6
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For 

Re: [OT] Re: CentOS Tomcat install seems to ignore setenv.sh

[logo]

Chris,

> Am 13.05.2020 um 16:42 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
> On 5/13/20 02:48, logo wrote:
>> Hi calder,
>> 
>> 
>>> Am 13.05.2020 um 04:59 schrieb calder :
>>> 
>>> On Tue, May 12, 2020, 21:48 kohmoto 
>>> wrote:
>>> 
>>>> Hi, Calder,
>>>> 
>>>> Thank you for your prompt reply. I think Tomcat binary files
>>>> all have root priviledges. Should these priviledges should be
>>>> changed to user priviledges?
>>>> 
>>> 
>>> 
>>> Yes.
>> 
>> I would suggest to leave the binaries and maybe even config files
>> to root or any other admin. So a hacked tomcat process under tomcat
>> user will not be able to exchange config or even binaries.
> Yes! There really is no need for Tomcat to modify its own config files
> or binaries.
> 
>> That will only work if the config will not be changed via
>> host-manager or programmatically.
> 
> This shouldn't be too much of a problem. Not many people use the
> host-manager.
> 
>> In the past we even held the installed webapps under a different
>> user. but that maybe difficult in automated deployments.
> 
> This is less important IMO. The owner of the files can be anybody...
> just not the Tomcat user.
> 
> And, before anybody says "but.. but... Docker!" you should remember
> that root in a Docker container often ends up having many more
> privileges outside the container than you think it does/should.
> 

Never ignore this!

As simple as adding the following to your Dockerfile


RUN set -x \
  && groupadd tomcat \
  && useradd -g tomcat -s /usr/bin/nologin -m -d /home/tomcat tomcat \
  && chown -R tomcat:tomcat $CATALINA_HOME/logs $CATALINA_HOME/work 
$CATALINA_HOME/temp

# add $CATALINA_HOME/webapps if you use the manager-app

USER tomcat



before running the ENTRYPOINT or CMD.

BTW: that is something that is really missing in the „Official“ Tomcat Docker 
images. (I know they are not maintained by ASF)

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl68B08ACgkQHPApP6U8
> pFhlGA/+O68ss6u7JTG4j7LDOqZq3K+E6DJ+45v8Tz69nL49WNZzcs3n1DfhP3Ar
> EomgYcbGgAq0eot6LInWQmoMX1xp+Wh2XC0b/fae1/vkerN4ugqLiqWIA1uM1ar4
> LQ0im7X8RaredMc0BanditDuJK5iRoUqRg7md8Sw/aGOncvVzjRR1hgU9mzqbHps
> C6wrSb+5rr5a3SE1P2k2uhpMY1FI1xP8icdQXBCA6eYiJ3tBYsPmWU3z3J8JAmmG
> k3i4WpZdoTsfVlX2n8H6K1l3u8WQsHmoMg5pzqgV1ABUtSBBbrSSkdCTlwHse4ch
> ePAZg5XRuVlb06UbRHW15hfVGJCgCrzeL/yIufScEOYV6YYnEAx5D+UULG0wSJ7r
> cRnmPE5ccWSLflplcmhurqhXRWeqsfpzjraZGRdyqv4HqG1zlfefEIuMVCPLHtRO
> DQACi0HfbhOvNoIsVtabXBC4gigT4Zv2k9EQcRjbpO/cN1VMzRNV80jVnnV4QiOj
> PCJ81Z4G+LE0pCSqoYLIvZKZ1CbmD0BIeL6ZngrHJFACJlkbSK4zfRMBgKc/2OZa
> 5ltCftRev8fW4hztptQRxg9tfEdhaa+6MVXTGPTHYhGycMsDgCEO/W7dU6LcJNJG
> q+bcNedNE5y046yCm9SpGKW0/kmS5I6R984W1NhfHSNKTLtEwHc=
> =V1n4
> -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

[OT] Re: CentOS Tomcat install seems to ignore setenv.sh

[logo]

Hi calder,


> Am 13.05.2020 um 04:59 schrieb calder :
> 
> On Tue, May 12, 2020, 21:48 kohmoto  wrote:
> 
>> Hi, Calder,
>> 
>> Thank you for your prompt reply.
>> I think Tomcat binary files all have root priviledges.
>> Should these priviledges should be changed to user priviledges?
>> 
> 
> 
> Yes.

I would suggest to leave the binaries and maybe even config files to root or 
any other admin. So a hacked tomcat process under tomcat user will not be able 
to exchange config or even binaries.
That will only work if the config will not be changed via host-manager or 
programmatically.

In the past we even held the installed webapps under a different user. but that 
maybe difficult in automated deployments.

My 2cts.

Peter

> 
> There is a "Tomcat Security" guide at the Tomcat website.  Also, Mulesoft
> has a good guide
> https://www.mulesoft.com/tcat/tomcat-security
> 
> 
> Your truly,
>> Kazuhiko Kohmoto
>> 
>> On 2020/05/13 11:17, calder wrote:
>>> If TC, running as root, is ever compromised, the compromising user
>>> (attacker) can gain access to the whole of the system.  The attacker
>> could
>>> execute any arbitrary command available on the system.  They could remove
>>> files, or install malicious software.
>> 
>> 


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

Re: Losing session between calls from mobile phone

[logo]

AJ

> Am 30.04.2020 um 22:22 schrieb AJ Chen :
> 
> The session problem happens when testing without SSL.
> 
Just a thought:

If the session cookie has the secure flag it will not be sent on http requests. 
(That would fail your test above in any case!)

Now if that happens during regular https usage, it could be that one requests 
redirects to http. That will remove the cookie and a new session will be 
generated. The next https-request will have new cookie and then you start from 
scratch.


Could that be possible?

Peter


> I'll try to test with Tomcat session manager example app. Thanks, Chris.
> 
> -aj
> 
> On Wed, Apr 29, 2020 at 3:05 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> AJ,
>> 
>> On 4/29/20 13:46, AJ Chen wrote:
>>> On Wed, Apr 29, 2020 at 10:28 AM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>> 
>>> AJ,
>>> 
>>> On 4/29/20 13:24, AJ Chen wrote:
>> Chris, When i use my latest iphone 11 to access the web app,
>> tomcat server generates new session every time. It's normal
>> use, not private browsing.> I did not change any setting on
>> tomcat regarding session, use default session tracking. Is
>> there any setting that can enforce using previous session
>> (i.e. track session)?  Can I save the previous SessionID and
>> use it to get the session with this id explicitly?
>>> AFAIK, Safari Mobile doesn't do anything weird.
>>> 
>>> Are you always using TLS (HTTPS)?
>>> 
>>> -chris
>>> 
>> On Wed, Apr 29, 2020 at 10:13 AM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>> 
>> AJ,
>> 
>> On 4/28/20 16:13, AJ Chen wrote:
> Andre, thanks for asking the questions. Yes, we try to
> get understand the behaviors.
> 
> We have seen iphone and other android phones, on
> different carriers, from different networks, encounter
> this problem - losing session. It does not seem there
> is a pattern so far. Users use all kinds of phones.
> Some of their phones experience this problem.
>> 
>> Are any of them using "private browsing" or anything like
>> that?
>> 
>> Are you just using the standard Tomcat-generated JSESSIONID
>> cookies?
>> 
>> -chris
>> 
> On Tue, Apr 28, 2020 at 12:08 PM André Warnier
> (tomcat/perl)  wrote:
> 
>> On 28.04.2020 18:28, AJ Chen wrote:
>>> Thanks. Martin and Mark.
>>> 
>>> I can recreate the problem: I compare two
>>> different mobile phones. One phone can log in and
>>> proceed. Server log shows the same session persists
>>> (same sessionID upon different requests). The other
>>> phone can log in, but upon next request, server log
>>> show a new session is always created (new
>>> sessionId).
>>> 
>>> Since session tracking works on PC browser and
>>> some mobile phone, the
>> proxy
>>> (if any) in front of aws EC2 server should not be
>>> the problem.
>> Anything
>>> else may be missing?
>>> 
>> 
>> Asking just in case : - are the 2 phones on the same
>> network carrier ? - are they the same brand, or at
>> least OS ? - if you connect them both to the same
>> local WiFi, do they still act differently ?
>> 
>> Note : no idea if this makes any difference, but
>> we're trying to find a reason why they act
>> differently when using the same Internet application
>> server, right ?
>> 
>>> -aj
>>> 
>>> 
>>> On Tue, Apr 28, 2020 at 12:30 AM Mark Thomas
>>>  wrote:
>>> 
 On 28/04/2020 07:47, Martin Grigorov wrote:
> On Tue, Apr 28, 2020 at 9:11 AM AJ Chen
> 
>> wrote:
> 
>> Anyway to fix it? thanks. -aj
>> 
> 
> First you need to investigate whether there is
> a proxy. Then what kind of proxy. Then where is
> its configuration. Then consult with its manual
> and see whether there is something
> wrong/missng.
 
 I'd recommend taking a step back.
 
 Guessing at what might be wrong and then trying
 to fix the problem you have only guessed at is
 unlikely to work.
 
 Can you recreate the problem? You can't tell if
 something is fixed if you can't recreate it.
 
 Once you recreate the problem then you can start
 to narrow it down. You need to track what is
 happening to the session ID. You'll probably need
 to add some information to the access log,
 possibly look at some raw network logs and/or

Re: JNDI match of LDAP hashed passwords fail against cleartext

[logo]

Brian,

see down below

Am 2020-04-14 08:34, schrieb Brian Burch:

I thought it would be helpful to start this issue on the users list
because it will contain a lot of helpful search terms.

I am upgrading a stable production tomcat 7.0.52 system to tomcat
8.5.54. Both were built from source code (tc8 cloned from git) and
compiled under openjdk8.

Many users have pre-hashed SHA-1 passwords stored in the LDAP
directory. My SSO login jsp uses Form authentication. Because the only
Connector services https on port 443, there is no security exposure
from sending the user-entered cleartext password "over the wire" to
tomcat.

The working tomcat 7 Engine has the following Realm definition:-

  

  
  ldap://ldap.pingtoo.com:10389;
 userBase="ou=people,o=pingtoo.com"
 userSubtree="false"
 userSearch="(uid={0})"
 userRoleName="tomcatRole"
 userPassword="userPassword"
 digest="SHA" />
  

... and the Host has the following:-

className="org.apache.catalina.valves.ExtendedAccessLogValve"

   directory="logs"
   prefix="access." suffix=".txt"
   pattern="c-ip x-H(authType) x-H(remoteUser) date time
cs-method cs-uri sc-status bytes"
   resolveHosts="false"/>


className="org.apache.catalina.authenticator.SingleSignOn"/>


As I said earlier, but without sounding like I am complaining, this
environment worked as intended (by me, the webadmin) with
tomcat7.0.52.

I am aware of the following information on the tomcat 8 Documentation:-

https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html

and

https://tomcat.apache.org/tomcat-8.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm

It states the "algorithm attribute is deprecated. Set the algorithm on
a nested CredentialHandler element instead."

I deleted the algorithm attribute from the tomcat8 JNDIRealm
definition, and nested three different versions for different test
runs:-



It made no difference whether I used "SHA-1" or "SHA-256".

Under a netbeans remote debugging session with the tomcat8 server, I
initially set a breakpoint in FormAuthenticator.doAuthenticate, then
instruction stepped to drill down into the JNDI authentication logic.

JNDIREalm.compareCredentials executes:-

return getCredentialHandler().matches(credentials, password);

.. where the calling parameters are the {SHA} password from
the LDAP directory and the cleartext password string from the logon
Form.

MessageDigestCredentialHandler.matches immediately calls its own
getAlgorithm method, which returns null. Without a correct digest
handler, the two password parameters are compared as simple strings.
This means the authentication fails!

To prove my point, I pasted the hashed copy of the LDAP userpassword
(as plain text) into the FormAuthenticator field. Naturally, without a
valid hash algorithm the authentication is successful simply because
the two strings match exactly.

I searched for usages of MessageDigestCredentialHandler.setAlgorithm,
but only found it used once - within TestJNDIRealm. I did not find any
occurrences within tomcat mainline code, but would not be surprised if
the algorithm was intended to be set within code which used
introspection at runtime.

My initial code inspection makes me strongly suspect tomcat does not
initialise JNDIRealm and a nested CredentialHandler properly during
startup. However, I am not smart enough to attach my debugger to the
tomcat jvm until it is too late.

I had a smart idea... at a breakpoint I changed the value of the
algorithm instance variable from null to "SHA" before the comparison,
but I was slapped down with the following Exception:-

BB 2020-04-14T15:22:44,257 ERROR
[org.apache.catalina.core.ContainerBase.[Catalina].[www2.pingtoo.com]]
Exception Processing /staticPingToo/restricted/j_security_check
java.lang.IllegalStateException: Must call init() first
at
org.apache.tomcat.util.security.ConcurrentMessageDigest.digest(ConcurrentMessageDigest.java:71)
~[tomcat-util.jar:8.5.54]
at
org.apache.tomcat.util.security.ConcurrentMessageDigest.digest(ConcurrentMessageDigest.java:63)
~[tomcat-util.jar:8.5.54]
at
org.apache.catalina.realm.MessageDigestCredentialHandler.matches(MessageDigestCredentialHandler.java:114)
~[catalina.jar:8.5.54]
at
org.apache.catalina.realm.JNDIRealm.compareCredentials(JNDIRealm.java:1822)
~[catalina.jar:8.5.54]
at
org.apache.catalina.realm.JNDIRealm.checkCredentials(JNDIRealm.java:1782)
~[catalina.jar:8.5.54]
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1427)
~[catalina.jar:8.5.54]
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1304)
~[catalina.jar:8.5.54]
at
org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:197)
~[catalina.jar:8.5.54]
at

Re: [ANN] Apache Tomcat 9.0.31 available

[logo]

Am 2020-02-13 10:57, schrieb Olivier Jaquemet:

On 13/02/2020 10:32, Rémy Maucherat wrote:

On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote:

On 13/02/2020 01:02, Stefan Mayr wrote:
- AJP defaults changed to listen the loopback address, require a 
secret

and to be disabled in the sample server.xml

[snip]

Am I correct ? Why such a change ? Why no bugzilla issue for proper
tracking and context ?
What are your recommendations regarding AJP connector configuration ?
It is obviously best to keep default configurations as stable as 
possible.
But sometimes things have to change ... As a result, you'll indeed 
need to

adjust your server.xml according to your deployment and AJP usage.


Thank you Rémy for taking the time to answer.

I understand the need to introduce a "secured by default" AJP 
configuration.

However, I question one choice that was made for this change : the
default behavior of the AJP connector to listen only on the loopback
address.



+1


This is the change which is, to me, the most questionable one. Because
to my understanding, any architecture in which a remote Apache HTTPD
is being used will require a *specific IP address of the current host*
to be specified in the address attribute of the AJP connector. A
specific IP address means that the server.xml is no longer agnostic to
the platfom it is being hosted on. Prior to this, a server.xml file
could be configured in such way that it would never contain any hard
coded value related to the current host. With this change it is no
longer possible. (unless I'm missing something). For large deployment
configuration, this does seems a bit problematic.
Do you understand my concern ? Is there any way to address this ?


That's really difficult. Specifically in container environments where 
the container is started dynamically and the ip address shifts 
frequently. Access is done through dns or labels.




(The secret attribute is less of a problem, because as stated in the
documentation there is an alternative : secretRequired can be set fo
false "when the Connector is used on a trusted network".)

Make that such a breaking change in a minor maintenance update is
quite touchy. I have never seen such drastic change in my usage
history of Tomcat.

Olivier

-
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: [OT] Install Comodo SSL in Tomcat

[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: [OT] Install Comodo SSL in Tomcat

[logo]

Chris,



> Am 28.01.2020 um 19:35 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
> On 1/28/20 12:24 PM, Peter Kreuser wrote:
>>> Am 28.01.2020 um 18:02 schrieb Christopher Schultz 
>>> :
>>> 
>>> You have to say certificateKeystoreType="PKCS12" (for 
>>> , or keystoreType="PKCS12" for ) as well
>>> in your config.
>> 
>> You don‘t need that in the new SSLHostConfig, right? I don‘t have 
>> that attribute and it works... ???
> 
> I'd need to see your configuration, and know what type of keystore you
> are using.
> 

 
   


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 ;-) .


Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wfw4ACgkQHPApP6U8
> pFhm5A//e0VNCvCklGGFfNNxNdamDuzbaZZ3e/aCQeW85dat+rsHZDZKrPgb5MYz
> 7nwjgxooe0TcvkaXzaB/pJGD21ImntWtiTl42MyvPXmZl0PXyXjRGA2/XcQj/Yji
> vTWyVKl1TiH5s0fiIZrQZ0M6lTfQ7T2eVnTzX5MjQwin9zDzRDPl77Dbatn57d4H
> heMY4GgS7XfHrH/EN5jJvU+vXOKI/bS61ujM28+A1dJnEECduIZbsTQTSDah903t
> X/09b8jqUTPJNAQLIfk5/KQS2arhP2Nsoplsy+8a/KOJisRLRWZpoSga4N/CBc3D
> CoslAJM1w+za6BV+xKuZSP795ZiuqF34jnb36LTOkiaXcCrKrm4B35ImvCtSOgYX
> FvC4NJq+t4f3AVnvNkqaN6ygJifveI4g86C46r8A40YUFSydbQoKiwrDUGvbN+jq
> 568014A/p7n0k4N48KPyVZmH8x8NwlBE3n0V4/KW1kXikGUDcyFOoXp+g+nMhRpV
> l/I9US8rrBnJbkIlZLOibxI5LzRQ0mqMmspHaqzkl7zGWnP3EwvI1KysgpkotJ+i
> shAaY5z1IWg6i5w1iZK/JzOkpixBBZR4ckMAanZXV5UQaW06Swkc81C4vfpJoNAO
> qZINTga45uXg2/Wt5xkNjkv9+P5KVnPiVb3YhtGH4b1wRaI9qaQ=
> =E1yB
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Fwd: Install Comodo SSL in Tomcat

[logo]

Fwd to the list

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Léonard WAMBERGUE 
> Betreff: RE : Re: Install Comodo SSL in Tomcat
> Datum: 27. Januar 2020 um 21:40:58 MEZ
> An: logo 
> 
> Peter,
>  
> Thank for your help, since my email i was able to find a solution now my 
> website can be reach by 8443. The next step is to make disappear the port in 
> url if you have any ideas but actually it’s work !
> However, i noticed that i have this in my Catalina.out :
> 27-Jan-2020 18:36:54.764 SEVERE [main] 
> org.apache.catalina.startup.HostConfig.beforeStart Unable to create directory 
> for deployment: [/opt/tomcat/conf/Catalina/localhost]
>  
> 27-Jan-2020 19:21:35.463 WARNING [main] 
> org.apache.catalina.startup.SetAllPropertiesRule.begin 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'maxSpareThreads' to '75' did not find a matching property.
>  
> The main problem is solve !
>  
> Regards,
>  
>  
>  
> Provenance : Courrier <https://go.microsoft.com/fwlink/?LinkId=550986> pour 
> Windows 10
>  
> De : logo <mailto:l...@kreuser.name>
> Envoyé le :lundi 27 janvier 2020 21:35
> À : Tomcat Users List <mailto:users@tomcat.apache.org>
> Cc : Léonard WAMBERGUE <mailto:leonard.wambergue...@gmail.com>
> Objet :Re: Install Comodo SSL in Tomcat
>  
> Leonard,
> 
> 
> Am 27.01.2020 um 18:50 schrieb Léonard WAMBERGUE 
> mailto:leonard.wambergue...@gmail.com>>:
>  
> Peter,
>  
> I hadn’t seen that i hadn’t answered to all.
>  
> Comodo didn’t send me a key file, *they* = Hostinger, and i can download a 
> zip from their website with my certificates and my server key but i don’t 
> have the CSR.
>  
>  
> Still not helpful if your hoster has the private key - that’s not what 
> private means  If you have access to openssl you could create the CSR 
> yourself and the reissue the cert. Or think about moving to Let’s Encrypt and 
> save the money. But that’s a future step. Let’s get you to https first!!!
>  
>  
> 
> 
> The JKS file was made with :
> openssl pkcs12 -export -in my.crt -inkey my.key -certfile my.ca 
> <http://my.ca/>-bundle -out my.pf
> keytool -importkeystore -srckeystore my.pfx -srcstoretype pkcs12 
> -destkeystore my.jks -deststoretype jks
> So i can’t add any alias with those 2 lines. And without alias i can’t change 
> it with -changealias
>  
>  
> Could you try
>  
> openssl pkcs12 -export -in my.crt -inkey my.key -name tomcat -certfile my.ca 
> <http://my.ca/>-bundle -out my.jks  <<—  the output of pkcs12 is already a 
> jks!!!  and -name tomcat is the alias
>  
> keytool -list -v  -keystore my.jks
>  
>  
> A onliner!
> 
> Hope this helps
>  
> Peter
> 
> 
> The connector actually look like :
> «  minSpareThreads="25" maxSpareThreads="75" 
> enableLookups="false"
> disableUploadTimeout="true" acceptCount="100" scheme="https"
> secure="true" SSLEnabled="true"  clientAuth="false" 
> sslProtocol="all"
> keystoreFile="/opt/tomcat/certs/my.jks" SSLPassword="mypass"
>  keystorePass="mypass"/> »
> Thank for helping me
>  
>  
> Provenance : Courrier <https://go.microsoft.com/fwlink/?LinkId=550986> pour 
> Windows 10
>  
> De : logo <mailto:l...@kreuser.name>
> Envoyé le :lundi 27 janvier 2020 17:32
> À : Tomcat Users List <mailto:users@tomcat.apache.org>
> Cc : Léonard WAMBERGUE <mailto:leonard.wambergue...@gmail.com>
> Objet :Re: RE : Install Comodo SSL in Tomcat
>  
> Leonard,
>  
>  
> Am 2020-01-27 16:53, schrieb Léonard WAMBERGUE:
> > Ok so i have find this error (severe) in my Catalina.out about
> > connector :
> > 
> > 27-Jan-2020 10:52:23.625 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio-194.5.159.189-8080"]
> > 27-Jan-2020 10:52:23.760 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["https-openssl-nio-443"]
> > 27-Jan-2020 10:52:23.764 SEVERE [main]
> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
> > to initialize component [Connector[HTTP/1.1-443]]
> > org.apache.catalina.LifecycleException: Protocol handler
> > initialization failed
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:983)
> > at
> > org.apache.catalina.uti

Re: Install Comodo SSL in Tomcat

[logo]

Leonard,

> Am 27.01.2020 um 18:50 schrieb Léonard WAMBERGUE 
> :
> 
> Peter,
>  
> I hadn’t seen that i hadn’t answered to all.
>  
> Comodo didn’t send me a key file, *they* = Hostinger, and i can download a 
> zip from their website with my certificates and my server key but i don’t 
> have the CSR.
>  

Still not helpful if your hoster has the private key - that’s not what private 
means  If you have access to openssl you could create the CSR yourself and 
the reissue the cert. Or think about moving to Let’s Encrypt and save the 
money. But that’s a future step. Let’s get you to https first!!!



> The JKS file was made with :
> openssl pkcs12 -export -in my.crt -inkey my.key -certfile my.ca 
> <http://my.ca/>-bundle -out my.pf
> keytool -importkeystore -srckeystore my.pfx -srcstoretype pkcs12 
> -destkeystore my.jks -deststoretype jks
> So i can’t add any alias with those 2 lines. And without alias i can’t change 
> it with -changealias
>  

Could you try

openssl pkcs12 -export -in my.crt -inkey my.key -name tomcat -certfile 
my.ca-bundle -out my.jks  <<—  the output of pkcs12 is already a jks!!!  and 
-name tomcat is the alias

keytool -list -v  -keystore my.jks


A onliner!

Hope this helps

Peter

> The connector actually look like :
> «  minSpareThreads="25" maxSpareThreads="75" 
> enableLookups="false"
> disableUploadTimeout="true" acceptCount="100" scheme="https"
> secure="true" SSLEnabled="true"  clientAuth="false" 
> sslProtocol="all"
> keystoreFile="/opt/tomcat/certs/my.jks" SSLPassword="mypass"
>  keystorePass="mypass"/> »
> Thank for helping me
>  
>  
> Provenance : Courrier <https://go.microsoft.com/fwlink/?LinkId=550986> pour 
> Windows 10
>  
> De : logo <mailto:l...@kreuser.name>
> Envoyé le :lundi 27 janvier 2020 17:32
> À : Tomcat Users List <mailto:users@tomcat.apache.org>
> Cc : Léonard WAMBERGUE <mailto:leonard.wambergue...@gmail.com>
> Objet :Re: RE : Install Comodo SSL in Tomcat
>  
> Leonard,
>  
>  
> Am 2020-01-27 16:53, schrieb Léonard WAMBERGUE:
> > Ok so i have find this error (severe) in my Catalina.out about
> > connector :
> >
> > 27-Jan-2020 10:52:23.625 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio-194.5.159.189-8080"]
> > 27-Jan-2020 10:52:23.760 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["https-openssl-nio-443"]
> > 27-Jan-2020 10:52:23.764 SEVERE [main]
> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
> > to initialize component [Connector[HTTP/1.1-443]]
> > org.apache.catalina.LifecycleException: Protocol handler
> > initialization failed
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:983)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> > org.apache.catalina.core.StandardService.initInternal(StandardService.java:533)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1057)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> > org.apache.catalina.startup.Catalina.load(Catalina.java:584)
> > at
> > org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at
> > java.base/java.lang.reflect.Method.invoke(Method.java:566)
> > at
> > org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:303)
> > at
> > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
> > Caused by: java.net.SocketException: Permission denied
> > at java.base/sun.nio.ch.Net.bind0(Native Method)
> > at java.base/sun.nio.ch.Net.bi

Re: Install Comodo SSL in Tomcat

[logo]

Leonard,

Please respond to the list!!! Easiest as respond to all...


> Am 27.01.2020 um 17:48 schrieb Léonard WAMBERGUE 
> :
> 
> Ok so i put 8443 in my connector but not yet the alias. Now i have in my 
> browser the error : ERR_CONNECTION_TIMED_OUT. 
>  
> I have this error in Catalina out with context.xml :
>  
> 27-Jan-2020 16:40:12.646 SEVERE [main] 
> org.apache.catalina.startup.ContextConfig.processContextConfig Parse error in 
> context.xml for [/host-manager]
> org.xml.sax.SAXParseException; systemId: 
> file:/opt/tomcat/webapps/host-manager/META-INF/context.xml; lineNumber: 19; 
> columnNumber: 7; Invalid byte 1 of 1-byte UTF-8 sequence.
> at 
> java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
> at 
> java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:306)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3085)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
>  
> And this :
>  



> 27-Jan-2020 16:40:12.639 WARNING [main] 
> org.apache.catalina.startup.SetContextPropertiesRule.begin 
> [SetContextPropertiesRule]{Context} Setting property 'antiResourceLocking' to 
> 'false' did not find a matching property.
> 27-Jan-2020 16:40:12.641 SEVERE [main] 
> org.apache.tomcat.util.digester.Digester.fatalError Parse fatal error at line 
> [19] column [7]
> org.xml.sax.SAXParseException; systemId: 
> file:/opt/tomcat/webapps/host-manager/META-INF/context.xml; lineNumber: 19; 
> columnNumber: 7; Invalid byte 1 of 1-byte UTF-8 sequence.
> at 
> java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
> at 
> java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
>  
> But i have not find the same error it’s seem like port 8443 solve the error 
> in my last email. I hadn’t edit the context.xml so i don’t understand this 
> problem. It can be wrong installation of tomcat ?
>  

Ok, I’m at loss here. Maybe your web app did not get that far to load before 
you changed the port??? Could you please put the (redacted) content here?

Peter


> Thank for helping me !
>  
> Provenance : Courrier <https://go.microsoft.com/fwlink/?LinkId=550986> pour 
> Windows 10
>  
> De : logo <mailto:l...@kreuser.name>
> Envoyé le :lundi 27 janvier 2020 17:32
> À : Tomcat Users List <mailto:users@tomcat.apache.org>
> Cc : Léonard WAMBERGUE <mailto:leonard.wambergue...@gmail.com>
> Objet :Re: RE : Install Comodo SSL in Tomcat
>  
> Leonard,
>  
>  
> Am 2020-01-27 16:53, schrieb Léonard WAMBERGUE:
> > Ok so i have find this error (severe) in my Catalina.out about
> > connector :
> >
> > 27-Jan-2020 10:52:23.625 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio-194.5.159.189-8080"]
> > 27-Jan-2020 10:52:23.760 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["https-openssl-nio-443"]
> > 27-Jan-2020 10:52:23.764 SEVERE [main]
> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
> > to initialize component [Connector[HTTP/1.1-443]]
> > org.apache.catalina.LifecycleException: Protocol handler
> > initialization failed
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:983)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> &g

Re: RE : Install Comodo SSL in Tomcat

[logo]

Leonard,


Am 2020-01-27 16:53, schrieb Léonard WAMBERGUE:
Ok so i have find this error (severe) in my Catalina.out about 
connector :


27-Jan-2020 10:52:23.625 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-194.5.159.189-8080"]
27-Jan-2020 10:52:23.760 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-openssl-nio-443"]
27-Jan-2020 10:52:23.764 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
to initialize component [Connector[HTTP/1.1-443]]
org.apache.catalina.LifecycleException: Protocol handler
initialization failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:983)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:533)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1057)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.startup.Catalina.load(Catalina.java:584)
at 
org.apache.catalina.startup.Catalina.load(Catalina.java:607)

at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 
java.base/java.lang.reflect.Method.invoke(Method.java:566)

at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:303)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
Caused by: java.net.SocketException: Permission denied
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:455)
at java.base/sun.nio.ch.Net.bind(Net.java:447)
at



that looks like you're trying to start a privileged port without being 
root.


try to start on port 8443, and see if you can connect.

After that you may need a natting to map port 443 to 8443. (you should 
not start tomcat as root or privileged windows user)


Peter.


java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at
java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80)
at
org.apache.tomcat.util.net.NioEndpoint.initServerSocket(NioEndpoint.java:229)
at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:212)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1154)
at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:980)
... 13 more

I will add an alias to my keystore and i had seen others errors in
context.xml but i never edit this file.
Provenance : Courrier pour Windows 10

De : Christopher Schultz
Envoyé le :lundi 27 janvier 2020 14:24
À : users@tomcat.apache.org
Objet :Re: Install Comodo SSL in Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Léonard,

On 1/27/20 4:57 AM, Léonard WAMBERGUE wrote:

I’m resending this email because i wasn’t well subscribed to users.
I have a VPS server which turn with Ubuntu and i had install
apache/maven and tomcat.> My server version is Apache
Tomcat/9.0.30.

So i deploy my webapp with a ROOT.war file in tomcat. The website
is running on port 8080 and 80 with a redirection. Now i am trying
to install a Comodo SSL to my website and configure my 443 port in
order to use Something like https://mydomain.com.

After purchasing my comodo certificate i received a zip which
containing a key file, a bundle and .crt like mydomain.crt.

Are you sure Comodo send you a .key file? That would be very unusual.

When you applied for the certificate, did you send them a Certificate
Signing Request (CSR)? Or did *they* generate the server-key for you?
You should never let anyone else generate your server key for you.


I had already configure mydomain.jks with a keystore and configure
my connector with this code :

What is in the JKS file? Did you add anything from the ZIP file into
the JKS file?





That looks okay to me, except that you don't have a certificate
"alias" listed, so Tomcat will choose the first certificate it finds
in the store, which may not be the one you want to use.

The contents 

Re: ECDSA Private Keys

[logo]

Chris and Mark,


> Am 09.01.2020 um 21:49 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> All,
> 
> On 1/9/20 3:45 PM, Christopher Schultz wrote:
>> Mark and Peter,
>> 
>> On 1/9/20 3:36 PM, Mark Thomas wrote:
>>> On 09/01/2020 20:22, logo wrote:
>>>> Mark,
>>>> 
>>>>> Am 09.01.2020 um 20:36 schrieb Mark Thomas
>>>>> :
>>>>> 
>>>>> On 02/01/2020 09:24, logo wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> The connector comes up correctly, is accessible through
>>>>>> the browser but if I test the ssl setup, I get an error
>>>>>> message that the key/cert may not be used for "Key
>>>>>> agreement"
>>>>>> 
>>>>>> See: testssl.sh :8443
>>>>>> 
>>>>>> Signature Algorithm  ECDSA with SHA256 Server key 
>>>>>> size  EC 256 bits Server key usage Digital
>>>>>> Signature, Key Encipherment Certificate incorrectly used
>>>>>> for key agreement Server extended key usageTLS Web 
>>>>>> Server Authentication, TLS Web Client Authentication
>>>> 
>>>> The key usage error is caused by identifying ECDH_RSA ciphers
>>>> on the connector… (most certainly an unexpected edge case,
>>>> I’ve debugged it that far). That should not be the case - as it
>>>> is an ECDSA Cert, right?
>> 
>>> I don't think so.
>> 
>>> I'm seeing ECHD/RSA ciphers in the output and I am not getting
>>> that warning.
>> 
>>> My reading of a couple of questions on stack exchange suggests
>>> RSA vs DSA ciphers depends on how the CA signs the cert. My test
>>> CA signs with RSA.
>> 

Root and Intermediate are RSA-signed.

Cert is:
Signature Algorithm   ECDSA with SHA256
Server key size  EC 256 bits


>> DSA is almost never used. Nearly 100% of keys in the world are 
>> plain-RSA or EC. I know of no CA that uses DSA for signing. So
>> pretty much every cert you will come across will be EC-with-RSA or 
>> RSA-with-RSA (that's keytype-with-signature-type).
> 
> Obviously, the above is a mixture of half-truths and irrelevant
> information. I was thinking of RSA versus DSA keys, not ECDSA as a
> signature algorithm in its own right.

Maybe I’m causing a lot of hassle by asking these questions. So far I was happy 
to get a cert with a key, drop it in the right spot and all worked well. If I 
stick to RSA that should stay like this.

So actually it won’t be a problem of the client - as long as it finds one 
matching cipher. So for now, we should be fine if an EC-key is supported.

Nevertheless I will try to contact Dirk Wetter and ask him if he can explain 
the finding. 

Peter


> 
> Carry on...
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4XkdgACgkQHPApP6U8
> pFiJ/xAAudFM0wtuRNTIZy6hHGpwLZ4QX6Z9mbWYBYJ93eId8VKL8jQyHgkGTXyT
> OZ2moW+13Grr5zGxo7WgS4EGc1+MKnrBfSY0BwQJwKCwDCJOKTCqMjSybUMrrM7Y
> POf/Lwc+KbxTNhMd7KonxpwYOhox6Cu+I0wh/EQl5jsJCDK4VFW9Y7BjywlQsGjI
> reYQCEu7Sc98c+x8lw1eb6soAj7cIRzmyf8lofS0eOXW10waesIrZSL+8/QyiGd6
> ku6198xaB4ofGOaeXBOO3L91e/2Kx4oRPd0FQHqe0h/nUp9+YJbOr6ypub9nCuuX
> Oq/MAPUv2Abds3mYAAdRNipJmsGmcud3dgJubzmVAQqfoJTCZHtn90p7IBJGK1t0
> 7nCmFCDGdqEYv43v6lBrzc6X5BBMT99c7gZ7pqWq7n2lAmorVNZK3rDkT4wMUjP3
> OO0YapUd2+PyrneBFGb5e6lHvzHGk6sbKTNoeMkcMFAD3S5cE20w79gBruYP3y3B
> PlwFIXmYQTGBExIpTxZQziD19yKsavi8tMXWfLHt9yw04a9vIxeQdaSG6sFLQrj7
> ZzyX1q9uhxieyTNNjwaDxhkLpnSJDHelu5SLV32TBr+9OL3426r3cVsivQQlouWD
> iAGdB84DMZLj0dINM1Y7XJHe/4FHjoMfnn7ELIiTdYmPm1sLJMQ=
> =c/td
> -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 app within docker container

[logo]

Alex,

Am 2020-01-10 12:47, schrieb Alex K:
Just to follow-up on this in case it will be useful to anyone, I 
managed to
use also the official tomcat image. I had to amend my .war files and 
use

the openjdk:8-jdk version instead of openjdk:11-jdk.

I have used the following Docker files to prepare my custom tomcat 
image
(so as to have tomcat home at /opt/tomcat) and then deployed the final 
app

as following:

Got openjdk:8-jdk Docker file from:
https://github.com/docker-library/tomcat/blob/807a2b4f219d70f5ba6f4773d4ee4ee155850b0d/8.5/jdk8/openjdk/Dockerfile
Amended the tomcat home to /opt/tomcat.

Then deployed the app using the following Docker file:

FROM tomcat:custom
USER root
ENV CATALINA_HOME /opt/tomcat
ENV PATH $CATALINA_HOME/bin:$PATH
RUN mkdir -p "$CATALINA_HOME"
WORKDIR $CATALINA_HOME
ADD iforms_files/app.war $CATALINA_HOME/webapps/
ADD iforms_files/orbeon.war $CATALINA_HOME/webapps/
ADD iforms_files/server.xml $CATALINA_HOME/conf/
ADD iforms_files/mariadb-java-client-2.4.1.jar $CATALINA_HOME/lib
ADD iforms_files/setenv.sh $CATALINA_HOME/bin/
EXPOSE 8443
CMD ["catalina.sh", "run"]

I also tried the alpine versions:
https://hub.docker.com/layers/openjdk/library/openjdk/8-jre-alpine3.9/images/sha256-ea81da311d33e052eeea34336018434bdc50596100f9c623193867faa291b284

by using the same Dockerfile (by pointing to the custom built image 
FROM
tomcat:alpine) I was able to deploy same app successfully reaching 
image

size 281MB instead of 660MB with the default tomcat image.



Almost perfect.

Now have a look at 
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE.


This way you don't have to change the installation directory.

set CATALINA_BASE to /opt/tomcat and deploy all your conf and webapp to 
the directories underneath /opt/tomcat.


like this:

FROM tomcat:8-jdk8-openjdk-slim
 #(slim saves you space)

ENV CATALINA_BASE /opt/tomcat
WORKDIR $CATALINA_BASE
RUN mkdir -p temp logs work webapps conf
ADD iforms_files/app.war $CATALINA_BASE/webapps/
ADD iforms_files/orbeon.war $CATALINA_BASE/webapps/
ADD iforms_files/server.xml $CATALINA_BASE/conf/
# you do need those:
ADD iforms_files/tomcat-users.xml $CATALINA_BASE/conf/
ADD iforms_files/web.xml $CATALINA_BASE/conf/

ADD iforms_files/mariadb-java-client-2.4.1.jar $CATALINA_BASE/lib
ADD iforms_files/setenv.sh $CATALINA_BASE/bin/

EXPOSE 8443
CMD ["catalina.sh", "run"]

optionally I'd recommend to change the user to tomcat (root is baaah)

...
RUN set -x \
  && groupadd tomcat \
  && useradd -g tomcat -s /usr/bin/nologin -m -d /home/tomcat tomcat \
  && chown -R tomcat:tomcat $CATALINA_HOME $CATALINA_BASE

USER tomcat
...

Imagesize is sth like 300MB. Unique size 18MB

HTH

Peter



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

Re: [OT] Tomcat app within docker container

[logo]

Martynas,

> Am 09.01.2020 um 23:12 schrieb Martynas Jusevičius :
> 
> Forget Kubernetes for now :)
> 
> My recipe is using a multi-stage build. Very crudely:
> 
> FROM maven as maven
> # build your webapp into a .war
> mvn clean install
> 
> FROM tomcat
> COPY --from=maven /webapp/target/ROOT webapps/ROOT/
> 

NICE!

> It copies the whole folder from the build directory rather than the .war file.
> Here is an example:
> https://github.com/AtomGraph/LinkedDataHub/blob/master/Dockerfile
> 
> It does not use tomcat image directly but rather an intermediary image
> which adds config as ENV capabilities as well as LetsEncrypt
> certificates:
> https://hub.docker.com/r/atomgraph/letsencrypt-tomcat/
> 
> You might also want to take a look at the entrypoint script which is a
> bit more involved:
> https://github.com/AtomGraph/LinkedDataHub/blob/master/platform/entrypoint.sh
> 

Thanks for sharing. Will be very interesting to improve my deployment.


> Look at the container as a large function. Minimize the number of
> inputs to it - generate all the configs that can be generated and
> execute the init actions within Dockerfile and/or entrypoint. Mount
> the rest from host as volumes, under Tomcat's webapps/ROOT (assuming
> you're Dockerizing one webapp).
> 
> Martynas
> atomgraph.com
> 
> On Thu, Jan 9, 2020 at 8:32 PM Christopher Schultz
>  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Pater,
>> 
>> On 1/9/20 12:39 PM, logo wrote:
>>>> Am 09.01.2020 um 17:51 schrieb Alex K :
>>>> 
>>>> Hi all,
>>>> 
>>>> I have two .war files that when deployed at a plain Debian 9 VM
>>>> are working fine. I have prepared a docker file so as to deploy
>>>> the same apps within a docker container and for some reason one
>>>> of the apps is not loading due to some error.
>>>> 
>>>> Dockerfile: FROM debian:latest
>>> 
>>> Why not using any of the different flavored tomcat images?
>>> 
>>> https://hub.docker.com/_/tomcat <https://hub.docker.com/_/tomcat>
>>> 
>>> You get a working jdk (oracle, adopt, openjdk) and don’t have to
>>> build the system yourself. That may help to get the base running
>>> and then copy your file to the correct spots.
>> 
>> If you've got experience with Docker, I'd love for someone to put
>> together a post/presenation/whatever which addresses this question:
>> 
>> I've got an application that I deploy to Tomcat on a traditional
>> server; How do I Dockerize that?
>> 
>> Specifically, I'd like more than just "well, docker-compose with your
>> WAR file and put it in the right place" because we all know that there
>> are plenty of configuration files, etc. that don't work well with a
>> WAR file, etc.
>> 
>> So maybe this bleeds into "well, if you want to use Docker, maybe you
>> want to consider Kubernetes for configuration" and then explain how
>> you might move some of your server/application configuration into
>> Kubernetes (or similar). I'd like to understand how to package-up
>> things like this to be able to eventually use something like AWS's
>> auto-scaling.
>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>> 
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4Xf6sACgkQHPApP6U8
>> pFgobg//Zf5fQ5RqqNDYRDk8KFuS7QWmsZWxUez/waeEbrLW0z/iBRYaIDf63dDs
>> G6/XOPAKov5K4jWxLxTeUY/GUVklwdqy8mGnQJwEmBOlFrMqidfrYZEbx4b6Us1o
>> /GiAch2QUFhflaZ7DzSjxLYosMdReiQRl4PXnLVxNUQ7jB7aRaYRMwXgjCJGc66b
>> PXJSUamYhngIlV4ZYB23ACJsbUlaacsyiYdXOJNSuip/xb8atz547KuGT7shCT0P
>> QqJMNDD91KHWBtgrldkO9pb6zYMpwCUxf5PE9jpgk6U6MDlXeXF+HGEnYY6PFxwV
>> kJfsPt2JUIC8Coo7ydkboxUgSQ16xvV6/PvhAdUGiaadS+WF4ZullveqSyNVHBQw
>> dQI563oQYZ1qfh8zcHeZdsb7TLIaVh9Vx2Vn/+XN1bA1tcvjJx+Pz0fEHjtTy8Q+
>> JW2nLIV2ZdbpsdHi0FjdIWIXscg+EyVMUiPx+qmpVyFA3Al7GWLc1h7yQic+hsuT
>> oscRQf2crbu2tpPBBRP5YodtcAtOOvxbbRsQnALxKuBhBDmFzdl4taPTXlko6Kqc
>> b1C/onqwrDlVPKwySPWFU43rTCLImD0L7eGCDxIzDX5z/HbGahtvYxKXf/Jpg7Sl
>> lZuGlyhIIgRoWZF3utUsI11YjRsmRFme0EtfpMdBz/Xb4v/9YeU=
>> =PK8y
>> -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
> 


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

Re: ECDSA Private Keys

[logo]

Mark,

> Am 09.01.2020 um 20:36 schrieb Mark Thomas :
> 
> On 02/01/2020 09:24, logo wrote:
> 
> 
> 
>> The connector comes up correctly, is accessible through the browser but if I 
>> test the ssl setup, I get an error message that the key/cert may not be used 
>> for "Key agreement"
>> 
>> See:
>> testssl.sh :8443
>> 
>> Signature Algorithm  ECDSA with SHA256
>> Server key size  EC 256 bits
>> Server key usage Digital Signature, Key Encipherment
>>  Certificate incorrectly used for key agreement
>> Server extended key usageTLS Web Server Authentication, TLS Web Client 
>> Authentication

The key usage error is caused by identifying ECDH_RSA ciphers on the connector… 
(most certainly an unexpected edge case, I’ve debugged it that far). That 
should not be the case - as it is an ECDSA Cert, right?

> 
> The allowed usages are configured when a certificate is created. See:
> https://www.openssl.org/docs/manmaster/man5/x509v3_config.html
> 
> You need to take this up with your Certificate Authority.

The CA is issuing the right cert with appropriate usage for a Webserver 
"Digital Signature, Key Encipherment".

> 
> I'll look at the cipher differences next.
> 

testssl.sh -e  https://: should give you my result.

Thanks.

Peter

[1] https://github.com/drwetter/testssl.sh 
<https://github.com/drwetter/testssl.sh>

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

Re: Tomcat app within docker container

[logo]

Hi Alex,



> Am 09.01.2020 um 17:51 schrieb Alex K :
> 
> Hi all,
> 
> I have two .war files that when deployed at a plain Debian 9 VM are working
> fine.
> I have prepared a docker file so as to deploy the same apps within a docker
> container and for some reason one of the apps is not loading due to some
> error.
> 
> Dockerfile:
> FROM debian:latest

Why not using any of the different flavored tomcat images?

https://hub.docker.com/_/tomcat 

You get a working jdk (oracle, adopt, openjdk) and don’t have to build the 
system yourself.
That may help to get the base running and then copy your file to the correct 
spots.


> USER root
> 
> ENV CATALINA_HOME /opt/tomcat
> ENV PATH $CATALINA_HOME/bin:$PATH
> RUN mkdir -p "$CATALINA_HOME"
> WORKDIR $CATALINA_HOME
> 
> # Install packages
> RUN apt update && apt install default-jdk -y && groupadd tomcat && useradd
> -s /bin/false -g tomcat -d $CATALINA_HOME tomcat
> COPY apache-tomcat-8.5.50.tar.gz /tmp/
> 
> RUN tar xzvf /tmp/apache-tomcat-8.5.50.tar.gz -C /opt/tomcat
> --strip-components=1
> 
> ADD app.war $CATALINA_HOME/webapps/
> ADD orbeon.war $CATALINA_HOME/webapps/
> ADD server.xml $CATALINA_HOME/conf/
> ADD web.xml $CATALINA_HOME/conf/
> ADD mariadb-java-client-2.4.1.jar $CATALINA_HOME/lib
> ADD setenv.sh $CATALINA_HOME/bin/
> 
> RUN chgrp -R tomcat $CATALINA_HOME && \
>chown -R tomcat webapps/ work/ temp/ logs/ && \
>chmod -R g+r conf && \
>chmod g+x conf && \
>chmod 750 $CATALINA_HOME/bin/setenv.sh && \
>rm -f /tmp/apache-tomcat-8.5.50.tar.gz;
> 
> EXPOSE 8443
> CMD ["catalina.sh", "run"]
> 
> I have tried also several other ways, by using directly other docker tomcat
> images everytime resulting with some error.
> 
> The error I am getting now is:
> 
> 10:21:32.201 WARN  c.h.c.c.s.CubaXmlWebApplicationContext  - Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'org.springframework.security.filterChains': Cannot resolve
> reference to bean
> 'org.springframework.security.web.DefaultSecurityFilterChain#0' while
> setting bean property 'sourceList' with key [0]; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name
> 'org.springframework.security.web.DefaultSecurityFilterChain#0': Cannot
> create inner bean '(inner bean)#27690bd5' of type
> [org.springframework.security.web.authentication.www.BasicAuthenticationFilter]
> while setting constructor argument with key [4]; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name '(inner bean)#27690bd5': Cannot resolve reference to bean
> 'clientAuthenticationEntryPoint' while setting constructor argument; nested
> exception is org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'clientAuthenticationEntryPoint' defined in class
> path resource [com/haulmont/addon/restapi/rest-dispatcher-spring.xml]:
> Instantiation of bean failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.springframework.security.oauth2.provider.error.OAuth2AuthenticationEntryPoint]:
> Constructor threw exception; nested exception is
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> 10:21:32.243 ERROR c.h.a.r.a.r.RestAPIDispatcherServlet- Context
> initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'org.springframework.security.filterChains': Cannot resolve
> reference to bean
> 'org.springframework.security.web.DefaultSecurityFilterChain#0' while
> setting bean property 'sourceList' with key [0]; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name
> 'org.springframework.security.web.DefaultSecurityFilterChain#0': Cannot
> create inner bean '(inner bean)#27690bd5' of type
> [org.springframework.security.web.authentication.www.BasicAuthenticationFilter]
> while setting constructor argument with key [4]; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name '(inner bean)#27690bd5': Cannot resolve reference to bean
> 'clientAuthenticationEntryPoint' while setting constructor argument; nested
> exception is org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'clientAuthenticationEntryPoint' defined in class
> path resource [com/haulmont/addon/restapi/rest-dispatcher-spring.xml]:
> Instantiation of bean failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.springframework.security.oauth2.provider.error.OAuth2AuthenticationEntryPoint]:
> Constructor threw exception; nested exception is
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> 
> 

javax.xml.bind libs 

Re: Using the certificate files instead of a Java Keystore file, Re: Let's Encrypt with Tomcat?

[logo]

James,

Am 2020-01-09 00:58, schrieb James H. H. Lampert:

I wrote:
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" 
and ".key" files directly, instead of the Java Keystore file?


On 12/30/19 1:41 PM, Peter Kreuser wrote:

Correct!


I tried an experiment this afternoon:

I made a copy of the existing server.xml file, and I changed the active
connector from this (keystore file and alias redacted for privacy,
ciphers and compressibleMimeTypes clauses redacted because they're
quite long, and not relevant here):
protocol="org.apache.coyote.http11.Http11NioProtocol"
 compression="on" compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata"

 compressableMimeType="[REDACTED]"
 maxThreads="1000" socket.appReadBufSize="1024" 
socket.appWriteBufSize="1024" bufferSize="1024"

 SSLEnabled="true" scheme="https" secure="true"
 keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
 clientAuth="false" sslProtocol="TLS" />


to this:
protocol="org.apache.coyote.http11.Http11NioProtocol"
 compression="on" compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata"

 compressableMimeType="[REDACTED]"
 maxThreads="1000" socket.appReadBufSize="1024" 
socket.appWriteBufSize="1024" bufferSize="1024"

 SSLEnabled="true" scheme="https" secure="true">
  
certificateKeyFile="[REDACTED].key"

 certificateChainFile="[REDACTED].ca.crt" />
  



and restarted Tomcat, and it failed to open the port, producing this
in catalina.out:
08-Jan-2020 23:14:09.026 SEVERE [main] 
org.apache.catalina.core.StandardService.initInternal Failed to 
initialize connector [Connector[HTTP/1.1-8443]]
 org.apache.catalina.LifecycleException: Failed to initialize 
component [Connector[HTTP/1.1-8443]]
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.startup.Catalina.load(Catalina.java:639)
at 
org.apache.catalina.startup.Catalina.load(Catalina.java:662)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.catalina.LifecycleException: Protocol handler 
initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)

... 12 more
Caused by: java.lang.IllegalArgumentException: Cannot store 
non-PrivateKeys
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
at 
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1105)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:224)
at 
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)

... 13 more
Caused by: java.security.KeyStoreException: Cannot store 
non-PrivateKeys
at 
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
at 
sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
at 
sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
at 
sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)

at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
at 
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
at 
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:239)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)

... 20 more




I recently came across a similar problem (at least the same error 
message), where the key was in an unsupported format (first line of the 
file: "BEGIN EC PRIVATE KEY"; Mark is working on a solution for this). 
What type of private key are you using? all files PEM 

Re: ECDSA Private Keys

[logo]

Hi Mark,

> Am 08.01.2020 um 19:04 schrieb Mark Thomas :
> 
> On 26/12/2019 23:55, logo wrote:
> 
> 
> 
>> as an EC certificate will start with EC PRIVATE KEY.
>> 
>> Is this something that is expected? ECDSA unsupported? Or just an incomplete 
>> implementation, edge case or a bug?
> 
> Hi,
> 
> Sorry for not getting to this sooner.
> 
> I'm not 100% sure that Java directly supports the format that includes:
> -BEGIN EC PRIVATE KEY-
> 
> 
> Initial research suggests you need to "update" the format of the key file:
> 
> openssl pkcs8 -topk8 -inform pem -in file.key -outform pem -nocrypt -out
> file.pem
> 
> I have confirmed that this updated key then works cleanly with both the
> OpenSSL and JSSE TLS implementations.
> 

Felix already suggested that. I've tried it and at first it looks good. 
Connector starts and serves the ECDSA cert.

Please see the last two emails with the findings of the testssl.sh scans. I 
don’t know but tomcat now also serves strange ciphers… (at least some that 
openssl doesn’t even support and the scanner gets some strange results!)

https://markmail.org/message/nj7lvuplld4c5nqx


> In theory, Tomcat should be able to do this conversion for you. The
> issue will be how much of the crypto API we need to do that is part of
> the public API and, where it isn't, how easy it is to craft our own.
> 
> I'm currently investigating…
> 

Thanks for your support. I got the people at smallstep to create an option to 
also create RSA certs. So there is currently a workaround to use their acme 
process with tomcat.

Peter


> Mark
> 
> -
> 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: Ignore duplicate HTTP headers in Tomcat 8.5.50-0+deb9u1

[logo]

Dennis,



Am 07.01.2020 um 08:10 schrieb Dennis Rech :

Hi Christopher,


Am 06.01.20 um 17:39 schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dennia,


On 1/6/20 07:09, Dennis Rech wrote:
we have an application where HTTP clients have a kind of unclean
way of submitting HTTP POST requests to our tomcat server for data
upload: The |POST| and |Host: xxx| part appears twice in the
request.

Yuck. You mean like this?

POST /foo HTTP/1.1
POST /foo HTTP/1.1
Host: foo.com
Host: foo.com
Content-Type: application/x-www-url-encoded
Content-Length: 13

q=Hello World

?


No, rather like that:

POST /foo HTTP/1.1
Host: foo.com
POST /foo HTTP/1.1
Host: foo.com
Content-[stuff] [...]



It could be worse. But at least the first two lines are protocol 
compliant.


As Chris mentioned you may add a reverse proxy like nginx or traefik in 
front of it and strip the lines - the POST line not a „real“ header 
though - before passing the request to tomcat.


Then if the first two lines are compliant, I wonder if a Valve on tomcat 
level could intercept the request and deal with the bad lines before 
reaching the app layer.


Peter




Until now this didn't cause any problems with tomcat, but since
the latest release, Tomcat refuses to accept this message and
returns a 400 bad request immediately.

Having two "host" headers should be okay. But repeating the request
line is a clear violation of the HTTP spec that will be difficult to
get over. I can't believe Tomcat ever allowed that, though it may have
done so.
I read in the changelog that since Tomcat 8.5.22 it will also reply 
with Bad request 400 if there are two Host fields in the header. But I 
guess the double "POST" is even worse.



Unfortunately we'll not be able to change the client-side code. Is
there any way to tell the tomcat connector "ignore duplicate
headers" or so to make it work again? I guess the rewrite filters
for tomcat won't help as tomcat probably discards the incoming
message before handing it over to rewrite.

Tomcat is responsible for reading the request line and routing the
request to an application. If the request is broken badly enough, it
won't be able to route.

Headers are parsed as a part of that, and:

POST /foo HTTP/1.1

is not a valid header for at least two reasons:

1. There is no : character (required, even when the header has no 
value)
2. There are spaces in the "name" (the name is everything before colon 
)
Well, "POST"... is the actual request followed by the HTTP headers. 
POST is not part of the actual header. Maybe I haven't pointed that 
out.



Example request:

|POST /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 POST
/data/upload/test HTTP/1.1 Host: www.myhost.de:8180 [...rest of
the request is ok...] |

This got word-wrapped. Was this?


Yes I copied it from a formatted document, the pipes probably indicate 
that this text was preformatted in the original document, sorry. Also 
the newlines are missing.


POST /data/upload/test HTTP/1.1
Host: www.myhost.de:8180
POST/data/upload/test HTTP/1.1
Host: www.myhost.de:8180
[...here comes the remaining header with Content-Length etc followed by 
the body...]





POST /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 POST
/data/upload/test HTTP/1.1 Host: www.myhost.de:8180 [...rest of the
request is ok...]

?

Yikes. What kind of client is this?
It's a remote unit transmitting data to a server using POST file 
uploads with - obviously - a little bug in the firmware that builds the 
HTTP request manually as there is no curl library for the unit etc. 
which can be used to generate the requests.



I wonder if there is a parameter for the |Connector| part in
server.xml or so to workaround this problem and restore the old
behaviour without downgrading.

The good news is that the second POST could theoretically be
considered to be a "broken" header and ignored. But Tomcat has been
getting progressively more strict about what it will accept. There are
all kinds of nasty ways to use malformed messages like this to confuse
environments where e.g. a reverse-proxy and the origin server behave
differently when they see requests like those above. It's better to
just fail and fix the software. Why can't you fix the clients? Is this
another case of internet-of-things garbage that can't practically be
repaired?


Something like that. The devices could be updated in theory but 
probably not over-the-air and many of them are already deployed 
somewhere in the "wild" so we don't have physical access to them 
anymore. Unfortunately we did not notice that in the past as tomcat 
always accepted these requests until the latest update for debian came 
out.


I totally agree that the best solution would be to let those devices 
send proper HTTP protocol but I guess we'll have to find a workaround 
on server-side.




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

Re: Tomcat 9 does not allow to read file in /tmp folder with 777 permission?

[logo]

Well - why do you think someone is calling you names? Mark did not, right?

> Am 06.01.2020 um 22:11 schrieb Zahid Rahman :
> 
> Are you calling me names  ?
> 
> On Mon, 6 Jan 2020, 20:35 Mark Thomas,  wrote:
> 
>> On 06/01/2020 16:29, Christopher Schultz wrote:
>>> You have a right to a view, and you can troll all you want. But you
>>> will be ignored.
>> 
>> Up to a point.
>> 
>> Users that continue to troll will be unsubscribed and blocked from
>> re-subscribing.
>> 
>> As a general reminder aimed at keeping noise down on the list:
>> 
>> Please don't feed the trolls.
>> 
>> 
>> Mark
>> 
>> -
>> 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: ECDSA Private Keys

[logo]

> Am 02.01.2020 um 17:13 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
> On 1/2/20 04:24, logo wrote:
> 
>> There may be an issue with the provided/available ciphers!
>> 
>> The connector comes up correctly, is accessible through the browser
>> but if I test the ssl setup, I get an error message that the
>> key/cert may not be used for "Key agreement"
>> 
>> See: testssl.sh :8443
>> 
>> Signature Algorithm  ECDSA with SHA256 Server key size
>> EC 256 bits Server key usage Digital Signature, Key
>> Encipherment Certificate incorrectly used for key agreement Server
>> extended key usageTLS Web Server Authentication, TLS Web Client
>> Authentication
>> 
>> I cannot find the reason for that yet, testssl complains if there
>> are TLS_ECDH_*-ciphers with the wrong server key usage. The setup
>> may be causing troubles in testssl.sh as Tomcat provides ciphers
>> that maybe should not be available with ECDSA certs (? _RSA???
>> Maybe even ECDH_ECDSA???)?
>> 
>> Testing 370 ciphers via OpenSSL plus sockets against the server,
>> ordered by encryption strength
>> 
>> Hexcode  Cipher Suite Name (OpenSSL)   KeyExch.   Encryption
>> Bits Cipher Suite Name (IANA/RFC) 
>> --
> - ---
>> 
>> 
>> 



>> There is probably more complexity to implementation of ECDSA in
>> Tomcat with JSSE?!?
> 
> I seem to remember a bug where Tomcat does not check the "usage" of a
> key before trying to use it. I couldn't find it in BZ, maybe it was
> fixed in some partial way.
> 
> What do those lists represent? All the cipher suites tried, or all
> that connected successfully?
> 

testssl.sh [1] tries a list of 370 ciphers. Apparently those are the successful 
socket connects.

[1] https://github.com/drwetter/testssl.sh

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4OFroACgkQHPApP6U8
> pFifJw//befvNHGem8GtKH5ds3bEdZk/nvxi1FsytOMA7YplenYI7LxnPrHYeQj0
> L6jUxgYJk5canTmCi/Zw2st03wCAXCfO+AHUYDu4TwA+Ml7ij+cmwtt5Di9onhg0
> c23bDS8WNkiTA6aW4dX5RgPj7+C60k8he+uLCpeoDjWh6b778IR7UcRdd+9uFdVU
> wx4ILhl1MNnbQeyH6UMolQA4ms+4HG09mDYcQwK4B5VejQnbtzud1hkB0mJJCCes
> MbSaE/6BA4cs9feHV8rzWqy1EW5v9MyfbgNweFMS2GJXHNr1mMiUbmW5clnGphL5
> OhLonEA8FFaceuutePz+LefQiznsbCBljSuKTB4nzy14KY3mDBAyxp3N3SLD+Rno
> Aowhp657foWlre652MORmgK7KZWGg8PZ3fxtIuGXFxk9uY0Ib0x3jvvMxm0XWMW0
> BysOmO1LW6kDKUBZSxBh1ZBq4hExySWdn2wT8n4tbYnPdDcun1EjXKSYofKevRXP
> +CDY8GER1TpLasiDbL9FHYcEtOIsKgGg85REfB13zlMkUNleTEinM7laLQnUFyIt
> hHB7Ua28lykMI3CpaOWDFfNhtzsRW5TRh7DT84OCqnnQQl3vz0Xxr6pg1dPT3M+o
> Ns3Hcr/MhgD05sOcA9i3hGRmtpRcYYznqQYdTMSxjb9HWzEjDpk=
> =A9OL
> -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: ECDSA Private Keys

[logo]

Felix,


> Am 01.01.2020 um 20:27 schrieb Felix Schumacher 
> :
> 
> 
>> Am 01.01.20 um 18:19 schrieb logo:
>> Felix,
>> 
>>>> Am 01.01.2020 um 11:49 schrieb Felix Schumacher 
>>>> :
>>> 
>>> 
>>> Am 27.12.19 um 17:36 schrieb logo:
>>>> Chris
>>>> 
>>>> Am 2019-12-27 16:33, schrieb Christopher Schultz:
>>>> Peter,
>>>> 
>>>> On 12/26/19 18:55, logo wrote:
>>>>>>> Hi Mark,
>>>> I hope it's okay if I reply. :)
>>>> 
>>>>> :-)
>>>> 
>>>> 
>>>>>>> I just recently tested Step CA (smallstep.com) as an internal CA
>>>>>>> that provides an internal ACME service.
>>>>>>> 
>>>>>>> After I deployed the created cert to my Tomcat (8.5.50 with
>>>>>>> adoptopenjdk 11) I noticed that while the openssl connector
>>>>>>> immediately started, the JSSE connector with the same cert would
>>>>>>> fail with a "java.security.KeyStoreException: Cannot store
>>>>>>> non-PrivateKeys“ I use the openssl XML certificate config also for
>>>>>>> JSSE.
>>>>>>> 
>>>>>>> It took me quite a while to figure this one out - as the message
>>>>>>> usually indicates a public key as cert. I noticed that Step Ca is
>>>>>>> creating ECDSA certs by default. The Openssl Connector delivers the
>>>>>>> new ECDSA cert just fine.
>>>>>>> 
>>>>>>> While Java (afaik) seems to be able to handle ECDSA, tomcat will
>>>>>>> fall through a case statement in
>>>>>>> org.apache.tomcat.util.net.jsse.PEMFile
>>>>>>> 
>>>>>>> When loading the PEM file parts it will skip all cases in
>>>>>>> 
>>>>>>> for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
>>>>>>> privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
>>>>>>> break; case "ENCRYPTED PRIVATE KEY": privateKey =
>>>>>>> part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
>>>>>>> case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
>>>>>>> keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
>>>>>>> CERTIFICATE": certificates.add(part.toCertificate()); break; } }
>>>>>>> 
>>>>>>> as an EC certificate will start with EC PRIVATE KEY.
>>>>>>> 
>>>>>>> Is this something that is expected? ECDSA unsupported? Or just an
>>>>>>> incomplete implementation, edge case or a bug?
>>>> EC should work. What does your  configuration look like?
>>>> 
>>>> 
>>>>>>>>>   protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>>>> 
>>>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>>>>>   maxThreads="150"
>>>>>   SSLEnabled="true" >
>>>>>>>> className="org.apache.coyote.http2.Http2Protocol" />
>>>>>
>>>>>>>>>  certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
>>>>>  certificateFile="${catalina.base}/conf/ssl/cert.pem"
>>>>>   />
>>>>>
>>>>>
>>>>> really basic.
>>>>> First I had a type attribute "RSA" but even ommitting this didn't
>>>> change it.
>>>> 
>>>>> Once Tomcat hits the PEMFile-Class the parts read from the
>>>> ECDSA-PEM-file are not transferred to a private key so the class
>>>> member "privateKey" is null. None of the cases above match "EC PRIVATE
>>>> KEY".
>>> The comments at the beginning of PEMFile state that it works for PKCS8,
>>> only. But the code makes an exception for RSA keys, so it probably makes
>>> sense to ad EC keys, too.
>>> 
>> Please!
> 
> After looking into the code, it doesn't look easy at all.
> 
> The code tries to stay away from oracles internal API for cryptography
> and the standard API is not very

Re: ECDSA Private Keys

[logo]

Felix,

> Am 01.01.2020 um 11:49 schrieb Felix Schumacher 
> :
> 
> 
> Am 27.12.19 um 17:36 schrieb logo:
>> Chris
>> 
>> Am 2019-12-27 16:33, schrieb Christopher Schultz:
>> Peter,
>> 
>> On 12/26/19 18:55, logo wrote:
>>>>> Hi Mark,
>> 
>> I hope it's okay if I reply. :)
>> 
>>> :-)
>> 
>> 
>> 
>>>>> I just recently tested Step CA (smallstep.com) as an internal CA
>>>>> that provides an internal ACME service.
>>>>> 
>>>>> After I deployed the created cert to my Tomcat (8.5.50 with
>>>>> adoptopenjdk 11) I noticed that while the openssl connector
>>>>> immediately started, the JSSE connector with the same cert would
>>>>> fail with a "java.security.KeyStoreException: Cannot store
>>>>> non-PrivateKeys“ I use the openssl XML certificate config also for
>>>>> JSSE.
>>>>> 
>>>>> It took me quite a while to figure this one out - as the message
>>>>> usually indicates a public key as cert. I noticed that Step Ca is
>>>>> creating ECDSA certs by default. The Openssl Connector delivers the
>>>>> new ECDSA cert just fine.
>>>>> 
>>>>> While Java (afaik) seems to be able to handle ECDSA, tomcat will
>>>>> fall through a case statement in
>>>>> org.apache.tomcat.util.net.jsse.PEMFile
>>>>> 
>>>>> When loading the PEM file parts it will skip all cases in
>>>>> 
>>>>> for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
>>>>> privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
>>>>> break; case "ENCRYPTED PRIVATE KEY": privateKey =
>>>>> part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
>>>>> case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
>>>>> keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
>>>>> CERTIFICATE": certificates.add(part.toCertificate()); break; } }
>>>>> 
>>>>> as an EC certificate will start with EC PRIVATE KEY.
>>>>> 
>>>>> Is this something that is expected? ECDSA unsupported? Or just an
>>>>> incomplete implementation, edge case or a bug?
>> 
>> EC should work. What does your  configuration look like?
>> 
>> 
>>>  >> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>>
>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>>> maxThreads="150"
>>> SSLEnabled="true" >
>>>  > className="org.apache.coyote.http2.Http2Protocol" />
>>>  
>>>  >>certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
>>>certificateFile="${catalina.base}/conf/ssl/cert.pem"
>>> />
>>>  
>>>  
>> 
>>> really basic.
>>> First I had a type attribute "RSA" but even ommitting this didn't
>> change it.
>> 
>>> Once Tomcat hits the PEMFile-Class the parts read from the
>> ECDSA-PEM-file are not transferred to a private key so the class
>> member "privateKey" is null. None of the cases above match "EC PRIVATE
>> KEY".
> 
> The comments at the beginning of PEMFile state that it works for PKCS8,
> only. But the code makes an exception for RSA keys, so it probably makes
> sense to ad EC keys, too.
> 

Please!

> Have you tried to convert your key to pkcs8?
> 

Thanks! That works fine!

openssl pkcs8 -topk8 -nocrypt -in ssl/privkey.pem -out ssl/privkey-p8.pem

Happy new Year!

Peter

> Felix
> 
>> 
>>> Peter
>> 
>> -chris
>>> 
>>> -
>>> 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
> 


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

Re: ECDSA Private Keys

[logo]

Chris

Am 2019-12-27 16:33, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/26/19 18:55, logo wrote:

Hi Mark,


I hope it's okay if I reply. :)


:-)





I just recently tested Step CA (smallstep.com) as an internal CA
that provides an internal ACME service.

After I deployed the created cert to my Tomcat (8.5.50 with
adoptopenjdk 11) I noticed that while the openssl connector
immediately started, the JSSE connector with the same cert would
fail with a "java.security.KeyStoreException: Cannot store
non-PrivateKeys“ I use the openssl XML certificate config also for
JSSE.

It took me quite a while to figure this one out - as the message
usually indicates a public key as cert. I noticed that Step Ca is
creating ECDSA certs by default. The Openssl Connector delivers the
new ECDSA cert just fine.

While Java (afaik) seems to be able to handle ECDSA, tomcat will
fall through a case statement in
org.apache.tomcat.util.net.jsse.PEMFile

When loading the PEM file parts it will skip all cases in

for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
break; case "ENCRYPTED PRIVATE KEY": privateKey =
part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
CERTIFICATE": certificates.add(part.toCertificate()); break; } }

as an EC certificate will start with EC PRIVATE KEY.

Is this something that is expected? ECDSA unsupported? Or just an
incomplete implementation, edge case or a bug?


EC should work. What does your  configuration look like?



   
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"

   maxThreads="150"
   SSLEnabled="true" >
className="org.apache.coyote.http2.Http2Protocol" />






really basic.
First I had a type attribute "RSA" but even ommitting this didn't change 
it.


Once Tomcat hits the PEMFile-Class the parts read from the 
ECDSA-PEM-file are not transferred to a private key so the class member 
"privateKey" is null. None of the cases above match "EC PRIVATE KEY".


Peter


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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJDIACgkQHPApP6U8
pFi1HBAAxzrE1P4o2nj9/6/nr9sVEiPOusw30P2YnaJGvvkv2jvHoj1TITGVlaTg
Y/Oy4GPA7NEn0ofRPFwaphL0+kETxZyHSBotxtlsOZsg2aLj2tLKCmwCZe2UfPcA
nRmVtn+TgPOHOb3x+sSKhOzv73SjbnqVVRQLCa/4t/D/S8nfR6Lc9yqPibLI4y/+
+gqnKhs7TW5f74ZAMjLlWKrEwbsr1KRcCW7G4vA6859fxDtPSckPR5MoHBe3H/pK
2D26EoNb5jZ5McxgM9xmGe74lYXp3XVOQLEOZnBNAjGd6VWs4oyHFbc3/800vD6E
gyQLgFonupS0XE3gj0cy3HVWggSQhd9AlQXwyBNQg8UWA4tQNhRiPTvgX5gAYWnf
AHBKPb5LpDm8cEkCM63Ow92ce4a6JHFBxEs2TX2h14iHGCk1ARERiM2tgltugxub
vmkJLGkDGd6EM2B62Wv8dnA6/1qtebgrW6IcZrESEKaP3T5qYivs5uUq4sYLXMho
G8v24Om8tRDOCoE1gl+UIWRsoMZQttOJSYwbBriOWa7OJ3PSq3nzE22zSgqhqHOh
QwPBXMSYQNz6aMXKxCwwS5GjdrRQqIQINi8YbRf4Wjre4zZNIzPJ4FgDtROQYl85
32Gsa4pcwyEtM2a+8iH98dXhpP5ST1CxCiGXhlzEFmXbFgSadKg=
=aSBb
-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: Let's Encrypt with Tomcat?

[logo]

Chris,

Am 2019-12-27 16:40, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 12/27/19 07:24, logo wrote:

Hi James,

Am 2019-12-27 05:31, schrieb Igal Sapir:

James,

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:


We have a Tomcat (8.5.40) server running on an Amazon EC2
instance, currently using a Java Keystore for the SSL support.

We would like to be able to use Let's Encrypt, but I've learned
that Let's Encrypt and Tomcat don't get along all that well
together. The best I've found so far are article at:

<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-

3db8a469e3d2








and this thread in the Let's Encrypt community forum:

<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with

- -tomcat/81423








Does anybody here have any experience with situations like
this? Does anybody here have any suggestions? Or, as another
alternative, does anybody here know of some Amazon AWS product
that could front-end a single-box, non-load-balanced Tomcat
server, and use Amazon's free "Public Certificates"? (I've
already posted that last to the relevant Amazon forum.)



You should check out Chris' presentations on the topic.  He
outlines a very efficient process.  There is probably more
materials out there, but a quick search brings up the video [1]
and slides [2] from his presentation at ApacheCon earlier this
year, as well as his shell script for automating the process.

Igal

[1] https://www.youtube.com/watch?v=BWUjvmJgSeE [2]
<https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Enc

rypt%20Apache%20Tomcat.pdf>





https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt
%20Apache%20Tomcat.pdf


[3]
https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt

- -renew.sh









+1


Currently the script is broken


Really?


, as there is a bug in the JMX implementation of Tomcat 8.5 that
is fixed from 8.5.51.


Can you explain? I'll fix the script if there is something missing. I
*do* have to make the conversion from PEM -> PKCS12 optional.
keystores just suck.



well not really the script. I should say explicitly it will not work on 
8.5 as JMX reloadSSLConfigs is broken. See: 
https://markmail.org/thread/renoatnedduquebm

Mark already fixed it for 8.5.51.


Once that is released it is really easy to automate the letsencrypt
acme process with [3].

Tomcat 8.5 brings a new way to configure certificates [4]. You can
use pem encoded certs even in the JSSE implementation. So you can
just save/copy the certs from LE to your certificate directory (in
my case ${catalina.base}/conf/ssl):



After certbot has finished, reload the SSL config for the updated
Host through the jmxproxy and you are done.


That's the plan. In Las Vegas, Christopher Tubbs did say to me "aw, I
was really hoping for you to tell us that you just set
letsEncrypt="true" in your configuration and you are done". So there
is definitely more that can be done, here.

The plan was to try to get someone to integrate my script (or
equivalent) into certbot or other ACME clients. Maybe what we really
need is a command that can be run that "gracefully" restarts the
server -- like httpd already does. There is no reason to actually
restart the server -- just reinitialize the TLS engine for the
connector. So maybe what we need is a script that basically just hits
the jmxproxy to reinit the connector and tell certbot to use that when
it's done with the ACME stuff.


oh I get the idea! a hook-script, right?

Like the 2nd part of your script. well specifically it could reload only 
the SSLHostConfig affected by this new cert
curl 
"https:/$JMXUSER:$JMXPASSWORD@localhost:${SERVICE_PORT}/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port={CONNECTOR_PORT}=reloadSslHostConfig=${HOSTNAME}"


Or did you think about a bin/version.sh type script? That would get a +1 
from me. What I don't like is, that one needs to add credentials in 
tomcat-users.xml and expose the manager-interface.




I don't think it's necessary to build ACME into Tomcat itself when
tools like certbot already exist for that purpose, and admins will be
more familiar with those than some server-specific configuration.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJeMACgkQHPApP6U8
pFj6gA/+NS5ZO6IJZ8W8/XT7usLq8wG+B0VuRFGzPhERam0XqBFEe59AvW+LXpIa
ChUy/eZYkrtGmRX7ZhSr/njD3mEhp+3R2XVgM91kPg4WWIkpAeLixuJOaoqn5QZU
jDr9sWpe190i2RI/OKlki/ADJ6oEemJsF3HElW4YcSYtWnqgmjAzncCJDJd3xvrq
bCskiXd4ru7Afg0T0hv/B8B62W5DgtuvB0GqmTsQBElZ9cTpGMJFJFH3WUfVBwZV
jpE/X/jmArYnU/lJIf22of8+zZgCYxEDGmiNGhZxPMh+A8lkn71fyfXJ3ZojijIm
p29KSSWJX0GPcJpIq7xxs4tmvmehIErjxPyacTcGwEhhY0TCKA7aGnh8yrVrFJcs
Tvz/2CmPvDva37/d32Knv9mv+Niw2ia8TGD6SFmaxmlNLxWR9nB9i+VobY

Re: Let's Encrypt with Tomcat?

[logo]

Hi James,

Am 2019-12-27 05:31, schrieb Igal Sapir:

James,

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:


We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
currently using a Java Keystore for the SSL support.

We would like to be able to use Let's Encrypt, but I've learned that
Let's Encrypt and Tomcat don't get along all that well together. The
best I've found so far are article at:

<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
>

and this thread in the Let's Encrypt community forum:

<
https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
>

Does anybody here have any experience with situations like this? Does
anybody here have any suggestions? Or, as another alternative, does
anybody here know of some Amazon AWS product that could front-end a
single-box, non-load-balanced Tomcat server, and use Amazon's free
"Public Certificates"? (I've already posted that last to the relevant
Amazon forum.)



You should check out Chris' presentations on the topic.  He outlines a 
very
efficient process.  There is probably more materials out there, but a 
quick

search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as well as his shell script for automating 
the

process.

Igal

[1] https://www.youtube.com/watch?v=BWUjvmJgSeE
[2]

https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf
[3]
https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt-renew.sh



+1

Currently the script is broken, as there is a bug in the JMX 
implementation of Tomcat 8.5 that is fixed from 8.5.51.


Once that is released it is really easy to automate the letsencrypt acme 
process with [3].


Tomcat 8.5 brings a new way to configure certificates [4]. You can use 
pem encoded certs even in the JSSE implementation.
So you can just save/copy the certs from LE to your certificate 
directory (in my case ${catalina.base}/conf/ssl):


  certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"

   certificateFile="${catalina.base}/conf/ssl/cert.pem"
   
certificateChainFile="${catalina.base}/conf/ssl/chain.pem"

   type="RSA" />

After certbot has finished, reload the SSL config for the updated Host 
through the jmxproxy and you are done.


Hope that helps.

Peter

[4] 
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig








James H. H. Lampert
Touchtone Corporation

-
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

ECDSA Private Keys

[logo]

Hi Mark,

I just recently tested Step CA (smallstep.com) as an internal CA that provides 
an internal ACME service.

After I deployed the created cert to my Tomcat (8.5.50 with adoptopenjdk 11) I 
noticed that while the openssl connector immediately started, the JSSE 
connector with the same cert would fail with a 
"java.security.KeyStoreException: Cannot store non-PrivateKeys“
I use the openssl XML certificate config also for JSSE.

It took me quite a while to figure this one out - as the message usually 
indicates a public key as cert. I noticed that Step Ca is creating ECDSA certs 
by default. The Openssl Connector delivers the new ECDSA cert just fine.

While Java (afaik) seems to be able to handle ECDSA, tomcat will fall through a 
case statement in org.apache.tomcat.util.net.jsse.PEMFile

When loading the PEM file parts it will skip all cases in

for (Part part : parts) {
switch (part.type) {
case "PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, 
Format.PKCS8);
break;
case "ENCRYPTED PRIVATE KEY":
privateKey = part.toPrivateKey(password, keyAlgorithm, 
Format.PKCS8);
break;
case "RSA PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, 
Format.PKCS1);
break;
case "CERTIFICATE":
case "X509 CERTIFICATE":
certificates.add(part.toCertificate());
break;
}
}

as an EC certificate will start with EC PRIVATE KEY.

Is this something that is expected? ECDSA unsupported? Or just an incomplete 
implementation, edge case or a bug?

Best regards

Peter




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

UPDATED: JMX reloadSslHostConfigs fails with javax.management.RuntimeOperationsException

[logo]

Hi all,

More analysis and now getting to a weird point:

Chain of events:
———

Start tomcat with SSL and JMX enabled…

Reload SSL config with JMX (this time for only one host)

> curl -u user:pass 
> "https://docker2:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=docker2“

OK - Operation reloadSslHostConfig without return value

Now query the same certificate with JMX

> curl -u user:pass  
> 'https://docker2:8443/manager/jmxproxy?qry=Catalina:type=SSLHostConfig,ThreadPool="https-jsse-nio2-8443",name="docker2;'

OK - Number of results: 1
…

I see that an *empty* Default certificate is added to SSLHostConfigs at 
SSLHostConfig.java:217

private void registerDefaultCertificate() {
if (defaultCertificate == null) { // <<< ???
defaultCertificate = new SSLHostConfigCertificate(
this, SSLHostConfigCertificate.Type.UNDEFINED);  // << MEEK
certificates.add(defaultCertificate);
}
}

WAIT: it’s called from here:

// --- OpenSSL specific configuration properties

// TODO: These certificate setters can be removed once it is no longer
// necessary to support the old configuration attributes (Tomcat 10?).

public String getCertificateChainFile() {
registerDefaultCertificate();
return defaultCertificate.getCertificateChainFile();
}


And the callstack:

SSLHostConfig.registerDefaultCertificate() line: 217
SSLHostConfig.getCertificateChainFile() line: 733   
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available 
[native method]  
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 566  
BaseModelMBean.getAttribute(String) line: 176   
DefaultMBeanServerInterceptor.getAttribute(ObjectName, String) line: 641
JmxMBeanServer.getAttribute(ObjectName, String) line: 678   


Now Reload SSL config with JMX

> curl -u user:pass 
> "https://docker2:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=docker2“

javax.management.RuntimeOperationsException…


Apparently there are two certs in the config now for this host. The *empty* 
Default certificate is loaded and SSLUtilBase.java:301 fails as there is no 
certificate file in the Keystore.


Mark can you confirm that this is a bug?

Thanks and have a nice Sunday

Peter



> Am 14.12.2019 um 18:29 schrieb logo :
> 
> Hi all,
> 
> I have a problem with the reloading of my ssl configs after an update of 
> certs from LetsEncrypt or my internal CA.
> 
> Tomcat is 8.5.50, JDK is 11.0.5+10-post-Debian-2
> 
> I have used basically Christopher Schultz’s tool from 
> https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin 
> <https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin>.
> 
> 
> ▶ curl -u user:pass 
> "https://host:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs
>  
> <https://host:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs>"
> Error - javax.management.RuntimeOperationsException: Exception invoking 
> method reloadSslHostConfigs
> javax.management.RuntimeOperationsException: Exception invoking method 
> reloadSslHostConfigs
>   at 
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:295)
>   at 
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
>   at 
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(JMXProxyServlet.java:273)
>   at 
> org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyServlet.java:207)
>   at 
> org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:116)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.apache.catalina.filters.HttpHeaderSecurityFilter.do

JMX reloadSslHostConfigs fails with javax.management.RuntimeOperationsException

[logo]

Hi all,

I have a problem with the reloading of my ssl configs after an update of certs 
from LetsEncrypt or my internal CA.

Tomcat is 8.5.50, JDK is 11.0.5+10-post-Debian-2

I have used basically Christopher Schultz’s tool from 
https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin.


▶ curl -u user:pass 
"https://host:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs;
Error - javax.management.RuntimeOperationsException: Exception invoking method 
reloadSslHostConfigs
javax.management.RuntimeOperationsException: Exception invoking method 
reloadSslHostConfigs
at 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:295)
at 
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
at 
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at 
org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(JMXProxyServlet.java:273)
at 
org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyServlet.java:207)
at 
org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:116)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:668)
at 
org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:348)
at 
org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:52)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
at 
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:747)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at 
org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:324)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at 
org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:69)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: 
java.lang.IllegalArgumentException
at 
org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:252)
at 
org.apache.tomcat.util.net.AbstractEndpoint.reloadSslHostConfig(AbstractEndpoint.java:311)
at 
org.apache.tomcat.util.net.AbstractEndpoint.reloadSslHostConfigs(AbstractEndpoint.java:320)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.reloadSslHostConfigs(AbstractHttp11Protocol.java:517)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

Re: remote jmx monitoring through ssh tunnel

[logo]

Chris

> Am 11.12.2019 um 21:46 schrieb Chris Cheshire  >:
> 
> Peter,
> 
> On Wed, Dec 11, 2019 at 2:38 AM Peter Kreuser  > wrote:
>> 
>> Chris‘,
>> 
>>> Am 10.12.2019 um 18:59 schrieb Chris Cheshire >> >:
>>> 
>>> On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire >> > wrote:
 
> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz
> mailto:ch...@christopherschultz.net>> 
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Chris,
> 
> On 12/9/19 17:10, Chris Cheshire wrote:
>> In CATALINA_BASE/bin/setenv.sh I have the following :
>> 
>> CATALINA_OPTS="-Dcom.sun.management.jmxremote
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false"
> 
> Okay.
> 
>> In CATALINA_BASE/conf/server.xml I have a listener configured :
>> 
>> > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>> rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>> useLocalPorts="true" />
>> 
>> 
>> Upon startup I see in logs : INFO [main]
>> org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer
>> The JMX Remote Listener has configured the registry on port
>> [10001] and the server on port [10002] for the [Platform] server
>> 
>> 
>> 
>> I didn‘t read it anywhere. Did you add the catalina-jmx.jar to the classpath?
>> 
>> Peter
>> 
> 
> What is that jar and where does it come from? I don't see it in the TC
> 9 distribution, nor can I find mention of it in the docs [1] [2]
> 

https://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener
 


It’s called catalina-jmx-remote.jar and it’s an extra DL 
https://tomcat.apache.org/download-80.cgi#8.5.49 
 see „Extras"

Peter


> Chris
> 
> [1] https://tomcat.apache.org/tomcat-9.0-doc/monitoring.html 
> 
> [2] https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

smime.p7s
Description: S/MIME cryptographic signature

Re: Global Error Handling

[logo]

Sumit,


Am 2019-12-03 13:11, schrieb Sumit Bhardwaj:

Hi Experts,

We have a requirement from a customer, where in case of 404, where 
someone
is putting an invalid url, instead of showing the default error, we 
should

be showing a custom message.

Is this possible?

I have searched and found couple of solutions similar to
https://stackoverflow.com/questions/27859626/tomcat-server-change-default-http-404


but these did not work, these work at the app level, but not globally 
on

tomcat level.


this can also be configured on the global web.xml. An alternative way 
would be a CustomErrorReportValve that can be configured on the 
Host-Element in server.xml.


  autoDeploy="false" deployXML="true" 
errorReportValveClass="whatever.tomcat.valves.CustomErrorReportValve">


see: 
https://tomcat.apache.org/tomcat-8.5-doc/config/host.html#Common_Attributes 
-> errorReportValveClass


One link I found is 
https://aspiresoftware.in/blog/catalinatomcat-custom-error-report-valve-to-handle-errors-exceptions/


Best regards

Peter



e.g. if i have an app called myapp

http:///myapp/ This  works and it gets
redirected to custom page

but

http:///, This does not work and 404 is 
shown,


Is there someway we can handle errors at global level on tomca.t

We are using tomcat 9.0.24.

Thanks for your help.

Best
Sumit Bhardwaj


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

Re: postgresql jndi datasource with certificate authentication?

[logo]

Arpad and Chris,


Am 2019-10-22 18:07, schrieb Christopher Schultz:

Magosányi,

On 10/22/19 11:09, Magosányi Árpád wrote:
As I understand you are suggesting to use direct connection to the 
database.

The servlet needs a JNDI datasource, and the question is about
configuring that datasource in tomcat.
As I can modify the servlet, I could choose to set up hibernate in 
other

ways, but I would like to separate the concerns of providing the
database and using it between the operations staff and development.
And JNDI is exactly for that.


I think Peter was suggesting that you change your connection URL and
the format of your keystore.



+1


PKCS#8 is not a recognized format for Java keystores; you'll need to
use JKS or PKCS#12 (recommended, as JKS is being deprecated).



I was looking for the right type name. Thanks Chris.

Peter


-chris


On 10/22/19 2:27 PM, logo wrote:

Arpad,

have you tried sth like this:

 StringBuffer sb = new
StringBuffer("jdbc:postgresql://infra.kodekonveyor.com:5432/users?useSSL=true=true=UTF-8&");
 sb.append("user=market=&");

sb.append("clientCertificateKeyStoreUrl=file:var/lib/tomcat9/.postgresql/client.jks&");

 sb.append("clientCertificateKeyStorePassword=changeit");

 Connection c = DriverManager.getConnection(sb.toString());

and convert the pem certificate to JKS/P12 ? I have this working in
mysql...

Peter

Am 2019-10-22 12:56, schrieb Magosányi Árpád:

Hi!

Anyone have a postgresql jndi datasource with certificate 
authentication

working?

I have the following in context.xml:

   
url="jdbc:postgresql://infra.kodekonveyor.com:5432/users?ssl=truesslmode=verify-ca"


   username="market" maxTotal="20" maxIdle="10"
   maxWaitMillis="-1"/>

I have this in ~tomcat/.postgresql:

root@market:/var/lib/tomcat9/.postgresql# ls -lL
total 11
-rw-r--r-- 1 root   root 4597 Oct 21 12:49 postgresql.crt
-r 1 tomcat root 1329 Oct 21 17:40 postgresql.pk8
-rw-r--r-- 1 root   root 1493 Oct 21 12:49 root.crt

where the crt file is a pem client certificate, root.crt is the ca 
cert,

and pk8 is the client key in der pkcs-8 format.

The logs:

  NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
  Server version name:   Apache Tomcat/9.0.16 (Ubuntu)
  Server built:  Sep 11 2019 19:47:51 UTC
  Server version number: 9.0.16.0
  OS Name:   Linux
  OS Version:4.15.0-65-generic
  Architecture:  amd64
  Java Home: /usr/lib/jvm/java-11-openjdk-amd64
  JVM Version:   11.0.4+11-post-Ubuntu-1ubuntu218.04.3
  JVM Vendor:Ubuntu
  CATALINA_BASE: /var/lib/tomcat9
  CATALINA_HOME: /usr/share/tomcat9
  Command line argument: 
--add-opens=java.base/java.lang=ALL-UNNAMED
  Command line argument: 
--add-opens=java.base/java.io=ALL-UNNAMED

  Command line argument:
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
  Command line argument:
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
  Command line argument:
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
  Command line argument: -Djava.awt.headless=true
  Command line argument: -XX:+UseG1GC
  Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
  Command line argument:
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
  Command line argument:
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
  Command line argument: -Dignore.endorsed.dirs=
  Command line argument: -Dcatalina.base=/var/lib/tomcat9
  Command line argument: -Dcatalina.home=/usr/share/tomcat9
  Command line argument: -Djava.io.tmpdir=/tmp
  Loaded APR based Apache Tomcat Native library [1.2.21] using 
APR

version [1.6.3].
  APR capabilities: IPv6 [true], sendfile [true], accept filters
[false], random [true].
  APR/OpenSSL configuration: useAprConnector [false], useOpenSSL
[true]
  OpenSSL successfully initialized [OpenSSL 1.1.1  11 Sep 2018]
  Initializing ProtocolHandler ["ajp-nio-8009"]
  Server initialization in [1,859] milliseconds
  Starting service [Catalina]
  Starting Servlet engine: [Apache Tomcat/9.0.16 (Ubuntu)]
  Deploying web application archive
[/var/lib/tomcat9/webapps/market.war]
  SLF4J: Class path contains multiple SLF4J bindings.
  SLF4J: Found binding in
[jar:file:/var/lib/tomcat9/webapps/market/WEB-INF/lib/slf4j-simple-1.7.24.jar!/org/slf4j/impl/StaticLoggerBinder.class]

  SLF4J: Found binding in
[jar:file:/var/lib/tomcat9/webapps/market/WEB-INF/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]

  SLF4J:

Re: postgresql jndi datasource with certificate authentication?

[logo]

Arpad,

have you tried sth like this:

StringBuffer sb = new 
StringBuffer("jdbc:postgresql://infra.kodekonveyor.com:5432/users?useSSL=true=true=UTF-8&");

sb.append("user=market=&");

sb.append("clientCertificateKeyStoreUrl=file:var/lib/tomcat9/.postgresql/client.jks&");

sb.append("clientCertificateKeyStorePassword=changeit");

Connection c = DriverManager.getConnection(sb.toString());

and convert the pem certificate to JKS/P12 ? I have this working in 
mysql...


Peter

Am 2019-10-22 12:56, schrieb Magosányi Árpád:

Hi!

Anyone have a postgresql jndi datasource with certificate 
authentication

working?

I have the following in context.xml:

    

I have this in ~tomcat/.postgresql:

root@market:/var/lib/tomcat9/.postgresql# ls -lL
total 11
-rw-r--r-- 1 root   root 4597 Oct 21 12:49 postgresql.crt
-r 1 tomcat root 1329 Oct 21 17:40 postgresql.pk8
-rw-r--r-- 1 root   root 1493 Oct 21 12:49 root.crt

where the crt file is a pem client certificate, root.crt is the ca 
cert,

and pk8 is the client key in der pkcs-8 format.

The logs:

 NOTE: Picked up JDK_JAVA_OPTIONS: 
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
 Server version name:   Apache Tomcat/9.0.16 (Ubuntu)
 Server built:  Sep 11 2019 19:47:51 UTC
 Server version number: 9.0.16.0
 OS Name:   Linux
 OS Version:    4.15.0-65-generic
 Architecture:  amd64
 Java Home: /usr/lib/jvm/java-11-openjdk-amd64
 JVM Version:   11.0.4+11-post-Ubuntu-1ubuntu218.04.3
 JVM Vendor:    Ubuntu
 CATALINA_BASE: /var/lib/tomcat9
 CATALINA_HOME: /usr/share/tomcat9
 Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
 Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
 Command line argument:
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
 Command line argument:
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
 Command line argument:
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 Command line argument: -Djava.awt.headless=true
 Command line argument: -XX:+UseG1GC
 Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
 Command line argument:
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
 Command line argument:
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
 Command line argument: -Dignore.endorsed.dirs=
 Command line argument: -Dcatalina.base=/var/lib/tomcat9
 Command line argument: -Dcatalina.home=/usr/share/tomcat9
 Command line argument: -Djava.io.tmpdir=/tmp
 Loaded APR based Apache Tomcat Native library [1.2.21] using APR
version [1.6.3].
 APR capabilities: IPv6 [true], sendfile [true], accept filters
[false], random [true].
 APR/OpenSSL configuration: useAprConnector [false], useOpenSSL 
[true]

 OpenSSL successfully initialized [OpenSSL 1.1.1  11 Sep 2018]
 Initializing ProtocolHandler ["ajp-nio-8009"]
 Server initialization in [1,859] milliseconds
 Starting service [Catalina]
 Starting Servlet engine: [Apache Tomcat/9.0.16 (Ubuntu)]
 Deploying web application archive 
[/var/lib/tomcat9/webapps/market.war]

 SLF4J: Class path contains multiple SLF4J bindings.
 SLF4J: Found binding in
[jar:file:/var/lib/tomcat9/webapps/market/WEB-INF/lib/slf4j-simple-1.7.24.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in
[jar:file:/var/lib/tomcat9/webapps/market/WEB-INF/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for 
an

explanation.
 SLF4J: Actual binding is of type 
[org.slf4j.impl.SimpleLoggerFactory]

 3 Spring WebApplicationInitializers detected on classpath
 onStartup
 getContext
 getRootConfigClasses
 [main] INFO com.kodekonveyor.market.WebInitializer -
getRootConfigClasses
 getServletConfigClasses
 [main] INFO com.kodekonveyor.market.WebInitializer -
getServletConfigClasses
 getServletMappings
 [main] INFO com.kodekonveyor.market.WebInitializer - 
getServletMappings
 At least one JAR was scanned for TLDs yet contained no TLDs. 
Enable

debug logging for this logger for a complete list of JARs that were
scanned but no TLDs were found in them. Skipping unneeded JARs during
scanning can improve startup time and JSP compilation time.
 Initializing Spring root WebApplicationContext
 [main] INFO org.springframework.web.context.ContextLoader - Root
WebApplicationContext: initialization started
 [main] INFO
org.springframework.data.repository.config.RepositoryConfigurationDelegate
- Bootstrapping Spring Data repositories in DEFAULT mode.
 [main] INFO
org.springframework.data.repository.config.RepositoryConfigurationDelegate
- 

Re: Security issue involving HTTP response headers

[logo]

Hi James,

see below:

Am 2019-10-21 23:34, schrieb James H. H. Lampert:


 httpHeaderSecurity
 
org.apache.catalina.filters.HttpHeaderSecurityFilter

 
 antiClickJackingOption
 SAMEORIGIN
 




Mark mentioned it before, that can also go into your apps web.xml and 
instead of activating it for the whole tomcat instance, can only apply 
to your app.


You can also remove the antiClickJacking option 
(antiClickJackingEnabled=false) or extend it like this:


X-Frame-Options: allow-from https://example.com/

see 
https://developer.mozilla.org/de/docs/Web/HTTP/Headers/X-Frame-Options


But that will affect also your app.

BTW: if you add this only to your app, the system will still "fail" all 
security scans, as most scanners will run on IPs or the root context and 
then see that the headers are missing. So the other app will need a fix 
too.


HTH,

Peter


In the filter mapping section of the web.xml add the following.


 httpHeaderSecurity
 /*
 REQUEST



Before I installed the above filter on the customer box (which *only*
serves the webapp for our product), I tested it on our own box. And
seeing no immediate problems, I didn't bother to pull it out of our
box.

Then I discovered that another webapp sharing the Tomcat server on our
box, one that *by design* is placed in a frame, in a page residing on
another server, had stopped working. With the filter in place, it
works fine if you go directly to the page, but it fails if you go to
the page on the other server.

That raises two questions:

1. Is there something I can set in the above code, in order to allow
this webapp to appear in the aforementioned frame where it is supposed
to appear, but not if it's put in a frame on some other arbitrary
page, elsewhere?

2. Are there other side effects of the HTTP header security filter
that I should know about? It seems that on the aforementioned customer
box, something happened recently that seems to be keeping our webapp
from exporting M$ Excel files to the user. We don't think it's related
(and have reason to believe it isn't), but one never can tell, and it
never hurts to ask.

--
James H. H. Lampert
(As my freshman woodshop teacher in high school was fond of saying,
"The only dumb question is the one that doesn't get asked.")

-
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: Problem with OpenSSL cipher suites -what's wrong with this configuration?

[logo]

Mark,

Am 08.08.2019 11:45, schrieb Mark Thomas:

On 08/08/2019 10:15, Alten, Jessica-Aileen wrote:

Therefore, I guess Tomcat cannot interpret these cipher suites for TLS 
1.3. So is this possibly a bug in Tomcat with openSSL 1.1.1c
and JDK 8 (again: I am not talking about JSSE here, it can only do TLS 
1.2)?


Tomcat supports configuring the ciphers for TLSv1.2 and below.

Tomcat does not (yet) support configuring the ciphersuites for TLS1.3
and above.


that's good to know. Any timeline (if it is necessary at all)? Does that 
mean if only protocol is TLSv1.3, no cipher string is used? Or only the 
TLS1.3 ciphers? Should "HIGH:..." work?


Peter



Mark

-
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: Support Request for problem with problem running SSL certificate on tomcat 8

[logo]

Munzer,



Am 2019-08-07 09:19, schrieb Peter Kreuser:

Hi Munzer,

I guess we‘re going a slightly awkward way here, but to fix your
problem with the new cert in the first place, you could use this:

If your keystore is the old proprietary format, convert it to PKCS12:
keytool -importkeystore -srckeystore keystore.jks -destkeystore
keystore.p12 -deststoretype PKCS12 -srcalias tomcat -deststorepass
 -destkeypass 
Then extract the key using openssl:
openssl pkcs12 -in keystore.p12 -nocerts -out key.pem
After that recombine it with the new cert.
I‘ve found this here: https://security.stackexchange.com/a/66865

There has to be an easier way, but as your keystore is causing
troubles, I‘m not really able to troubleshoot that.



now I've replayed your commands and selfsigned the csr with my ca. I see 
the same behaviour on tomcat10.keystore!


BT! If I replace tomcat14.keystore in the first two commands with 
tomcat10.keystore the generated cert is imported as a PrivateKeyEntry. 
:-)


Well IF you did it like you send in the first mail, you imported the ca 
and the intermediate certificate into a different (unused?) keystore!!!


Could you please doublecheck?


Peter

BTW: did you get warnings on the console that the JKS-keystore format is 
a proprietary format and should be converted to pkcs12?



After all, you may have to reread on cert handling with keytool vs. 
openssl.

I prefer the openssl way ;-).

Peter



Peter Kreuser
Am 06.08.2019 um 19:50 schrieb Munzer Khatib 
:


Hi Peter
I dont have the private key file. That is created when I create the 
keystore. I dont know if it can be extracted.

Munzer
   On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
 wrote:


Hi,


Am 06.08.2019 um 02:42 schrieb Munzer Khatib 
:


Hi
Can you help me with this problem.
Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
I am trying to install a new SSL certificate into Apache tomcat 
8.0.36.I ran same steps ran successfully in 2013 and 2016 on tomcat 
7. Nothing changed other than moving the virtual machine from old 
server to new hardware this year. Windows Server 2008 is still the 
same Operating system.
I created a keystore and extracted CSR, generated certificate using 
godaddy for Apache server and imported to server. I keep getting an 
SSL handshake errors and I think it is because the certificate 
entrytype is "trustedcertEntry" and not "privateKey Entry'
Here are the steps I used to create the keystore and import 
certificate to it.

1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
SHA256withRSA -keypass secret19 -keystore tomcat10.keystore


2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
SHA256withRSA -keystore tomcat10.keystore -file file10.csr


3) Generate certificates on godaddy site for "Apache" server (not 
tomcat)

4) Install root, intermediate and user certificate
keytool -import -alias root -keystore tomcat14.keystore -trustcacerts 
-file c:\cert_2022\gd-class2-root.crt


keytool -import -alias intermediate -keystore tomcat14.keystore 
-trustcacerts -file c:\cert_2022\gd_bundle-g2-g1.crt
keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
c:\cert_2019\508c844632c0145.crt


I‘ve not found a keytool command for that. I use openssl to convert 
the PEM to pkcs12/keystore format


Care to try the following command?
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat 
-certfile fullchain.pem -passout pass:changeit -out jssekeystore


Peter

I am not sure why but it seems the new one is not linking all 
certificates into the private key.
I tried many different imports and it would never import the server 
certificate as a "privateKeyentry" as the one running now.C:\Program 
Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter 
keystore password:

Keystore type: JKSKeystore provider: SUN
Your keystore contains 3 entries
root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, 
Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 
22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E


I also tried creating a PEM text file for all certificates and 
importing that into private key alias tomcat but it only imported the 
domain certificate as "trustedcertentry"
My server xml file connector config is like thisport="8080" protocol="HTTP/1.1" connectionTimeout="2" 
redirectPort="8443" compression="on" URIEncoding="UTF-8" 
compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" 
compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" 
secure="true" clientAuth="false" sslProtocol="TLS" 

Re: Component working in Console not as Service

[logo]

All,

sorry for top posting. Nothing down there to relate to.

Could it be that it is something similar like headless on linux? I 
remember something similar when using pdflib back in the days.
As a service there may be something missing (login shell, DISPLAY, 
Terminal)? "Word to PDF" could be well something that requires screen 
information. Worth a check on the requirements of the library.


My 2cts.

Peter


Am 2019-07-31 15:54, schrieb André Warnier:

On 31.07.2019 14:49, Mark Thomas wrote:

On 31/07/2019 13:03, Potgieter, Carlo wrote:



On 31/07/2019 12:48, Potgieter, Carlo wrote:
I was hoping to obtain some assistance. We have used a library to 
convert MS Office documents (docx and pptx) to PDF.


This works perfectly in the development environment and also when 
running Tomcat in a console window.


The moment we run Tomcat as a service this specific component gives 
and error. Unfortunately the error is non-specific so we cannot 
troubleshoot the origin.


My question is, what would be the difference in running Tomcat as a 
Service as oppose to running it in Console that might cause this 
problem?


Tomcat runs as a different user with different access permissions, 
particularly to network shares.


You probably want to set up a Tomcat specific user with the 
appropriate permissions.


Mark

Thank you Mark for the quick response.

My first thought was permissions also, however I have attempted to 
run it with local, domain and system user, however the same result.


Both local and domain user was part of the local admin group. Is 
there anything else I can check?


Are you sure the DDL is being loaded? That normally needs explicit
configuration to point the JVM at the right path.

Look at the docs for for
org.apache.catalina.startup.VersionLoggerListener and configure it to
dump everything. Then compare the console start with the service 
start.




What is also different when Tomcat runs as a Service or in a console,
is where the JVM that runs tomcat, picks up its environment and
command-line switches.
If you are not familiar with this matter, this may help :
verbose explanation :
https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11
Official page :
https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html

(Perhaps the application expects some value to be set somewhere..)

Also, above you mention "Unfortunately the error is non-specific..",
but maybe you want to copy the error message here, so that someone
else can have a look at it ?
Maybe it triggers some recognition by another user having had the same
issue with that library.


-
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 manager keystore reload

[logo]

Chris,

Now this is taking a weird direction…


> Am 30.07.2019 um 16:57 schrieb Christopher Schultz 
> mailto:ch...@christopherschultz.net>>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Peter,
> 
> On 7/30/19 05:19, logo wrote:
>> Hi Chris,
>> 
>> I am also trying to figure this out and get to the same error.
>> 
>>> Am 25.07.2019 um 17:53 schrieb Joseph Dornisch
>>> mailto:kingcanut...@gmail.com>>:
>>> 
>>> Hello,
>>> 
>>> I have a CRL configured in my tomcat server configuration. If I
>>> update it and want to have Tomcat refresh it, I can login into 
>>> https://127.0.0.1/manager/html <https://127.0.0.1/manager/html> and click 
>>> the "Re-read" button
>>> under "Configuration->Re-read TLS configuration files" and this
>>> causes my CRL to be reread. It works great.
>>> 
>>> However,I have read here, " 
>>> https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encr 
>>> <https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encr>





>> If I query with the jmxproxy-Servlet I get to 
>> Catalina:type=ProtocolHandler,port=8443, but I cannot figure out
>> the necessary address. How can I find it? Once I add an address
>> (127.0.0.1, localhost or DNSs...) , I get exactly "OK - Number of
>> results: 0". That may be the cause of the above
>> java.lang.NullPointerException.
>> 
>> If I omit the address it I get a detailed stacktrace, with all
>> sorts of IO exceptions/Illegal argument exceptions that relate to
>> the actual code of AbstractJsseEndpoint/AbstractEndpoint and
>> reloadSslHostConfigs.
>> 
>> Could you please help us here? If I only want to reload one
>> specific HostConfig, how do I set the hostname parameter?
>> 
>> I looked at your letsencrypt script 
>> https://people.apache.org/~schultz/ApacheCon%20NA%202018/lets-encrypt- 
>> <https://people.apache.org/~schultz/ApacheCon%20NA%202018/lets-encrypt->
> renew.sh,
>> 
>> 
> but that requires the address already as a parameter...
> 
> The best thing to do is connect with a JMX client such as VisualVM or
> perhaps one that your IDE provides. If you connect, you can see what
> JMX paths are actually available instead of just guessing at them.
> 
> Use the screenshots in the Let's Encrypt presentation (and possibly
> the related screenshots in the "Monitoring Apache Tomcat with JMX"
> presentation as well) to help you find the correct protocol handler path
> .
> 

I used jconsole to get to the ProtocolHandler. There is an error opening the 
panel
"Error setting Operation panel :org.apache.tomcat.util.net.SSLHostConfig“

And if I reload the SSLHostConfigs with the panel button I get the 
IllegalStateException - again.

Now before you ask, there is my config:


  
  

  
  

  
  

  
  

  
  

  


Any idea why?

Thanks

Peter

> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ 
> <https://www.enigmail.net/>
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1AWt4ACgkQHPApP6U8
> pFhqvxAAoRDPDxU1poECO+s/q/kcWXaoLKE0WrE4rmlasViRuuMdn7QtLJJZ7s0Q
> MaKk0LeJ+p/fT9fAuQ0Ysm75MhLy88Xj6SvR60mroPQZM1ONkgQ9EzLyYWiMPgt0
> alPu0z5Nqk5CW4fl4El4tLFysdniRr7WfYUdt/inwhuJSGWylVMyzqAEIVpmMsHk
> hpAoB+TWSPL8DLJMauLP64AF+gIO/RTfyM4dtC8yZJqXiSpntF8Eq5JtR2Q4y5UZ
> ijzA/rMmpQB0I1yTpExicaveMfIWYZg/2rfGh1hh3dP4dyQ4dYR2ZalmRoEW6rhZ
> zf+1nhmrByIuEoboozxgkDcLOfpXMCnG0yHtz8rAewcUci4UHabddcpLVlV+0Ilg
> yOADCYwnU8gmnD6vb1fI0B0O8OMr/VyCbhsWklOUyFBmZD64XYC4rkmGQAVhRR97
> qWrV1/Rs09Oq1zY0zpzJnRD5xmumsi/uuJ6T7kEhaK1KdT6wkDImParq2n5dnhm/
> 3smAZDpS3Nh246oyldpVuxOJpQxEWfHX+GZyAZfAJ0t/OgNV/Xq61Cz0Mr4z5iML
> fGKKpPxDB0DEWAm8RT11tyzAqk/Mwlx/KE+pxqIM+OCDY1rpkpMEYAIgFA8S1Hd5
> Y7cFNQC207nA6TuUOgnZeHzLVw2iqQIbSPqKTuwiT4j3fCbbCXQ=
> =K62u
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> <mailto:users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> <mailto:users-h...@tomcat.apache.org>

smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat manager keystore reload

[logo]

Hi Chris, 

I am also trying to figure this out and get to the same error. 

> Am 25.07.2019 um 17:53 schrieb Joseph Dornisch : 
> 
> Hello,
> 
> I have a CRL configured in my tomcat server configuration. If I update it
> and want to have Tomcat refresh it, I can login into
> https://127.0.0.1/manager/html and click the "Re-read" button under
> "Configuration->Re-read TLS configuration files" and this causes my CRL to
> be reread. It works great.
> 
> However,I have read here, "
> https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encrypt%20Apache%20Tomcat.pdf"
> on page 34 you can do basically the same thing with a command something
> like:
> https://localhost/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs
> 
> When I do this, I get back:
> 
> Error - java.lang.NullPointerException
> java.lang.NullPointerException
> at 
> org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(JMXProxyServlet.java:264)
> at 
> org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyServlet.java:207)
> at org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:116)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> com.arl.servlet.core.filters.AbstractRedirectFilter.doFilter(AbstractRedirectFilter.java:250)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> com.arl.servlet.core.filters.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:356)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> com.arl.servlet.core.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:128)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610)
> at 
> org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:348)
> at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:52)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
> at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:808)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
> at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> 
> Is this command supposed to work in Tomcat 8.5.43? Is there a different
> command. Short of this, the only way to force reload without manual
> intervention seems to be to login to the manager from code, and then execute
> https://127.0.0.1/manager/html/sslReload?org.apache.catalina.filters.CSRF_NONCE=
> 
> 
> 

Re: HTTP to HTTPS redirect not happening

[logo]

Richard,



> Am 20.07.2019 um 16:47 schrieb Richard Huntrods :
> 
> OK. That was really weird.
> 
> As I said in my message, following the directions on the web did NOT
> work. It didn't force redirection from http to https.
> 
> What it DID end up doing was to kill the tomcat servlet application.
> Before the change it was working fine, and after the change it would
> only generate a 404 page.
> 
> I reverted to the original /conf/web.xml, restarted tomcat and the
> servlet application is back up and running perfectly.
> 
> So this code in /conf/web.xml affected the servlet but not the ROOT
> static web pages.
> 
> I'm thinking I need to make the change I noted, but in ROOT/web.xml
> instead. I'll try that today. But it was weird that the change in
> /conf/web.xml killed the servlet but didn't affect the ROOT static pages
> at all. Especially weird  since the servlet application ONLY runs on
> port 443 (https).
> 

Be careful where you put that element. If I remember correctly the order of the 
elements for web.xml is quite picky (at least it was when I added it a couple 
of years ago).

In my app this goes right after welcome-file-list and before error-page.

The error log should you show the reason why the app does not start or start 
incomplete.

Peter

> -R
> 
> On 7/19/2019 7:18 PM, Richard Huntrods wrote:
>> I tried implementing automatic redirection from HTTP to HTTPS on my
>> tomcat today, but it's not working.
>> 
>> First, my system:
>> OS: Ubuntu 18.04.2 LTS (server)
>> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
>> Java: OpenJDK "11.0.3" 2019-04-16
>> Mysql: Ver 14.14 Distrib 5.7.26
>> 
>> This web application has it's own domain (let's call it "mydomain.com"
>> ) and has working HTTPS - and has done  for some time now.
>> 
>> Static web pages are served on this application via tomcat using the
>> ROOT directory ../tomcat/webapps/ROOT
>> 
>> Again, this is working just fine. If I type "https://mydomain.com; I
>> see the secure static pages. If I type "http://mydomain.com; I see the
>> same pages, but browsers inform me the page isn't secure.
>> 
>> I want to force tomcat to redirect "http://mydomain.com; to
>> "https://mydomain.com; always.
>> 
>> I found instructions for auto-redirection on several on-line sites,
>> and all had the same instructions.
>> 
>> I already have the redirect code in server.xml:
>> 
>> >  connectionTimeout="2"
>>  redirectPort="443" />
>> 
>> So all I had to add (according to the instructions) was code at the
>> end of ...tomcat/conf/web.xml
>> 
>>   
>>   
>>   Secured
>>   /*
>>   
>>   
>> CONFIDENTIAL
>>   
>>   
>> 
>> just before the final 
>> 
>> I did this and restarted tomcat. It doesn't work.
>> 
>> After restarting tomcat, if I type in "http://mydomain.com; I still
>> see the unsecured version. It does not auto-redirect to https.
>> 
>> What am I missing?
>> 
>> Thanks,
>> -Richard
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> --
> This communication is intended for the use of the recipient to whom it is 
> addressed, and may contain confidential, personal, and or privileged 
> information. Please contact us immediately if you are not the intended 
> recipient of this communication, and do not copy, distribute, or take action 
> relying on it. Any communications received in error, or subsequent reply, 
> should be deleted or destroyed.
> ---
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: HTTP to HTTPS redirect not happening

[logo]

Richard,

> Am 20.07.2019 um 04:19 schrieb Richard Huntrods :
> 
> I tried implementing automatic redirection from HTTP to HTTPS on my
> tomcat today, but it's not working.
> 
> First, my system:
> OS: Ubuntu 18.04.2 LTS (server)
> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
> Java: OpenJDK "11.0.3" 2019-04-16
> Mysql: Ver 14.14 Distrib 5.7.26
> 
> This web application has it's own domain (let's call it "mydomain.com" )
> and has working HTTPS - and has done  for some time now.
> 
> Static web pages are served on this application via tomcat using the
> ROOT directory ../tomcat/webapps/ROOT
> 
> Again, this is working just fine. If I type "https://mydomain.com; I see
> the secure static pages. If I type "http://mydomain.com; I see the same
> pages, but browsers inform me the page isn't secure.
> 
> I want to force tomcat to redirect "http://mydomain.com; to
> "https://mydomain.com; always.
> 
> I found instructions for auto-redirection on several on-line sites, and
> all had the same instructions.
> 
> I already have the redirect code in server.xml:
> 
>   connectionTimeout="2"
>redirectPort="443" />
> 
> So all I had to add (according to the instructions) was code at the end
> of ...tomcat/conf/web.xml
> 
> 
> 
> Secured
> /*
> 
> 
> CONFIDENTIAL
> 
> 
> 
> just before the final 

This should go into your webapp's WEB-INF/web.xml! Not the tomcat/conf!

Hope this helps,

Peter

> 
> I did this and restarted tomcat. It doesn't work.
> 
> After restarting tomcat, if I type in "http://mydomain.com; I still see
> the unsecured version. It does not auto-redirect to https.
> 
> What am I missing?
> 
> Thanks,
> -Richard
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> --
> This communication is intended for the use of the recipient to whom it is 
> addressed, and may contain confidential, personal, and or privileged 
> information. Please contact us immediately if you are not the intended 
> recipient of this communication, and do not copy, distribute, or take action 
> relying on it. Any communications received in error, or subsequent reply, 
> should be deleted or destroyed.
> ---
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: OCSP with openSSL

[logo]

Hi Mark,

Sorry for top posting - I want to wrap this thread up.

I was bitten again by the default SSL Implementation.

While I wanted to use JSSE on Port 8443, I just noticed today that without 
telling the connector to do so 
(sslImplementationName=„org.apache.tomcat.util.net.jsse.JSSEImplementation"), 
it used the OpenSSLImplementation - well that does not support OCSP as we all 
know.

The documentation is a bit vague on the defaults
To enable it, the native library should be enabled as if intending to use the 
APR connector, and Tomcat will automatically enable it and the default value of 
this attribute becomes org.apache.tomcat.util.net.openssl.OpenSSLImplementation

My basic test case uses the tomcat docker image with openjdk11. I did not 
specifically install tc native and enable APR.

Now when I look at below logfile I can see all that‘s wrong…
Sorry for the noise!


PS: now waiting for the openssl fix for tc native ;-)

Am 28.06.2019 um 14:14 schrieb logo mailto:l...@kreuser.name>>:

> Mark,
> 
> Still no luck with 8.5.42/JDK11/JSSE.
> 
>> Am 17.06.2019 um 22:11 schrieb logo > <mailto:l...@kreuser.name>>:
>> 
>> Mark,
>> 
>> 
>>> Am 17.06.2019 um 18:00 schrieb Mark Thomas >> <mailto:ma...@apache.org>>:
>>> 
>>> On 17/06/2019 15:51, logo wrote:
>>>> Mark,
>>>> 
>>>> 
>>>> Am 2019-06-17 16:29, schrieb Mark Thomas:
>>>>> On 17/06/2019 15:15, logo wrote:
>>>>>> Hi Mark,
>>>>>> 
>>>>>> having been in contact with Усманов, I can confirm your summary.
>>>>>> 
>>>>>> May I add my question from February with additional info to this thread:
>>>>>> https://markmail.org/message/zvziqrhm32bctm7e 
>>>>>> <https://markmail.org/message/zvziqrhm32bctm7e>
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Progress can be tracked here:
>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56148 
>>>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=56148>
>>>>> 
>>>>> At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
>>>>> OCSP stapling with appropriate configuration.
>>>>> 
>>>> 
>>>> Do you mean on trunk or really only configuration?
>>>> 
>>>> I just tried it on 8.5.42 and it will not send the message on my
>>>> letsencrypt cert.
>>>> 
>>>> If it should work out of the box, do you mind to share the "appropriate"
>>>> config here.
>>> 
>>> I was testing Tomcat 9.0.x (latest source from Git) but with the
>>> knowledge that we haven't made *any* changes to Tomcat to support OCSP
>>> stapling and that 9.0.x and 8.5.x have very similar TLS code.
>>> 
>>> I have just tested with 8.5.42. Both NIO+JSSE and NIO2+JSSE support OCSP
>>> stapling. My Connector configuration is:
>>> 
>>>>>   port="8443"
>>>   proxyPort="443"
>>>   maxThreads="150"
>>>   useAsyncIO="true"
>>>   SSLEnabled="true">
>>>>> className="org.apache.coyote.http2.Http2Protocol"
>>> useSendfile="false"
>>> maxConcurrentStreamExecution="50" />
>>>
>>>>> certificateFile="/.../cert.pem"
>>> certificateChainFile="/.../chain.pem"
>>> type="RSA" />
>>>
>>>
>>> 
>>> Mark
>>> 
>> I’m lost. My conf is pretty much similar.
>> 
> 
> 
>> Any debug info I can create?
>> 
>> Thanks Peter
> 
> 
> Started from scratch, plain tc 8.5.42 with JDK 11 (Docker Hub version)
> 
> Only added my certs to server.xml,
> 
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>maxThreads="150" SSLEnabled="true" >
> 
> 
>certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
>   certificateFile="${catalina.base}/conf/ssl/cert.pem"
>   certificateChainFile="${catalina.base}/conf/ssl/chain.pem"
>   type="RSA" />   
> 
> 
> 
> export JAV

Re: OCSP with openSSL

[logo]

Mark,

Still no luck with 8.5.42/JDK11/JSSE.

> Am 17.06.2019 um 22:11 schrieb logo :
> 
> Mark,
> 
> 
>> Am 17.06.2019 um 18:00 schrieb Mark Thomas > <mailto:ma...@apache.org>>:
>> 
>> On 17/06/2019 15:51, logo wrote:
>>> Mark,
>>> 
>>> 
>>> Am 2019-06-17 16:29, schrieb Mark Thomas:
>>>> On 17/06/2019 15:15, logo wrote:
>>>>> Hi Mark,
>>>>> 
>>>>> having been in contact with Усманов, I can confirm your summary.
>>>>> 
>>>>> May I add my question from February with additional info to this thread:
>>>>> https://markmail.org/message/zvziqrhm32bctm7e 
>>>>> <https://markmail.org/message/zvziqrhm32bctm7e>
>>>> 
>>>> Thanks.
>>>> 
>>>> Progress can be tracked here:
>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56148 
>>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=56148>
>>>> 
>>>> At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
>>>> OCSP stapling with appropriate configuration.
>>>> 
>>> 
>>> Do you mean on trunk or really only configuration?
>>> 
>>> I just tried it on 8.5.42 and it will not send the message on my
>>> letsencrypt cert.
>>> 
>>> If it should work out of the box, do you mind to share the "appropriate"
>>> config here.
>> 
>> I was testing Tomcat 9.0.x (latest source from Git) but with the
>> knowledge that we haven't made *any* changes to Tomcat to support OCSP
>> stapling and that 9.0.x and 8.5.x have very similar TLS code.
>> 
>> I have just tested with 8.5.42. Both NIO+JSSE and NIO2+JSSE support OCSP
>> stapling. My Connector configuration is:
>> 
>>>   port="8443"
>>   proxyPort="443"
>>   maxThreads="150"
>>   useAsyncIO="true"
>>   SSLEnabled="true">
>>> className="org.apache.coyote.http2.Http2Protocol"
>> useSendfile="false"
>> maxConcurrentStreamExecution="50" />
>>
>>> certificateFile="/.../cert.pem"
>> certificateChainFile="/.../chain.pem"
>> type="RSA" />
>>
>>
>> 
>> Mark
>> 
> I’m lost. My conf is pretty much similar.
> 


> Any debug info I can create?
> 
> Thanks Peter


Started from scratch, plain tc 8.5.42 with JDK 11 (Docker Hub version)

Only added my certs to server.xml,




   



export JAVA_OPTS="${JAVA_OPTS} 
-Djdk.tls.server.enableStatusRequestExtension=true“
alternatively
export CATALINA_OPTS="${CATALINA_OPTS} 
-Djdk.tls.server.enableStatusRequestExtension=true"
to bin/setenv.sh

That gets picked up:

28-Jun-2019 14:05:04.509 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.5.42
28-Jun-2019 14:05:04.524 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
Jun 4 2019 20:29:04 UTC
28-Jun-2019 14:05:04.525 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server number: 
8.5.42.0
28-Jun-2019 14:05:04.526 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
Linux
28-Jun-2019 14:05:04.527 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
4.14.116-boot2docker
28-Jun-2019 14:05:04.532 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
amd64
28-Jun-2019 14:05:04.533 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
/usr/local/openjdk-11
28-Jun-2019 14:05:04.533 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
11.0.3+7
28-Jun-2019 14:05:04.534 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Oracle Corporation
28-Jun-2019 14:05:04.534 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
/opt/apache-tomcat.base
28-Jun-2019 14:05:04.535 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
/usr/local/tomcat
28-Jun-2019 14:05:04.535 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
--add-opens=java.base/java.lang=ALL-UNNAMED
28-Jun-2019 14:05:04.536 INFO [main] 
org.apache.catalina.startup.VersionL

Re: OCSP with openSSL

[logo]

Mark,


> Am 17.06.2019 um 18:00 schrieb Mark Thomas :
> 
> On 17/06/2019 15:51, logo wrote:
>> Mark,
>> 
>> 
>> Am 2019-06-17 16:29, schrieb Mark Thomas:
>>> On 17/06/2019 15:15, logo wrote:
>>>> Hi Mark,
>>>> 
>>>> having been in contact with Усманов, I can confirm your summary.
>>>> 
>>>> May I add my question from February with additional info to this thread:
>>>> https://markmail.org/message/zvziqrhm32bctm7e
>>> 
>>> Thanks.
>>> 
>>> Progress can be tracked here:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
>>> 
>>> At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
>>> OCSP stapling with appropriate configuration.
>>> 
>> 
>> Do you mean on trunk or really only configuration?
>> 
>> I just tried it on 8.5.42 and it will not send the message on my
>> letsencrypt cert.
>> 
>> If it should work out of the box, do you mind to share the "appropriate"
>> config here.
> 
> I was testing Tomcat 9.0.x (latest source from Git) but with the
> knowledge that we haven't made *any* changes to Tomcat to support OCSP
> stapling and that 9.0.x and 8.5.x have very similar TLS code.
> 
> I have just tested with 8.5.42. Both NIO+JSSE and NIO2+JSSE support OCSP
> stapling. My Connector configuration is:
> 
>   port="8443"
>   proxyPort="443"
>   maxThreads="150"
>   useAsyncIO="true"
>   SSLEnabled="true">
> className="org.apache.coyote.http2.Http2Protocol"
> useSendfile="false"
> maxConcurrentStreamExecution="50" />
>
> certificateFile="/.../cert.pem"
> certificateChainFile="/.../chain.pem"
> type="RSA" />
>
>
> 
> Mark
> 
I’m lost. My conf is pretty much similar.




 


JAVA_OPTS are set (startup logs show 17-Jun-2019 16:46:48.497 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djdk.tls.server.enableStatusRequestExtension=true )


I use a JSSE keystore - that contains the correct cert. Openssl syntax did not 
change anything.

Running openssl to the letsencrypt ocsp responder from the machine gives a 
positive result. Tcpdump shows data.

$ openssl ocsp -verify_other intermediate.pem -issuer intermediate.pem -cert 
xxx.crt  -text -url http://ocsp.int-x3.letsencrypt.org -header 
"Host=ocsp.int-x3.letsencrypt.org"
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
  Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  Serial Number: 041237E97D620E10AFA0442E9C1D7B588046
Request Extensions:
OCSP Nonce: 
0410E8ED9179F620FD43BBCC4C81EC432CFB
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Jun 15 23:48:00 2019 GMT
…
Response verify OK


But once I connect to tomcat from outside, I don’t see any tcpdump traffic.

$ openssl s_client -connect xxx.dedyn.io:8443  -servername xxx.dedyn.io  
-tlsextdebug  -status
CONNECTED(0003)
TLS server extension "renegotiation info" (id=65281), len=1
 - 00.
TLS server extension "server name" (id=0), len=0
TLS server extension "EC point formats" (id=11), len=4
 - 03 00 01 02   
TLS server extension "session ticket" (id=35), len=0
*OCSP response: no response sent*
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = xxx.dedyn.io
verify return:1
---
Certificate chain
 0 s:/CN=xxx.dedyn.io
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-BEGIN CERTIFICATE——

Any debug info I can create?

Thanks Peter

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



smime.p7s
Description: S/MIME cryptographic signature

Re: OCSP with openSSL

[logo]

Mark,


Am 2019-06-17 16:29, schrieb Mark Thomas:

On 17/06/2019 15:15, logo wrote:

Hi Mark,

having been in contact with Усманов, I can confirm your summary.

May I add my question from February with additional info to this 
thread:

https://markmail.org/message/zvziqrhm32bctm7e


Thanks.

Progress can be tracked here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148

At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
OCSP stapling with appropriate configuration.



Do you mean on trunk or really only configuration?

I just tried it on 8.5.42 and it will not send the message on my 
letsencrypt cert.


If it should work out of the box, do you mind to share the "appropriate" 
config here.


Thanks
Peter


The OpenSSL ones (APR/native, NIO+OpenSSL, NIO2+OpenSSL) do not.

It might be simply a configuration issue with OpenSSL. It might need
code changes in APR/Native. I'm currently looking in to that.

Mark




Thanks.

Peter

Am 2019-06-17 15:44, schrieb Mark Thomas:

Coming back to this as it has been on my TODO list for a while.

Having re-read the thread I think it would be helpful to first 
clarify

exactly what behaviour you are expecting and not seeing.

The issue relates to OCSP checks when Tomcat is presenting it's 
server

certificate to the client.

You are expecting Tomcat to use OCSP stapling to provide the OCSP
information to the client so that the client does not have to request 
it

itself.

Tomcat is not providing the OCSP information. It appears that OCSP
stapling is not working.

Is the above a fair summary? If not, please provide corrections.

Thanks,

Mark


On 27/05/2019 12:36, Усманов Азат Анварович wrote:
Just a quick follow up , trying to get some answers, I added  
include

 to sslutils.c (which has alll the ocsp functions )   to
print some info.I  added printf calls to every function defined in
this file.  Interestingly enough  when I issue  the  openssl 
s_client

-connect debug.ieml.ru:8443  -tls1_2 -status -proxy 192.168.1.6:3131
both tls1_2 and tls 1_3  versions and when I access  the server from
another machine via browser none of printf  calls are displayed, 
however, when I issue ssllabs server test (which is also supposedly
capable of detecting ocsp)   some of them start to appear.  sadly
none of them are ocsp related. I did put basic  ifdef  test for
HAVE_OCSP_STAPLING, surprisingly  it  shows that ocsp support is
indeed enabled . So here are  both   the modified  sslutils.c file
and tomcat log snippet (not sure if attachments are allowed on  the
list  so posting it  here )
Not sure where to go from here
/* Licensed to the Apache Software Foundation (ASF) under one or 
more
 * contributor license agreements.  See the NOTICE file distributed 
with
 * this work for additional information regarding copyright 
ownership.

 * The ASF licenses this file to You under the Apache License,
Version 2.0
 * (the "License"); you may not use this file except in compliance 
with

 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, 
software

 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
 * See the License for the specific language governing permissions 
and

 * limitations under the License.
 */

/** SSL Utilities
 */

#include "tcn.h"
#include 
#ifdef HAVE_OPENSSL
#include "apr_poll.h"
#include "ssl_private.h"


#ifdef WIN32
extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
#endif

#ifdef HAVE_OCSP_STAPLING
#include 
#include 
/* defines with the values as seen by the asn1parse -dump openssl
command */
#define ASN1_SEQUENCE 0x30
#define ASN1_OID  0x06
#define ASN1_STRING   0x86
static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX
*ctx);
#endif

/*  
_

**
**  Additional High-Level Functions for OpenSSL
**  
_

*/

/* we initialize this index at startup time
 * and never write to it at request time,
 * so this static is thread safe.
 * also note that OpenSSL increments at static variable when
 * SSL_get_ex_new_index() is called, so we _must_ do this at 
startup.

 */
static int SSL_app_data2_idx = -1;
static int SSL_app_data3_idx = -1;
static int SSL_app_data4_idx = -1;

void SSL_init_app_data_idx(void)
{ printf(" SSL_init_app_data_idx\n");
   #ifdef HAVE_OCSP_STAPLING
printf("Hi OCSP \n");
#else
printf("Sorry no OCSP support\n");
#endif

    int i;

    if (SSL_app_data2_idx > -1) {
    return;
    }

    /* we _do_ need to call this twice */
    for (i = 0; i <= 1; i++) {
    SSL_app_data2_idx =
    SSL_get_ex_new_index(0,
 

Re: OCSP with openSSL

[logo]

Hi Mark,

having been in contact with Усманов, I can confirm your summary.

May I add my question from February with additional info to this thread:
https://markmail.org/message/zvziqrhm32bctm7e

Thanks.

Peter

Am 2019-06-17 15:44, schrieb Mark Thomas:

Coming back to this as it has been on my TODO list for a while.

Having re-read the thread I think it would be helpful to first clarify
exactly what behaviour you are expecting and not seeing.

The issue relates to OCSP checks when Tomcat is presenting it's server
certificate to the client.

You are expecting Tomcat to use OCSP stapling to provide the OCSP
information to the client so that the client does not have to request 
it

itself.

Tomcat is not providing the OCSP information. It appears that OCSP
stapling is not working.

Is the above a fair summary? If not, please provide corrections.

Thanks,

Mark


On 27/05/2019 12:36, Усманов Азат Анварович wrote:
Just a quick follow up , trying to get some answers, I added  include 
 to sslutils.c (which has alll the ocsp functions )   to 
print some info.I  added printf calls to every function defined in 
this file.  Interestingly enough  when I issue  the  openssl s_client 
-connect debug.ieml.ru:8443  -tls1_2 -status -proxy 192.168.1.6:3131
both tls1_2 and tls 1_3  versions and when I access  the server from 
another machine via browser none of printf  calls are displayed,  
however, when I issue ssllabs server test (which is also supposedly 
capable of detecting ocsp)   some of them start to appear.  sadly none 
of them are ocsp related. I did put basic  ifdef  test for 
HAVE_OCSP_STAPLING, surprisingly  it  shows that ocsp support is 
indeed enabled . So here are  both   the modified  sslutils.c file and 
tomcat log snippet (not sure if attachments are allowed on  the list  
so posting it  here )

Not sure where to go from here
/* Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed 
with

 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 
2.0
 * (the "License"); you may not use this file except in compliance 
with

 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

/** SSL Utilities
 */

#include "tcn.h"
#include 
#ifdef HAVE_OPENSSL
#include "apr_poll.h"
#include "ssl_private.h"


#ifdef WIN32
extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
#endif

#ifdef HAVE_OCSP_STAPLING
#include 
#include 
/* defines with the values as seen by the asn1parse -dump openssl 
command */

#define ASN1_SEQUENCE 0x30
#define ASN1_OID  0x06
#define ASN1_STRING   0x86
static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX 
*ctx);

#endif

/*  _
**
**  Additional High-Level Functions for OpenSSL
**  _
*/

/* we initialize this index at startup time
 * and never write to it at request time,
 * so this static is thread safe.
 * also note that OpenSSL increments at static variable when
 * SSL_get_ex_new_index() is called, so we _must_ do this at startup.
 */
static int SSL_app_data2_idx = -1;
static int SSL_app_data3_idx = -1;
static int SSL_app_data4_idx = -1;

void SSL_init_app_data_idx(void)
{ printf(" SSL_init_app_data_idx\n");
   #ifdef HAVE_OCSP_STAPLING
printf("Hi OCSP \n");
#else
printf("Sorry no OCSP support\n");
#endif

int i;

if (SSL_app_data2_idx > -1) {
return;
}

/* we _do_ need to call this twice */
for (i = 0; i <= 1; i++) {
SSL_app_data2_idx =
SSL_get_ex_new_index(0,
 "Second Application Data for SSL",
 NULL, NULL, NULL);
}

if (SSL_app_data3_idx > -1) {
return;
}

SSL_app_data3_idx =
SSL_get_ex_new_index(0,
 "Third Application Data for SSL",
  NULL, NULL, NULL);

if (SSL_app_data4_idx > -1) {
return;
}

SSL_app_data4_idx =
SSL_get_ex_new_index(0,
 "Fourth Application Data for SSL",
  NULL, NULL, NULL);

}

void *SSL_get_app_data2(SSL *ssl)
{
 printf("ssl_get_app_data2 \n");
return (void *)SSL_get_ex_data(ssl, SSL_app_data2_idx);
}

void SSL_set_app_data2(SSL *ssl, void *arg)
{
printf("ssl_set_app_data2 \n");

SSL_set_ex_data(ssl, 

Re: Setting headers in tomcat 9

[logo]

Hi Olayemi,

Am 26.03.2019 09:36, schrieb Olayemi Olatunji:

Hello,

I'm deploying an application on Tomcat 9 which a client has requested
we conduct vulnerability test on.

The test came back with missing headers for the following:
Content-Security-Policy, X-Frame-Options, X-XSS-Protection,
X-Content-Type-Options, Referrer-Policy, Feature-Policy.

How can this be resolved/patched?



Per se this can be done by enabling the  
org.apache.catalina.filters.HttpHeaderSecurityFilter in the global or 
your webapp‘s web.xml


This will solve quite a few of the vulnerability scanner findings.

For Content-Security-Policy (CSP) you should write your own Filter. The 
CSP finding is a pain for legacy applications. CSP is nothing that can 
be enabled without application knowhow, the right settings for your 
needs and intensive testing. You may really break inline Javascript in 
your pages (css too).


Please check out the great websites of Scott Helme on the Headers
https://Securityheaders.io or https://scotthelme.co.uk/csp-cheat-sheet/

Feature Policy is quite new and I would not deem that relevant for 
legacy applications (that don't use features like GPS, rotation, 
microphone).



Kind regards

Olayemi


Best regards

Peter

BTW: may I suggest you use the search function on the user list (eg: 
https://tomcat.apache.org/lists.html#tomcat-users -> MARC, MarkMail, 
Nabble). This question has been asked before quite a few times.



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

Re: Http insecure headers

[logo]

 

Hello Nitin, 

Am 27.02.2019 16:34, schrieb Nitin Kadam: 

> Hello Team, 
> 
> I have added below given filter and restarted tomcat service still it shows 
> Cache Control as private. 
> Please help me on same.

Pictures are stripped off the mailing list. so better send us text logs.


Nevertheless I told you before, the Cache-Control header may come from
your webapp. So you have to check the web.xml of the app for a possible
filter. Maybe it's also in the framework or the servlets itself. What is
happening if you request a resource from another context?
If it is set in the app, then possibly nothing in tomcat will be able to
remove it from the response (maybe a reverse proxy like apache or
nginx). 

Hope this helps. 

Peter 

> On Wed, Feb 27, 2019 at 2:54 PM logo  wrote: 
> 
>> Hi Nitin,
>> 
>> Am 27.02.2019 10:11, schrieb Nitin Kadam:
>>> Sorry for typo in earlier email, i was saying about ExpiresFilter only
>>> 
>>> so how do i add this filter and failter mapping , Do i need to add
>>> both in existing httpHeaderSecurity
>>> 
>>> 
>>> 
>>> ExpiresFilter
>>> 
>>> org.apache.catalina.filters.ExpiresFilter
>>> 
>>> ExpiresByType image
>>> access plus 10 days
>>> 
>>> 
>>> ExpiresByType text/css
>>> access plus 10 hours
>>> 
>>> 
>>> ExpiresByType application/javascript
>>> access plus 10 minutes
>>> 
>>> 
>>> 
>>> ExpiresDefault
>>> access plus 0 seconds
>>> 
>> 
>> this is an extra entry. I don't know if you should really put this in 
>> the global web.xml or rather in your applications web.xml. Maybe Mark 
>> can let us know more about possible consequences?
>> 
>> Add the ... AND the !!!
>> 
>> Peter
>> 
>>> 
>>> 
>>> On Wed, Feb 27, 2019 at 1:59 PM logo  wrote:
>>> 
>>>> Hello Nitin,
>>>> 
>>>> Am 27.02.2019 08:52, schrieb Nitin Kadam:
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> How can i change "Cache Control -private: to "Cache-Control: nostore"
>>>>>
>>>>> i searched and found that need to add express filters in web config but
>>>>> not
>>>>> sure on where to add in filters.
>>>>>
>>>>> can you please guide me on same?
>>>>>
>>>> 
>>>> as far as I can tell, that Header is already set by your application -
>>>> Tomcat will not set it by default. Not to "private" for sure.
>>>> So it may be necessary to change that in your config, maybe even code.
>>>> 
>>>> Usually you would have to implement a CacheControl filter like the one
>>>> mentioned here at stackoverflow
>>>> https://stackoverflow.com/questions/2876250/tomcat-cache-control [1]
>>>> 
>>>> I don't know if the new ExpiresFilter will let you set the
>>>> Cache-Control-Header to that necessary value (other than max-age=0).
>>>> 
>>>> From my experience and the long history of many different browsers 
>>>> using
>>>> different headers, the one header will maybe solve a vulnscan issue 
>>>> but
>>>> not the compatibility with "all" browsers.
>>>> 
>>>> Peter
>>>> 
>>>> 
>>>>>
>>>>> On Wed, Feb 20, 2019 at 3:28 AM Peter@Kreuser-Online
>>>>> 
>>>>> wrote:
>>>>>
>>>>>> Hi Nitin,
>>>>>>
>>>>>> Per se this can be done by enabling the
>>>>>> org.apache.catalina.filters.HttpHeaderSecurityFilter
>>>>>> in the global or your webapp's web.xml
>>>>>>
>>>>>> For CSP you should write your own Filter.
>>>>>>
>>>>>> Beware though that Content Security Policy is nothing that can be
>>>>>> enabled
>>>>>> without application knowhow, the right settings for your needs and
>>>>>> intensive testing. You may really break inline Javascript in your
>>>>>> pages
>>>>>> (css too).
>>>>>>
>>>>>> Please check out the great websites of Scott Helme on the Headers
>>>>>> https://Securityheaders.io [2] or
>>>>>> https://scotthelme.co.uk/csp-cheat-sheet/ [3]
>>>>>>
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> > Am 19.02.2019 um 19:13 schrieb Nitin Kadam >>>>:
>>>>>> >
>>>>>> > Hello Team
>>>>>> >
>>>>>> > Need help to enable below security headers in Apache tomcat 7.0.79
>>>>>> > Operating system is windows 2012 R2
>>>>>> >
>>>>>> > 1. Content security headers
>>>>>> > 2. HSTS header
>>>>>> >
>>>>>> > Regards
>>>>>> > Nitin
>>>>>>
>>>> 
>>>> -
>>>> 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
> 
> -- 
> 
> Regards
> Nitin Kadam
> (9967688959)

 

Links:
--
[1] https://stackoverflow.com/questions/2876250/tomcat-cache-control
[2] https://Securityheaders.io
[3] https://scotthelme.co.uk/csp-cheat-sheet/

Re: Http insecure headers

[logo]

Hi Nitin,

Am 27.02.2019 10:11, schrieb Nitin Kadam:

Sorry for typo in earlier email, i was saying about ExpiresFilter only

so how do i add this filter and failter mapping , Do i need to add
both in existing httpHeaderSecurity



ExpiresFilter

org.apache.catalina.filters.ExpiresFilter


ExpiresByType image
access plus 10 days


ExpiresByType text/css
access plus 10 hours


ExpiresByType application/javascript
access plus 10 minutes



ExpiresDefault
access plus 0 seconds



this is an extra entry. I don't know if you should really put this in 
the global web.xml or rather in your applications web.xml. Maybe Mark 
can let us know more about possible consequences?


Add the ... AND the !!!

Peter





On Wed, Feb 27, 2019 at 1:59 PM logo  wrote:


Hello Nitin,

Am 27.02.2019 08:52, schrieb Nitin Kadam:
> Hello,
>
>
>
> How can i change “Cache Control -private: to “Cache-Control: nostore”
>
> i searched and found that need to add express filters in web config but
> not
> sure on where to add in filters.
>
> can you please guide me on same?
>

as far as I can tell, that Header is already set by your application -
Tomcat will not set it by default. Not to "private" for sure.
So it may be necessary to change that in your config, maybe even code.

Usually you would have to implement a CacheControl filter like the one
mentioned here at stackoverflow
https://stackoverflow.com/questions/2876250/tomcat-cache-control

I don't know if the new ExpiresFilter will let you set the
Cache-Control-Header to that necessary value (other than max-age=0).

 From my experience and the long history of many different browsers 
using
different headers, the one header will maybe solve a vulnscan issue 
but

not the compatibility with "all" browsers.

Peter


>
> On Wed, Feb 20, 2019 at 3:28 AM Peter@Kreuser-Online
> 
> wrote:
>
>> Hi Nitin,
>>
>> Per se this can be done by enabling the
>> org.apache.catalina.filters.HttpHeaderSecurityFilter
>> in the global or your webapp‘s web.xml
>>
>> For CSP you should write your own Filter.
>>
>> Beware though that Content Security Policy is nothing that can be
>> enabled
>> without application knowhow, the right settings for your needs and
>> intensive testing. You may really break inline Javascript in your
>> pages
>> (css too).
>>
>> Please check out the great websites of Scott Helme on the Headers
>> https://Securityheaders.io or
>> https://scotthelme.co.uk/csp-cheat-sheet/
>>
>>
>> Peter
>>
>> > Am 19.02.2019 um 19:13 schrieb Nitin Kadam :
>> >
>> > Hello Team
>> >
>> > Need help to enable below security headers in Apache tomcat 7.0.79
>> > Operating system is windows 2012 R2
>> >
>> > 1. Content  security headers
>> > 2. HSTS header
>> >
>> > Regards
>> > Nitin
>>

-
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: Http insecure headers

[logo]

Hello Nitin,

Am 27.02.2019 08:52, schrieb Nitin Kadam:

Hello,



How can i change “Cache Control -private: to “Cache-Control: nostore”

i searched and found that need to add express filters in web config but 
not

sure on where to add in filters.

can you please guide me on same?



as far as I can tell, that Header is already set by your application - 
Tomcat will not set it by default. Not to "private" for sure.

So it may be necessary to change that in your config, maybe even code.

Usually you would have to implement a CacheControl filter like the one 
mentioned here at stackoverflow 
https://stackoverflow.com/questions/2876250/tomcat-cache-control


I don't know if the new ExpiresFilter will let you set the 
Cache-Control-Header to that necessary value (other than max-age=0).


From my experience and the long history of many different browsers using 
different headers, the one header will maybe solve a vulnscan issue but 
not the compatibility with "all" browsers.


Peter




On Wed, Feb 20, 2019 at 3:28 AM Peter@Kreuser-Online 


wrote:


Hi Nitin,

Per se this can be done by enabling the
org.apache.catalina.filters.HttpHeaderSecurityFilter
in the global or your webapp‘s web.xml

For CSP you should write your own Filter.

Beware though that Content Security Policy is nothing that can be 
enabled

without application knowhow, the right settings for your needs and
intensive testing. You may really break inline Javascript in your 
pages

(css too).

Please check out the great websites of Scott Helme on the Headers
https://Securityheaders.io or 
https://scotthelme.co.uk/csp-cheat-sheet/



Peter

> Am 19.02.2019 um 19:13 schrieb Nitin Kadam :
>
> Hello Team
>
> Need help to enable below security headers in Apache tomcat 7.0.79
> Operating system is windows 2012 R2
>
> 1. Content  security headers
> 2. HSTS header
>
> Regards
> Nitin



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

Re: Tomcat 9_Setting property 'digest' to 'SHA-256'

[logo]

Hi,


Am 15.02.2019 10:08, schrieb dheeraj joshi:


Hi Team,



I am getting warning “Setting property 'digest' to 'SHA-256' did not 
find
a matching property” in tomcat9-stderr.log  when I use attribute 
"digest"

in realms.

Snip from server.xml that i am using when i get error -



digest="SHA-256"

/>



If I remove digest="SHA-256" from line className="org.apache.catalina.realm.MemoryRealm" digest="SHA-256" /> 
and

restart tomcat service , I don’t see this warning after it.



That would be expected as it is removed and there is no setter.




I did search for similar error reported by other users on internet but
couldn’t confirm whether I am doing correct configuration. Some people 
say
that digest attribute is removed since Tomcat 8.5 while some suggested 
me

to use CredentialHandler sub element rather than using digest.




well that IS the suggested fix.
https://tomcat.apache.org/tomcat-8.0-doc/config/realm.html#Memory_Based_Realm_-_org.apache.catalina.realm.MemoryRealm
"This attribute is deprecated. Set the algorithm on a nested 
CredentialHandler element instead."


You could probably always try the migration guide when you do a major 
version upgrade https://tomcat.apache.org/migration.html

Unfortunately each version separate.

Hope this helps.

Peter




https://stackoverflow.com/questions/41325893/tomcat-form-based-authentication-datasourcerealm-configuration-errors
,
https://mail-archives.apache.org/mod_mbox/tomcat-dev/201511.mbox/raw/%3c564a60fb.70...@gmail.com%3e



I couldn’t find  public documentation from Apache foundation 
confirming
that digest should not be used with Tomcat 9 . When I check docu 
provided

with Tomcat 9 I don’t see attribute named digest listed under Memory
Based Realm section




https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html#Memory_Based_Realm_-_org.apache.catalina.realm.MemoryRealm








Can you confirm whether digest attribute can be still used in Tomcat 9 
in
realms, if yes then what should be the correct syntax to use it. If 
the use

of digest is deprecated what should I be using instead?



I have been using digest attribute in previous versions of Tomcat in
realms and it used to work fine , problem is after Tomcat upgrade from
Tomcat 6 to Tomcat 9.

Regards
Dheeraj Joshi





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

OCSP Stapling with Tomcat 8.5

[logo]

Hi all,

I’m wondering why I get 

OCSP Must StapleSupported, OCSP response not stapled
Revocation information  OCSP 
OCSP: http://ocsp.int-x3.letsencrypt.org 

with the SSLlabs check on both the JSSE and the APR connector. The same cert is 
working on Apache or Nginx.

My version info is: 
Server version: Apache Tomcat/8.5.38
Server built:   Feb 5 2019 11:42:42 UTC
Server number:  8.5.38.0
OS Name:Linux
OS Version: 4.9.93-boot2docker
Architecture:   amd64
JVM Version:11.0.2+9-Debian-3
JVM Vendor: Oracle Corporation

My understanding is that tomcat should use OCSP stapling out of the box since 
Java9 with -Djdk.tls.server.enableStatusRequestExtension=true set or APR with 
an OCSP enabled (Let’sEncrypt) certificate.

The documentation on 
https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Configuring_OCSP_Connector
 is not quite clear. I don’t have any client certs to validate. So neither 
option for the certificateVerification attribute makes sense to me.

openssl s_client -connect :443  -servername  -tlsextdebug  
-status  gives me "OCSP response: no response sent“. I have checked that the 
docker container can reach let’s encrypt’s responder.
(BTW 443 is natted to 8443/8843 internally)

Could you please lead me into the right direction? What am I missing?

Thank you.

Peter

Re: Number of Web Applications in one Tomcat

[logo]

Tarek,

Am 30.10.2018 14:39, schrieb Ahmed, Tarek:

Am 30.10.18 um 13:13 schrieb logo:

Mark,




DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It
takes
4 minutes to start)


You can configure Tomcat to load applications in parallel to reduce 
this

impact.




do you mind to tell me how? Or what option to search for?


Since I've already searched (and found it): Look at this page:
https://wiki.apache.org/tomcat/HowTo/FasterStartUp#Starting_several_web_applications_in_parallel

"With Tomcat 7.0.23+ you can configure it to start several web
applications in parallel. This is disabled by default but can be 
enabled
by setting the startStopThreads attribute of a *Host* to a value 
greater

than one."

cheers,

tarek


that's nice, Thanks

Peter

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

Re: Number of Web Applications in one Tomcat

[logo]

Mark,




DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It 
takes

4 minutes to start)


You can configure Tomcat to load applications in parallel to reduce 
this

impact.




do you mind to tell me how? Or what option to search for?

Thank you.

Peter

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

[OT] Re: Tomcat Valve

[logo]

Nice one Christopher. Didn't know that yet. Will bookmark.

Am 28.08.2018 05:13, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lance,

On 8/27/18 19:21, Christopher Schultz wrote:

Lance,

On 8/24/18 11:52, Campbell, Lance wrote:

Tomcat 9 Use Case 1:  I want to store the last N number of URLs
sent to Tomcat 9 application.  Then if Tomcat shuts down I want
to write out these last N number of URLs to the log file.



Strategy: I figured I would use a valve to keep track of the last
N number of URLs.  However I don’t know how to tell when the
valve is shutting down.



Does anyone have any suggestions?


Sounds like an X-Y problem: http://xyproblem.info/

Maybe you can tell us what Y is in this case?


Uhh... actually I meant "what is X, here?" ;)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluEveUACgkQHPApP6U8
pFh5Og//djlqDz0WsiVlHg+Z6w6cGUiXAOd8FiQOMPPvgps9fl0rLU5bMteyRO4D
YKrU8zECfbvZxDnt1aVtxcqrKVaVvu/YyObIUG/6xQAN7pqEz3iJJ/7tWLhaGvHn
/fw+8oFHiO2rrodr9M8OFpeYklhqLkP1N0yxZVn9pfUQKcN0hWgOEwdHL2TWicZm
kx2MRs2hr2SRTs0dxmIYNVpy6ajRL8CDYY02rItCWGZZ3BLLNaePvRfkBn+BMfdm
W8XF1vArV8JvMkydvNk6Nq1U0uxRCf8eeDuT7DtJ8ls6j8FFIA34OuLmiXao+5Bl
E6YfKcpjJgxxlJqbuz3UTPiSSJ7HK/XkR1lZhz/GSJP5BhoCGFv8wiEwscH2b6pF
sbsT8gn1OqfVgHZPYMViqxXHxpLitbV1ZrtbmtY0QGyyGW8lUOWWTO/Jor1CTgKo
Jh+G1FOT4L5q0bE1WmloRxjwj+lg7beMwGjLKp9+Lu+yZRjvz+bJUJNacHr5ysG2
EQiCTKGHdaImtSs0vg0N8t13RmjgMhZljMxeX46bk4nZ+MsAX1SxnBN8kZdXVHKy
aVXIez73a3FhjLy0+fVZlObsHWPvHtvSpX3VN3Slnc0g5Lm6X2feeZLpnv6irs3y
Wos/zAFA5opTa4pBoqz6+q9A5Btx3EHJQAK9XqagqZbYWjJ/TLU=
=CJN/
-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: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

[logo]

Mark,



Am 06.07.2018 11:27, schrieb Sandels Mark (RTH) OUH:

Hi Tomcat users

I have now configured the tomcat configuration file (server.xml) to
use TLS (see relevant sections of server.xml). I created a keystore
(using the jdk keystore command) for my existing certificate.

I am getting "This site cannot be reached" from my browser (Chrome)
when I enter the URL https://oxnetmdms04:8443/OracleStatus

Can anyone tell what I am doing wrong? (wrt:
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html)



What do the logfiles say? Really important to check this, as they will 
lead you the way - before you ask here and we ask what they say ;-) .





Keystore command used:

"%JAVA_HOME%\bin\keytool" -import -alias mdms04 -file certificate.crt
-keystore publicKey.store

Relevant sections from Server.xml:

 protocol="org.apache.coyote.http11.Http11NioProtocol"

   maxThreads="150" SSLEnabled="true"

certificateKeystoreFile="conf/localhost-rsa.jks"

 type="RSA" />




   




To me it looks like you have a config error. If that is the relevant 
part of your config, you have a double 8443 connector.


And mdms04 is not the password it's the keyAlias!

Did you use the standard password of changeit? (keystorePass="changeit") 
Plus if you don't set an alias name in the connector, Tomcat uses the 
default "tomcat"


Now for the new and better config in Tomcat 8.5/9:



ciphers="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305: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-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">
 certificateKeystoreFile="${catalina.home}/conf/keystore/publicKey.store"
  certificateKeystorePassword="keystore>"

  certificateKeyAlias="mdms04"
  type="RSA" />


And from the naming: you should have the *private* key of the server in 
the publicKey.store !


Hope this helps.

Peter

PS and BTW: You don't have to use keytool as I told you before.





Mark Sandels



-
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: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

[logo]

Mark,


Am 05.07.2018 12:35, schrieb Sandels Mark (RTH) OUH:

Hi Peter

I would use tomcat to provide https if it could be configured to do
this - is this fairly easy to do?

The IT Department have given me a Certificate and private key for the
server (OXNETMDMS04) but do I need to use "keytool" to create a key
store for the Certificate? (I am referring to the link
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html).


Tomcat from 8.5 on will let you use PEM-Files to configure TLS. You may 
find more Information on the correct attributes on:

https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support

That's the way I use it:

   
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"

allowTrace="false"
maxThreads="150"
SSLEnabled="true"
compression="off"
scheme="https"
server="Apache Tomcat"
secure="true"
defaultSSLHostConfigName="" >

ciphers="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305: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-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">
  certificateKeyFile="${catalina.base}/conf/ssl/cert.key"

   certificateFile="${catalina.base}/conf/ssl/cert.crt"
   
certificateChainFile="${catalina.base}/conf/ssl/ca-chain.cert.pem"

   type="RSA" />

  


Christopher Schultz has maybe more details on how to use this correctly 
and on the prerequisites.


Best regards

Peter






Kind regards
Mark

Mark Sandels |Senior Systems Analyst/Programmer|IM & T Services –
Integration Services Team |Manor House Annexe Room G22, Oxford
University Hospitals NHS Trust , Headley Way, Headington, Oxford OX3
9RR |Phone:  01865 (5) 72103 | Email: mark.sand...@ouh.nhs.uk NHS
colleagues can visit the OUH IM Services intranet site at
http://ouhimt.oxnet.nhs.uk





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

Re: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

[logo]

Mark,

Am 05.07.2018 10:31, schrieb André Warnier:

Hi.

I have not looked through all of your configuration lines, but I
believe that the problem is first of all this line :

On 05.07.2018 09:18, Sandels Mark (RTH) OUH wrote:

DocumentRoot "C:\Program Files (x86)\apache-tomcat-9.0.6\webapps"




+1

That's most certainly the reason. You can browse down to WEB-INF and see 
web.xml or any file with credentials... Even worse if you enable 
indexes!


Make yourself familiar how to configure Apache httpd and be aware that 
any config in the main httpd-file is for the whole server! Put all 
config into your own virtualhost not the default. You can severly mess 
up the security of your tomcat webapp if you don't understand httpd. 
httpd hardening adds just one more complexity.


Do you really need httpd fronting tomcat? Tomcat provides pretty much 
everything you need...


Best regards

Peter




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

Re: Updating a working installation

[logo]

Hi,

Am 11.05.2018 15:47, schrieb Mark H. Wood:

"Is there an easy way?"  Depends on what you find easy. :-/

I usually just load old and new server.xml into a maximized Emacs with
two windows, and thoughtfully copy stuff over, after reading the
release notes to learn of stuff to look out for.  Other configuration
I usually don't touch, and webapp.s should just copy over without much
trouble.

As for the keystore:  I've recently moved that out of my Tomcat
configurations into the place where I keep other certificates and
keys, and I configure Tomcat to look for it there.  So I just copy
those settings over and the keystore stays where it was.

I also tend to install the webapp.s elsewhere and just drop in
external Context files to point to them, so copying these is a snap.


Nobody mentioned the usage of CATALINA_BASE vs. CATALINA_HOME

Besides diffing the conf-dirs I just update CATALINA_HOME with the new 
version, restart and then it's done.


Best regards

Peter

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

Re: configuring ciphers for SSL Labs server test

[logo]

Hi Baron,


Am 12.05.2018 05:36, schrieb Baron Fujimoto:

Hmm, I'm now getting an A grade using:



If I'm sufficiently motivated next week, I'll see if I can sort out 
exactly what

the deal was. But for now, it's Friday and pau hana time...

(yes, tomcat 8.5.x and Java 1.8_x)

On Fri, May 11, 2018 at 07:39:25AM +0100, Mark Thomas wrote:

On 11/05/18 03:35, Baron Fujimoto wrote:
Yes, the host is behind an F5 load balacer, but AFAIK it should be 
passing

all the TLS/SSL directly to the real host to handle.


You don't say which Tomcat version is being used. I assume one of the
8.5.x versions since the 8.5.x docs are referenced.

8.5.x should get an A from SSLLabs with the default configuration:
https://wiki.apache.org/tomcat/Security/Ciphers

I recently updated that page but 8.5.x was getting a A two years ago 
as

well.

Are you sure Java 8 is being used?

Mark




On Thu, May 10, 2018 at 11:23:44PM +, Scott Hoenigman wrote:

Are you using a load balancer?



Sent from my T-Mobile 4G LTE Device


 Original message 
From: David Wall 
Date: 5/10/18 6:15 PM (GMT-06:00)
To: users@tomcat.apache.org
Subject: Re: configuring ciphers for SSL Labs server test

We're doing good with this:




On 5/10/18 2:45 PM, Baron Fujimoto wrote:
I'm trying to improve our grade on SSL Labs SSL server test[1] for 
our
Tomcat configuraton. Currently, their report caps our grade at B 
because,
"This server does not support Authenticated encryption (AEAD) 
cipher

suites". They report that we support the following cipher suites:

# TLS 1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

# TLS 1.1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

I'm not sure why SSL Labs is seeing such a limited set of ciphers. 
We are

using Java 1.8.0_162, and I believe we have the Java Cryptography
Extension (JCE) properly installed. I have the following connector
defined (this version explicitly lists ciphers I think should 
satisfy the

AEAD cipher requirement[2]):

 protocol="org.apache.coyote.http11.Http11NioProtocol"

address="0.0.0.0"
port="8443"
maxThreads="500"
maxPostSize="10"
scheme="https" secure="true"
defaultSSLHostConfigName="foo.example.edu"
SSLEnabled="true" >
 
ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK

:!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
:!TLS_DHE_RSA_WITH_AES_128_CBC_SHA
:!TLS_DHE_RSA_WITH_AES_256_CBC_SHA

:!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

:!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

:!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

:!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

:!TLS_RSA_WITH_AES_128_CBC_SHA
:!TLS_RSA_WITH_AES_256_CBC_SHA
:!TLS_RSA_WITH_AES_128_CBC_SHA256
:!TLS_RSA_WITH_AES_256_CBC_SHA256
:!TLS_RSA_WITH_AES_128_GCM_SHA256
:!TLS_RSA_WITH_AES_256_GCM_SHA384

:!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

:!TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

:TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384

:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

:TLS_DHE_RSA_WITH_AES_128_CBC_SHA
:TLS_DHE_RSA_WITH_AES_256_CBC_SHA

:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256" >

   
certificateKeystoreFile="/home/cas/keystore/foo.pkcs12.keystore" >

 
 

Re: Connection closed error and certificateVerification="required"

[logo]

Mark,


> Am 19.04.2018 um 20:58 schrieb Mark Thomas :
> 
> On 19/04/18 16:50, Peter@Kreuser-Online wrote:
> 
> 
> 
>> Do you mind to share more about the root cause? I’ve followed this mail 
>> communication from the start and am  curious. 
> 
> Sure.
> 
> Tomcat was configured to require CLIENT-CERT auth and the main client
> was configured to use this. Occasionally, the main client would see
> connection problems when using 8.5.x or later with NIO and the OpenSSL
> TLS implementation.
> 
> There was a second client the performed health checks on the server.
> This client did not use a certificate. The requests it made always
> failed but did so with a predictable error message that the health check
> looked for.
> 
> OpenSSL error states are stored per thread.
> 
> Each Java thread is mapped 1-to-1 to an OS thread.
> 
> The sequence of events that cause the problem was as follows:
> 
> - Health check ran
> - TLS connection failed because no client certificate was provided
> - OpenSSL set an error state that - depending on the timing of the
> socket closure - was not always cleaned up
> - Standard request was received and was handled by the thread that
> previously experienced the error
> - Because the error had not been cleaned up, this new connection thought
> the error was meant for it and closed the connection
> 
> The fix was to ensure that, whenever the Tomcat code made a call to
> OpenSSL that looked like this:
> - Do something via the OpenSSL API
> - Check the OpenSSL error state
> 
> the code was changed so it looked like this:
> - Clear the OpenSSL error state
> - Do something via the OpenSSL API
> - Check the OpenSSL error state
> 
> I also added a TODO for the arguably more complete fix which is to check
> the OpenSSL error state after every call to the OpenSSL API.
> 
>> Let me tell you that your endurance on all the tricky issues here is 
>> admirable! 
>> 
>> Thank you for that!
> 
> Thank you.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Much appreciated. That was a mean one.

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

Re: No reliable way to know if the request emerged from localhost

[logo]

Hi Vasanth,

Am 27.02.2018 09:29, schrieb Vasantharaju Trichy:

Tomcat version 7.0.82 | Windows



We have a requirement such that admins(tomcat users) need to login 
remotely
to the machine where Tomcat is hosted and access tomcat webapp to 
perform

certain action or see certain pages . These pages or actions are not
permitted if users login remotely



Initially thought  *request.getRemoteAddr* can be used determine actual
client ip is local or not but looks like based *X-Forwarded-For* header 
it
is easy to spoof *request.getRemoteAddr* . The spoofing is possible 
even

from trusted internal proxies



So thought *request.getServerName* is reliable than 
*request.getRemoteAddr*




But *HOST* header can be spoofed to reflect *request.getServerName*



Strangely Tomcat honors HOST header to update request. getServerName .



I strongly feel this is a tomcat issue  or let us know how can we 
reliably
determine if the request is originated from local or this is something 
not

possible





Thanks in advance,

Vasanth


Do you need to protect only single pages or the whole app? Did you check 
"Remote Address Filter" 
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Address_Filter?


But: nevertheless request.getRemoteAddr(); can not be spoofed! That is 
the origin of the request - that will be your data you need to check for 
localhost. If you'd need to identify non-admin-requests from remote and 
get the "real" ip, this may be more difficult and may need to handle 
X-Forward-headers.
Looking at the code of the Valve you would find the necessary handling 
for X-Forward-Header.


request.getServerName does not identify the client! That is the target 
host name and is irrelevant for your app.


Best regards

Peter

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

Re: problems with tomcat 8.5.5

[logo]

Lou,

Am 2018-02-23 09:25, schrieb Lou DeGenaro:

I've replaced tomcat 8.5.5 with 8.5.28.  Now I see these exceptions in
catalina.out:

22-Feb-2018 21:45:42.988 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR 
based
Apache Tomcat Native library which allows optimal performance in 
production

environments was not found on the java.library.path:
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
22-Feb-2018 21:45:43.315 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-8080"]
22-Feb-2018 21:45:43.354 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal Failed to 
initialize

connector [Connector[HTTP/1.1-8080]]
 org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8080]]
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:113)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:632)
at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)

Caused by: org.apache.catalina.LifecycleException: Protocol handler
initialization failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:996)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.net.BindException: Address already in use


Tomcat is already running on Port 8080


at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at 
sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:210)

at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1086)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:268)
at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
... 13 more
22-Feb-2018 21:45:43.357 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["ajp-nio-8009"]
22-Feb-2018 21:45:43.359 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal Failed to 
initialize

connector [Connector[AJP/1.3-8009]]
 org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[AJP/1.3-8009]]
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:113)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:632)
at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)

Caused by: org.apache.catalina.LifecycleException: Protocol handler
initialization failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:996)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at

Re: Apache Tomcat 8.5.24 SSL Configuration

[logo]

Hi Thomas,

> Am 21.12.2017 um 00:56 schrieb Thomas Delaney :
> 
> Greetings,
> 
> I am having trouble regarding google chrome's behavior to Apache Tomcat's
> SSL setup. I have been successful getting an ssl website to work with
> Apache HTTP web server, but not Apache Tomcat 8.5.24 on google chrome.
> Mozilla Firefox brings me to my site with no problem.
> 
> When going to https://mydomain.com:8443 I recieve a message from Google
> Chrome.
> 
> Google Chrome Error -
> This site can’t provide a secure connection
> mydomain.com uses an unsupported protocol.
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> 
> Unsupported protocol
> The client and server don't support a common SSL protocol version or cipher
> suite.
> 
> When checking Google Chrome's Browser console in the security tab I
> recieve:
> Page is not secure
> Valid certificate
> secure resources
> 
> Here is the following background info I have for the configuration I gave
> Apache Tomcat when setting up the 8443 connector
> 
> Chrome Version 63.0.3239.108 (Official Build) (64-bit)
> 
> Linux OS: SUSE Enterprise 12 sp1
> 
> Packages installed:
> 
> - OpenSSL 1.0.2n  7 Dec 2017
> - jdk version 1.7.0_79

That may be the culprit.

Apparently this (old) version of Java7 will not provide in the default modern 
ciphers that Chrome requires. And the config is using the JSSE SSL 
implementation.
But as you have TC Native and openssl 1.0.2 you should switch to openssl. 


> - tomcat version -> apache-tomcat-8.5.24
> - apr-1.6.3
> - tomcat-native-1.2.16-src
> 
> Server.xml apr connector (Certificates are signed from GoDaddy and are
> placed in the conf directory of Apache Tomcat):
> 
>maxThreads="150" SSLEnabled="true" defaultSSLHostConfigName="
> mydomain.com" >
> protocols="TLSv1,TLSv1.1,TLSv1.2">
> certificateFile="conf/server.crt"
> certificateChainFile="conf/CA_server_bundle.crt"
> type="RSA" />
>
>
> 
> 
My config for openssl is like this:


  


  

  

It contains openssl 1.1 ciphers but that will not matter for your config.

You may search this’ mailing list archive for some good posts on available 
ciphers.

Hope this helps.

Peter

> hostname displays properly when typing command: hostname -f and/or typing:
> cat /etc/HOSTNAME on the linux server

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

[logo]

James,


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

Apparently Tomcat 7 syntax will not support openssl syntax like 
HIGH:+AES256:!MD5:... That will perfectly work with Tomcat 8.5 with the new ssl 
syntax, and that is a major achievement.

A quick dig into tomcat7 conf and tested with docker will lead you to the 
following working ssl conf. Be aware that Java7 is not really able to handle 
modern ssl requirements like bit length > 1024bit or server cipher order.



You may want to test a local ssl setup with the great testssl.sh tool by dirk 
wetter (https://testssl.sh ), also available on docker.
I’ve picked the ciphers from the list that testssl.sh showed me for the 
standard conf of Tomcat 8.0.47 and JRE7 (RFC notation). Then I’ve added your 
requested cipher.

HTH,

Peter

Re: tomcat ssl setup

[logo]

G, I hate formatting in Mails...

Beware of “ when copying source code!

> Am 26.09.2017 um 22:25 schrieb l...@kreuser.name:
> 
> John,
> 
> 
> 
>> Am 26.09.2017 um 21:26 schrieb John Ellis :
>> 
>> Yesterday my boss suggested setting up Tomcat vers. 8 as he thought this is 
>> what Jira and/or Confluence would use so I did that and it worked fine on 
>> http port of 8080. I then edited the server.xml file again for the SSL port 
>> and got the same result as before; never gets to a webpage login using the 
>> secure port of 8443 but I can still get the webpage on port 8080. When I 
>> look at the Tomcat 8 Catalina log file I see several lines where it says- 
>> "java.security.KeyStoreException: Cannot store non-PrivateKeys". I have been 
>> googling that error and found a couple of posts saying to change from JKS to 
>> JCEKS but when I ran the commands I didn't have JKS in the command; only RSA 
>> for the algorithm. Can someone provide me with the proper keytool commands 
>> that I need to use to create an SSL certificate for Tomcat?   
>> 
>> John Ellis
>> 
>> 405.285.2500 office
>> 
>> 
> 
> 
> We’re talking about Tomcat 8.5, 8.0 is EOLed so it may not make sense to ride 
> a dead horse, also SSL setup has changed quite a bit in 8.5/9.0.
> 
> So my setup is as follows:
> 
> server.xml:
> 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>allowTrace="false"
>maxThreads="150"
>SSLEnabled="true"
>compression="off"
>scheme="https"
>server="Apache Tomcat"
>secure="true"
   defaultSSLHostConfigName=“localhost” > 
> 
>hostName="localhost"
>honorCipherOrder="true"
>certificateVerification="none"
>protocols="TLSv1.2"
>
> ciphers="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305: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-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS">
>  certificateKeystoreFile="${catalina.base}/conf/ssl/jssecacerts"
>  certificateKeystorePassword="changeit"
>  certificateKeyAlias="tomcat"
>  type="RSA" />
>
>  
> 
> https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl
>  
> 
> 
> I use openssl to create the certs (as let’s encrypt for an official cert will 
> generate the same structure) and then convert to JKS:
> 
> openssl genrsa -aes256 -out server.key 4096 -subj 
> "/C=XX/ST=XX/L=XX/O=XX/CN=localhost"
> openssl req -new -key server.key -out server.csr -sha512  -subj 
> "/C=XX/ST=XX/L=XX/O=XX/CN=localhost/emailAddress=x...@xx.com"
> #there is more to it to get SAN extensions, but that’s not necessary to get 
> it running
> 
> openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out 
> server.crt
> # you may need your own ca and a signing-process to make this work in all 
> browsers
> 
> #Verify Server Cert
> openssl x509 -in server.crt -text -noout
> 
> openssl pkcs12 -export -in server.crt -inkey server.key -out jssecacerts 
> -name tomcat
> keytool -list -v -keystore jssecacerts -storepass changeit
> 
> 
> Hope this helps for a start.
> 
> Regards
> 
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: tomcat ssl setup

[logo]

John,



> Am 26.09.2017 um 21:26 schrieb John Ellis :
> 
> Yesterday my boss suggested setting up Tomcat vers. 8 as he thought this is 
> what Jira and/or Confluence would use so I did that and it worked fine on 
> http port of 8080. I then edited the server.xml file again for the SSL port 
> and got the same result as before; never gets to a webpage login using the 
> secure port of 8443 but I can still get the webpage on port 8080. When I look 
> at the Tomcat 8 Catalina log file I see several lines where it says- 
> "java.security.KeyStoreException: Cannot store non-PrivateKeys". I have been 
> googling that error and found a couple of posts saying to change from JKS to 
> JCEKS but when I ran the commands I didn't have JKS in the command; only RSA 
> for the algorithm. Can someone provide me with the proper keytool commands 
> that I need to use to create an SSL certificate for Tomcat?   
> 
> John Ellis
> 
> 405.285.2500 office
> 
> 


We’re talking about Tomcat 8.5, 8.0 is EOLed so it may not make sense to ride a 
dead horse, also SSL setup has changed quite a bit in 8.5/9.0.

So my setup is as follows:

server.xml:

 

 

  

https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl
 


I use openssl to create the certs (as let’s encrypt for an official cert will 
generate the same structure) and then convert to JKS:

openssl genrsa -aes256 -out server.key 4096 -subj 
"/C=XX/ST=XX/L=XX/O=XX/CN=localhost"
openssl req -new -key server.key -out server.csr -sha512  -subj 
"/C=XX/ST=XX/L=XX/O=XX/CN=localhost/emailAddress=x...@xx.com"
#there is more to it to get SAN extensions, but that’s not necessary to get it 
running

openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out 
server.crt
# you may need your own ca and a signing-process to make this work in all 
browsers

#Verify Server Cert
openssl x509 -in server.crt -text -noout

openssl pkcs12 -export -in server.crt -inkey server.key -out jssecacerts -name 
tomcat
keytool -list -v -keystore jssecacerts -storepass changeit


Hope this helps for a start.

Regards

Peter