I guess I will have to investigate the RHEL 7.3 entropy issue separately
(possibly as hobby project) and look for other options to make progress.
I still find it odd that something related to randomness (entropy generation)
is so consistent (the slowness is equally slow or more on multiple RHEL 7.3
systems I have, maybe I need to look for machines from different data center or
a physical 7.3 server).
And yes, the 10 year certificate validity is just for testing purposes. 😊
Thank you for your inputs. Indeed helpful in evaluating our choices.
Thanks,
Amit
-Original Message-
From: Christopher Schultz
Sent: Wednesday, November 25, 2020 9:42 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
Amit,
On 11/25/20 12:40, Amit Pande wrote:
> Thank you Chris for the inputs. Admittedly, I didn’t know the internals of
> Sun JCE/JSSE vs BC JCE.
>
> Pasting sample output and it indeed is taking minutes on RHEL 7.3. Not sure
> if I am indeed missing some trick here.
>
>
> RHEL 7.3 ---
>
> test-host-1:~ # date ; /usr/openv/java/jre/bin/keytool -providerpath
> /root/Downloads/bc-fips-1.0.2.jar -providerclass
> org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair
> -keyalg RSA -keypass "Test123" -validity 3650 -dname
> "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123"
> -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date
>
> Wed Nov 25 10:52:56 CST 2020 (START TIME)
>
> Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA)
> with a validity of 3,650 days
> for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing
> /tmp/test_bc.bcfks]
>
> Wed Nov 25 10:58:11 CST 2020 (END TIME) (Almost 6 minutes)
>
> test-host-1:~ # uname -a
> Linux test-host-1 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT
> 2016 x86_64 x86_64 x86_64 GNU/Linux test-host-1:~ # cat
> /etc/redhat-release Red Hat Enterprise Linux Server release 7.3
> (Maipo) test-host-1:~ # test-host-1:~ # /usr/openv/java/jre/bin/java
> -version java version "1.8.0_271"
> Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM)
> 64-Bit Server VM (build 25.271-b09, mixed mode) test-host-1:~ #
>
>
> RHEL 7.2 -
>
> [root@test-host-2 ~]# date ; /usr/openv/java/jre/bin/keytool
> -providerpath /root/bc-fips-1.0.2.jar -providerclass
> org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair
> -keyalg RSA -keypass "Test123" -validity 3650 -dname
> "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123"
> -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date
>
> Wed Nov 25 11:20:06 CST 2020 (START TIME)
>
> Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA)
> with a validity of 3,650 days
> for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing
> /tmp/test_bc.bcfks]
>
> Wed Nov 25 11:20:10 CST 2020 (END TIME)(Almost 4 seconds)
>
> [root@test-host-2 ~]# uname -a
> Linux test-host-2 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29
> EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
> [root@test-host-2 ~]# cat /etc/redhat-release Red Hat Enterprise Linux
> Server release 7.2 (Maipo)
> [root@test-host-2 ~]#
>
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> [root@test-host-2 ~]# /usr/openv/java/jre/bin/java -version java
> version "1.8.0_261"
> Java(TM) SE Runtime Environment (build 1.8.0_261-b33) Java HotSpot(TM)
> 64-Bit Server VM (build 25.261-b33, mixed mode)
> [root@test-host-2 ~]#
>
>
> Since the keytool is literally taking minutes (specifically on RHEL
> 7.3 as you can see above), enabling FIPS OOTB has become a challenge
> as it has resulted in some our test suites timing out.
What I see is that on two servers were everything is the same (except for the
RHEL version... weird; RHEL 7.2 and 7.3 have identical kernel versions?), two
identical command-lines take different amounts of time.
In both cases, you are using BC with FIPS enabled.
The reason is that one of the servers is starved for entropy and the other one
is not. Some operations require a LOT of entropy (like generating an RSA key)
and others require less entropy, but each of those operations consumes some of
the system's entropy as they occur.
When you run out, processes block waiting for it, and it's only created slowly
as random hardware events are sampled to generate that "high quality
randomness". So it can take a while.
Some servers have hardware that generates entropy faster, some servers have
usage profiles that cause certain hardware events to occur more often and
therefore keep the entropy pool full. Others are constantly starved for entropy.
> Tomcat is very much a core of our product and configuration and
> starting Tomcat in timely manner (FIPS or no FIPS) has been a critical
> requirement. And now, with this issue, test suites timing out, hard to
> convince to get the suite
