Re: trying to deploy oscar (was Re: how to tune cacheMaxSize )
I grabbed apache-tomcat-9.0.52.tar.gz from https://downloads.apache.org/tomcat/tomcat-9/v9.0.52/bin/apache-tomcat-9.0.52.tar.gz I unpacked it to /opt/apache-tomcat-9.0.52.tar.gz. I uninstalled tomcat9 (purged, and rm -rf /var/lib/tomcat/webapps) I tweaked CATALINA_HOME and JRE_HOME appropriately. I ran $CATALINA_HOME/bin/start.sh. As root, which clearly was a mistake. I thought it would su, but clearly I should start it as mortal user. Perhaps there is a better script, but clearly the tomcat package took care of that. (I wouldn't want to run it as root in production at all) Before fixing that mistake, I notice: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 6246 root 20 0 3417M 37392 17752 S 201. 0.9 22:34.04 /usr/bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties -Djava.util.logging.manag 6252 root 20 0 3417M 37392 17752 R 100. 0.9 11:10.02 /usr/bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties -Djava.util.logging.manag 6247 root 20 0 3417M 37392 17752 R 100. 0.9 11:15.75 /usr/bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties -Djava.util.logging.manag oscar-serv03-[~] root 55 #ls -l /opt/apache-tomcat-9.0.52/logs total 0 -rw-r- 1 root root 0 Aug 16 20:34 catalina.2021-08-16.log -rw-r- 1 root root 0 Aug 16 20:34 catalina.out -rw-r- 1 root root 0 Aug 16 20:34 host-manager.2021-08-16.log -rw-r- 1 root root 0 Aug 16 20:34 localhost.2021-08-16.log -rw-r- 1 root root 0 Aug 16 20:34 manager.2021-08-16.log I've done nothing. No deploy. Of course, the manager is included, so perhaps it is compiling or deploying that? Port 8080 not open: oscar-serv03-[~] root 56 #netstat -tan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 192.168.2.13:22 192.168.2.3:56962 ESTABLISHED tcp0 0 192.168.2.13:22 192.168.2.3:56968 ESTABLISHED tcp6 0 0 :::22 :::*LISTEN oscar-serv03-[~] mcr 10002 %free totalusedfree shared buff/cache available Mem:4030104 169540 2835356 792 1025208 3603084 Swap: 1048572 0 1048572 So, 169M of ~4G used. No swapping. Lots of ram free. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: how to tune cacheMaxSize
Christopher Schultz wrote: > Okay, all that looks fine to me, except the "9.0.16" part. That version > is *very/8 old. I see you are running Ubuntu: are you running the > latest release? That 9.0.16 number if rinning a bell about an older > release which was capped at 9.0.16. YOu might want to consider > upgrading everything once you figure all of this out. No need to muddy > the waters quite, yet, though. Ubuntu 18.04. I shall look for a ppa with newer tomcat. It's a VM, I could go to Core 20. > A few more things: > 1. It takes 12 seconds to initialize the server? That seems > ... slow. Is this on Amazon? What instance type? The memory size > 3.75GiB is ringing a bell, too. I could go to 8G for the VM if you think that's relevant. My reading is that I'm not even using 1G of ram at this point. No, it's not in Amazon. It's a Dell Xeon workstation in the basement of my wife's clinic. Patient record confidentiality would probably contraindicate EC2 :-) > 2. You shouldn't have the "docs" > project depployed on a production system. I installed it there to grep/read them, then decided that I'd install that on my desktop. > 3. I don't see any message > "Deploying deployment descriptor blah/blah/oscar/blah" Yes, exactly. Christopher Schultz wrote: >> 14-Aug-2021 17:16:45.464 SEVERE [Catalina-utility-1] >> org.apache.catalina.startup.HostConfig.deployWAR Error deploying web >> application archive [/var/lib/tomcat9/webapps/oscar.war] >> java.lang.IllegalStateException: Error starting child at >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716) >> ... >> > That certainly looks bad. Are you building OSCAR yourself, or is it > pre-built? I'm assuming that all local customizations are done using > separate config files or in the database, right? Can you get a fresh > copy of the oscar.war file? No, I'm not building myself. There is an oscar.deb, which btw, results in the same 100%. It also does other stuff like configure mariadb locally (which I don't want). But, I've used the oscar.war from that deb, and also the oscar.war which is on the bare-metal version that is running. >> 14-Aug-2021 17:16:45.506 INFO [Catalina-utility-1] >> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web >> application archive [/var/lib/tomcat9/webapps/oscar.war] has finished >> in [1,684] ms > That's nice and fast. No, it's in error. >> 14-Aug-2021 17:16:55.661 INFO [Catalina-utility-2] >> org.apache.catalina.startup.HostConfig.undeploy Undeploying context >> [/oscar] 14-Aug-2021 17:16:58.286 INFO [Catalina-utility-2] >> org.apache.catalina.startup.HostConfig.deployWAR Deploying web >> application archive [/var/lib/tomcat9/webapps/oscar.war] > Strange that it's deploying, then undeploying, then deploying again. Is > it possible that there are weird file timestamps? Maybe something in > the future? I think that the cp of the 220M oscar.war hasn't completed when it starts that first deploy. That's why the ZIP error. >> My guess is that the cp oscar.war /var/lib/tomcat9/webapps hadn't >> actually finished yet when it tried to deploy it. > That can definitely break things. If you are going to drop a WAR file > on Tomcat, make sure that either Tomcat isn't running, or you are using > the Manager web application to upload-and-deploy the WAR file which > protects you from deploying mid-copy. This is the only time I've seen this error, I've also used the manager web application before. >> So the port is open, so I attempt to visit the /manage URL >> >> oscar-serv03-[~] root 31 #netstat -tan Active Internet connections >> (servers and established) Proto Recv-Q Send-Q Local Address Foreign >> Address State tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp 0 0 >> 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN >> tcp 0 0 192.168.2.13:22 192.168.2.3:56896 ESTABLISHED tcp 0 0 >> 192.168.2.13:22 192.168.2.3:56898 ESTABLISHED tcp6 0 0 :::22 :::* >> LISTEN tcp6 0 0 :::8080 :::* LISTEN tcp6 559 0 192.168.2.9:8080 >> 192.168.2.3:37486 ESTABLISHED >> >> And it just stalls. > Is there anything between Tomcat and your web browser? Like a reverse > proxy, firewall, etc.? What URL are you trying to hit? I have an ssh -L 8080:192.168.2.9:8080 tunnel from my desktop. There is nothing else in between. >> I went to eat lunch and watch TV, so waited a few hours, and it's the >> same afterwards. Note that it never told me that it had finished >> deploying this war. >> >> I've tried kill-3 repeatedly, on the main PID of the process, and >> gotten no output. > Anything in the other log files? Nope. > Instead of kill -3, what if you use the "jstack" utility and provide > the PID of the running process? (You'll wan
Re: Getting some peculiar TLS results in Tomcat 7
Chris, On 8/16/2021 12:56 PM, Christopher Schultz wrote: protocol="org.apache.coyote.http11.Http11Protocol" sslEnabledProtocols="TLSv1.2" ... and have no other protocol-related configuration settings. Thanks. That was my take as well. However, I figured the original author could read the documentation and not have it spelled out. I'm a little out of my field here since we do all of our HTTPS stuff on Apache HTTPD or AWS load balancers at $work. Nexus 3 uses Jetty under the covers, so when I implement a local docker repository, I'll have to wade through that (not looking forward to it). OpenPGP_signature Description: OpenPGP digital signature
Re: Getting some peculiar TLS results in Tomcat 7
Mark, On 8/13/21 21:13, Mark Eggers wrote: On 8/13/2021 5:27 PM, James H. H. Lampert wrote: While we've been systematically updating our customer boxes, a few of our customer boxes are still on Tomcat 7. I've got the following Connector tag set up in server.xml: compressableMimeType="text/html,text/xml,text/plain,text/css, text/javascript,text/json,application/x-javascript, application/javascript,application/json" /> And yet SSLLabs tells me the box in question is still accepting TLS 1.0 and TLS 1.1. Can anybody shed any light on this? (And yes, I know, "alias" should be "keyAlias," but it's the only chain in the keystore, so it shouldn't make any difference.) https://tomcat.apache.org/tomcat-7.0-doc/config/http.html Search for sslEnabledProtocols +1 In later versions of Tomcat, there is only one "protocols" configuration property, and it does "What you expect". The reason for the two separate configuration settings "sslProtocols" and "sslEnabledProtocols" (oh and also "SSLProtocol" for APR) is historical. Down in the JSEE API, you need to request an SSLContext object from a factory method, and you need to tell that factory what "protocol" you want. There are a whole host of things you can pass to that factory method like "TLSv1" and stuff like that, but the documentation says "the returned object will support that protocol; other protocols may be supported as well." And guess what? The object you get always supports all the protocols! So you need to tell Java what "protocol" you want, but then you may have to customize the "enabled protocols" if you want to specifically *disable* a certain protocol version. It's only after 2000 or so that anybody has been interested in *disabling* anything. Before that, it was all about being as accepting as possible. These days, security-mindedness has taken-over and it's appropriate to restrict things, disable old protocols, etc. And yet the configuration still exists. In 8.5, we replaced everything with "protocols" which will give you the exact settings you expect. But for 7.0.x, you still need to set "sslEnabledProtocols". You should probably never bother setting "sslProtocol". I note that you are using "sslProtocol" (which is slightly misspelled SSLProtocol; I'm not sure if that's a problem) but you are also explicitly specifying protocol="org.apache.coyote.http11.Http11Protocol" (which is a confusingly-named configuration setting which picks the class used to actually handle the byte-level conversation with the client). SSLProtocol is documented to only be used with the APR connector, and you are specifically requesting the "blocking Java-based" connector. So I would guess that SSLProtocol is being completely ignored. Do you log files say anything about not finding a matching setting for that configuration property? I would guess "yes, it's in the logs and we never noticed it." I think you want your Tomcat 7.x configuration to look like this: protocol="org.apache.coyote.http11.Http11Protocol" sslEnabledProtocols="TLSv1.2" ... and have no other protocol-related configuration settings. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: trying to deploy oscar (was Re: how to tune cacheMaxSize )
Michael, On 8/14/21 16:05, Michael Richardson wrote: <#secure method=pgpmime mode=sign> Extracts of log, full log at URL below. 18k. 14-Aug-2021 17:16:43.821 INFO [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/var/lib/tomcat9/webapps/oscar.war] 14-Aug-2021 17:16:44.005 SEVERE [Catalina-utility-1] org.apache.catalina.startup.ContextConfig.beforeStart Exception fixing docBase for context [/oscar] java.util.zip.ZipException: zip END header not found ... 14-Aug-2021 17:16:45.464 SEVERE [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployWAR Error deploying web application archive [/var/lib/tomcat9/webapps/oscar.war] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716) ... That certainly looks bad. Are you building OSCAR yourself, or is it pre-built? I'm assuming that all local customizations are done using separate config files or in the database, right? Can you get a fresh copy of the oscar.war file? 14-Aug-2021 17:16:45.506 INFO [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/var/lib/tomcat9/webapps/oscar.war] has finished in [1,684] ms That's nice and fast. 14-Aug-2021 17:16:55.661 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.undeploy Undeploying context [/oscar] 14-Aug-2021 17:16:58.286 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/var/lib/tomcat9/webapps/oscar.war] Strange that it's deploying, then undeploying, then deploying again. Is it possible that there are weird file timestamps? Maybe something in the future? My guess is that the cp oscar.war /var/lib/tomcat9/webapps hadn't actually finished yet when it tried to deploy it. That can definitely break things. If you are going to drop a WAR file on Tomcat, make sure that either Tomcat isn't running, or you are using the Manager web application to upload-and-deploy the WAR file which protects you from deploying mid-copy. So the first 1.684ms attempt fails, and then it tried again. (Times are UTC) oscar-serv03-[~] root 30 #netstat -tan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:3306 0.0.0.0:* LISTEN tcp0 0 192.168.2.13:22 192.168.2.3:56896 ESTABLISHED tcp0 0 192.168.2.13:22 192.168.2.3:56898 ESTABLISHED tcp6 0 0 :::22 :::*LISTEN tcp6 0 0 :::8080 :::*LISTEN So the port is open, so I attempt to visit the /manage URL oscar-serv03-[~] root 31 #netstat -tan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:3306 0.0.0.0:* LISTEN tcp0 0 192.168.2.13:22 192.168.2.3:56896 ESTABLISHED tcp0 0 192.168.2.13:22 192.168.2.3:56898 ESTABLISHED tcp6 0 0 :::22 :::*LISTEN tcp6 0 0 :::8080 :::*LISTEN tcp6 559 0 192.168.2.9:8080192.168.2.3:37486 ESTABLISHED And it just stalls. Is there anything between Tomcat and your web browser? Like a reverse proxy, firewall, etc.? What URL are you trying to hit? I went to eat lunch and watch TV, so waited a few hours, and it's the same afterwards. Note that it never told me that it had finished deploying this war. I've tried kill-3 repeatedly, on the main PID of the process, and gotten no output. Anything in the other log files? Instead of kill -3, what if you use the "jstack" utility and provide the PID of the running process? (You'll want to provide the PID of the parent JVM process, not a specific thread.) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to tune cacheMaxSize
Michael, On 8/14/21 11:56, Michael Richardson wrote: > > Thank you for the reply. > > Christopher Schultz wrote: > > On 8/12/21 11:05, Michael Richardson wrote: > >> I am trying to deploy OSCAR-EMR > Wow, that still exists? I remember more than a decade ago being asked to integrate a product at $work with that thing as a demo. We never did, because the market seemed not to really exist. I see you are in Canada. I know OSCAR same from McMaster University. Does it have a good ecosystem and install base in CA? > Yes, it's still quite popular among many Ontario (and I'm told BC) doctors, because it has good integration with the provincial billing system. Doctor like it because the price appears right, and doctors don't get rich by spending money. > There are a number of support companies that install it, but my experience (via my wife) is that their do a rather poor job of installation. No understanding of database encryption, replication, or even how to enable https. That's ... really bad. There seems to be developer still working on it, according to the bitbucket git commit lot. But, the public community around it seems to have died, as far as I can tell. That's a shame. As I have discovered through years of working with ASF and other projects, the community is far more important than the actual product itself. A good community can fix a bad product, but the reverse is not true. I am a member of other communities where the project ignores the community, which is also Not Good. Not naming any names. :) On 8/14/21 12:53, Michael Richardson wrote: This time, after apt-get purge tomcat9 and re-install, I seem to be in 100% CPU before I've deployed oscar or even updated the tomcat-users.xml to enable the manager login. HTOP view attached at bottom. (4 virtual CPUs, 4G of ram. KVM VM running ubuntu 18.04, on a server running ubuntu core 20) oscar-serv03-[~] root 276 #netstat -tan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:3306 0.0.0.0:* LISTEN tcp0 0 192.168.2.13:22 192.168.2.3:56874 ESTABLISHED tcp0 0 192.168.2.13:22 192.168.2.3:56556 ESTABLISHED tcp6 2 0 :::8080 :::*LISTEN tcp6 0 0 :::22 :::*LISTEN tcp6 747 0 192.168.2.9:8080192.168.2.3:37450 CLOSE_WAIT tcp6 489 0 192.168.2.9:8080192.168.2.3:37452 ESTABLISHED I find it weird that I have no catalina.out file: oscar-serv03-[~] root 274 #ls -l /var/log/tomcat9 total 8 -rw-r- 1 tomcat tomcat 5233 Aug 14 16:38 catalina.2021-08-14.log -rw-r- 1 tomcat tomcat0 Aug 14 16:37 localhost.2021-08-14.log -rw-r- 1 tomcat tomcat0 Aug 14 16:38 localhost_access_log.2021-08-14.txt You must be running usingh jsvc, which creates the catalina.[date].log file instead. No worries, there. I include cataline.2021-08-14.log here. Also now at: https://www.sandelman.ca/tmp/terapia9/catalina.2021-08-14.log ubuntu says that I have a new kernel and I should reboot, so I'll do another purge, reboot, and then reinstall again. 14-Aug-2021 16:38:02.279 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.16 (Ubuntu) 14-Aug-2021 16:38:02.302 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Sep 11 2019 19:47:51 UTC 14-Aug-2021 16:38:02.320 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.16.0 14-Aug-2021 16:38:02.343 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 14-Aug-2021 16:38:02.345 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.4.0-80-generic 14-Aug-2021 16:38:02.348 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 14-Aug-2021 16:38:02.374 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-11-openjdk-amd64 14-Aug-2021 16:38:02.380 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.11+9-Ubuntu-0ubuntu2.18.04 14-Aug-2021 16:38:02.382 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Ubuntu 14-Aug-2021 16:38:02.384 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /var/lib/tomcat9 14-Aug-2021 16:38:02.385 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat9 14-Aug-2021 16:38:02.472 INFO [main] org.apache.catalina.startup.VersionLoggerLis
Re: Error loading PKCS12 keystore, java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
All,
On 8/16/21 10:32, Christopher Schultz wrote:
All,
Anyone ever seen this before?
I'm using an older Tomcat (7.0.x) on an older Java (1.7.0_80) along with
a certificate from Let's Encrypt. This was the server I used to
initially develop my "Let's Encrypt Apache Tomcat" presentation and
scripts, so I am familiar with the process and everything that needs to
happen.
I was updating the script to use the new snap-based certbot instead of
the older one which is fraught with dependency issues, etc. and I'm able
to renew the certificate just fine, but after assembling the PKCS12
keystore, I'm getting this error when Tomcat attempts to start the HTTPS
connector.
My old script first converted from raw PEM files to PKCS12 using the
"openssl pkcs12" command, then converted to JKS using Java's "keytool".
I decided to cut-out the middle-man and use PKCS12 files directly this
time.
Here is my (sanitized) configuration:
I added the "truststoreType" just in case Tomcat was using the
keystoreType as the truststoreType, and defaulting to using the keystore
as the truststore. None of those things are true, but I left it in the
configuration.
When using "keytool" on the command-line to dump the certs, I get no
errors and the keystore contains the expected data.
Here is the command I use to assemble the pkcs12 file:
openssl pkcs12 -export -in "${LE_BASE}/cert.pem" -inkey
"${LE_BASE}/privkey.pem" \
-certfile "${LE_BASE}/fullchain.pem" \
-out "${CATALINA_BASE}/${HOSTNAME}.p12" -name tomcat \
-passout "pass:changeit"
Here is the complete stack trace of the error:
Aug 16, 2021 10:22:23 AM org.apache.coyote.AbstractProtocol start
SEVERE: Failed to start end point associated with ProtocolHandler
["http-nio-8443"]
java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.init(DerValue.java:365)
at sun.security.util.DerValue.(DerValue.java:320)
at
sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1233)
at java.security.KeyStore.load(KeyStore.java:1226)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:392)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSESocketFactory.java:343)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:599)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:511)
at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:493)
at
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:647)
at
org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:449)
at
org.apache.catalina.connector.Connector.startInternal(Connector.java:1007)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:321)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
Aug 16, 2021 10:22:23 AM org.apache.catalina.core.StandardService
startInternal
SEVERE: Failed to start connector
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
org.apache.catalina.LifecycleException: Failed to start component
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.r
Error loading PKCS12 keystore, java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
All,
Anyone ever seen this before?
I'm using an older Tomcat (7.0.x) on an older Java (1.7.0_80) along with
a certificate from Let's Encrypt. This was the server I used to
initially develop my "Let's Encrypt Apache Tomcat" presentation and
scripts, so I am familiar with the process and everything that needs to
happen.
I was updating the script to use the new snap-based certbot instead of
the older one which is fraught with dependency issues, etc. and I'm able
to renew the certificate just fine, but after assembling the PKCS12
keystore, I'm getting this error when Tomcat attempts to start the HTTPS
connector.
My old script first converted from raw PEM files to PKCS12 using the
"openssl pkcs12" command, then converted to JKS using Java's "keytool".
I decided to cut-out the middle-man and use PKCS12 files directly this time.
Here is my (sanitized) configuration:
I added the "truststoreType" just in case Tomcat was using the
keystoreType as the truststoreType, and defaulting to using the keystore
as the truststore. None of those things are true, but I left it in the
configuration.
When using "keytool" on the command-line to dump the certs, I get no
errors and the keystore contains the expected data.
Here is the command I use to assemble the pkcs12 file:
openssl pkcs12 -export -in "${LE_BASE}/cert.pem" -inkey
"${LE_BASE}/privkey.pem" \
-certfile "${LE_BASE}/fullchain.pem" \
-out "${CATALINA_BASE}/${HOSTNAME}.p12" -name tomcat \
-passout "pass:changeit"
Here is the complete stack trace of the error:
Aug 16, 2021 10:22:23 AM org.apache.coyote.AbstractProtocol start
SEVERE: Failed to start end point associated with ProtocolHandler
["http-nio-8443"]
java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.init(DerValue.java:365)
at sun.security.util.DerValue.(DerValue.java:320)
at
sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1233)
at java.security.KeyStore.load(KeyStore.java:1226)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:392)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSESocketFactory.java:343)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:599)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:511)
at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:493)
at
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:647)
at
org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:449)
at
org.apache.catalina.connector.Connector.startInternal(Connector.java:1007)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:321)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
Aug 16, 2021 10:22:23 AM org.apache.catalina.core.StandardService
startInternal
SEVERE: Failed to start connector
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
org.apache.catalina.LifecycleException: Failed to start component
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Metho
