If you never had SSL configured for Tomcat to begin with, I doubt that is the case now. I'm leaning toward RedHat misdiagnosing the error.
Whether Tomcat has mysteriously been configured for SSL or not, the error in question deals only with missing support for SHA-1, which apparently is needed for Java's secure random number generator. I believe Tomcat will use the secure random number generator regardless of whether SSL is configured, and Guacamole needs it as well for generating user autb tokens. Can you verify whether the same Java packages were installed as before, and that the files installed for those packages haven't become corrupt? I would expect SecureRandom to initialize without internal errors for any Java install, and if the original issue was filesystem corruption, remnants of that original issue may remain. If all else fails, a fresh install on a system which was never corrupted may be in order. - Mike On Mon, Dec 30, 2019, 15:07 Devine, Harry (FAA) <[email protected]> wrote: > The file system had gotten corrupted and they fixed that. Once the VM > came back online, we were unable to get the web interface to come up. We > are using Apache with a RapidSSL certificate, and we proxy the requests to > the guacamole backend as non ssl (i.e ProxyPass > http://localhost:8080/guacamole). > > > > Here’s what Red Hat had found in the logs that made them point me towards > the keystore, even though I know that the SSL certificate was working > before the disk corruption: > > > > And you have some SEVERE logs in Tomcat: > > > > ~~~ > > INFO: Deploying web application archive > /var/lib/tomcat/webapps/guacamole.war > > Dec 26, 2019 10:48:10 AM org.apache.catalina.startup.TldConfig execute > > INFO: 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 u > > nneeded JARs during scanning can improve startup time and JSP compilation > time. > > Dec 26, 2019 10:48:10 AM org.apache.catalina.startup.HostConfig deployWARs > > SEVERE: Error waiting for multi-thread deployment of WAR files to complete > > java.util.concurrent.ExecutionException: java.lang.InternalError: internal > error: SHA-1 not available. > > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:832) > > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495) > > at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1713) > > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:337) > > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > > at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:388) > > at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:333) > > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1136) > > at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:819) > > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) > > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1571) > > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1561) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > at java.lang.Thread.run(Thread.java:748) > > Caused by: java.lang.InternalError: internal error: SHA-1 not available. > > (...) > > Caused by: java.security.NoSuchAlgorithmException: SHA MessageDigest not > available > > at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) > > at java.security.Security.getImpl(Security.java:695) > > at java.security.MessageDigest.getInstance(MessageDigest.java:167) > > at sun.security.provider.SecureRandom.init(SecureRandom.java:106) > > ... 34 more > > ~~~ > > > > It seems that you tried to set up an SSL configuration, but your > certificate and keystore are incomplete. This is causing an error while > deploying all artifacts of Tomcat including the ROOT, manager and guacamole > applications. > > > > Thanks, > > Harry > > > > *From:* Mike Jumper <[email protected]> > *Sent:* Monday, December 30, 2019 4:53 PM > *To:* [email protected] > *Subject:* Re: FW: Java Keystore > > > > What was the nature of the issue that RedHat resolved and what changes did > they make between when things worked and when things stopped working? > > > > Is Tomcat configured for SSL, or are you using a proxy to provide SSL > termination with internal communication between that proxy and Tomcat using > unencrypted HTTP? > > > > - Mike > > > > On Mon, Dec 30, 2019, 13:27 Devine, Harry (FAA) < > [email protected]> wrote: > > Anyone have any insights on this? Our production server using Guacamole > is down until I get this piece resolved. > > > > Thanks, > > Harry > > > > *From:* Devine, Harry (FAA) <[email protected]> > *Sent:* Friday, December 27, 2019 9:32 AM > *To:* [email protected] > *Subject:* Java Keystore > > > > We had an issue with one of our servers that Red Hat helped us fix. It > had a package corruption. Now, even though HTTP and guac are started, I > can’t get the guacamole interface to show up. We have our own SSL > certificate and we forward requests to the guacamole backend. Red Hat is > telling us that we need to update the keystore to reflect our SSL > certificate but we can’t find it. I looked in /etc/tomcat/server.xml but > nothing was shown. > > > > We are on RHEL 7.7 and Guacamole 0.9.13-incubating. The system has 2 java > 1.7 packages and 2 1.8 packages installed, but I’m not sure which is being > used by guacamole. > > > > Thanks for any help, > > Harry > > > > Harry Devine > > DOT/FAA/AJM-2431 > > Terminal Server (NASDAC) Adminstrator > > Red Hat Certfied System Adminstrator (RHCSA) > > [email protected] > > (609)485-4218 > > Building 300, 3rd Floor, Column L20 (3L20) > > > >
