You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(3) |
Feb
(2) |
Mar
(8) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(15) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(2) |
Dec
(4) |
2003 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(6) |
May
(7) |
Jun
(5) |
Jul
(5) |
Aug
(25) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
(2) |
2004 |
Jan
(7) |
Feb
(4) |
Mar
(12) |
Apr
(16) |
May
(43) |
Jun
(56) |
Jul
(43) |
Aug
(40) |
Sep
(66) |
Oct
(12) |
Nov
(26) |
Dec
(10) |
2005 |
Jan
(13) |
Feb
(33) |
Mar
(16) |
Apr
(7) |
May
(10) |
Jun
(34) |
Jul
(41) |
Aug
(8) |
Sep
(4) |
Oct
(32) |
Nov
(20) |
Dec
(25) |
2006 |
Jan
(30) |
Feb
(101) |
Mar
(5) |
Apr
(75) |
May
(74) |
Jun
(22) |
Jul
(6) |
Aug
(70) |
Sep
(19) |
Oct
(21) |
Nov
(31) |
Dec
(50) |
2007 |
Jan
(15) |
Feb
(20) |
Mar
(24) |
Apr
(33) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
(7) |
Sep
(63) |
Oct
(68) |
Nov
(29) |
Dec
(68) |
2008 |
Jan
(30) |
Feb
(33) |
Mar
(30) |
Apr
(103) |
May
(78) |
Jun
(48) |
Jul
(72) |
Aug
(24) |
Sep
(62) |
Oct
(63) |
Nov
(70) |
Dec
(37) |
2009 |
Jan
(34) |
Feb
(35) |
Mar
(64) |
Apr
(34) |
May
(34) |
Jun
(58) |
Jul
(30) |
Aug
(30) |
Sep
(46) |
Oct
(52) |
Nov
(12) |
Dec
(23) |
2010 |
Jan
(121) |
Feb
(18) |
Mar
(53) |
Apr
(62) |
May
(62) |
Jun
(20) |
Jul
(33) |
Aug
(20) |
Sep
(36) |
Oct
(35) |
Nov
(44) |
Dec
(63) |
2011 |
Jan
(19) |
Feb
(32) |
Mar
(94) |
Apr
(41) |
May
(47) |
Jun
(25) |
Jul
(34) |
Aug
(20) |
Sep
(9) |
Oct
(41) |
Nov
(33) |
Dec
(24) |
2012 |
Jan
(12) |
Feb
(36) |
Mar
(48) |
Apr
(32) |
May
(20) |
Jun
(15) |
Jul
(32) |
Aug
(13) |
Sep
(33) |
Oct
(54) |
Nov
(25) |
Dec
(16) |
2013 |
Jan
(45) |
Feb
(39) |
Mar
(38) |
Apr
(50) |
May
(29) |
Jun
(30) |
Jul
(33) |
Aug
(12) |
Sep
(9) |
Oct
(25) |
Nov
(29) |
Dec
(20) |
2014 |
Jan
(25) |
Feb
(19) |
Mar
(16) |
Apr
(33) |
May
(27) |
Jun
(37) |
Jul
(29) |
Aug
(27) |
Sep
(37) |
Oct
(58) |
Nov
(109) |
Dec
(26) |
2015 |
Jan
(4) |
Feb
(35) |
Mar
(22) |
Apr
(35) |
May
(28) |
Jun
(20) |
Jul
(4) |
Aug
(16) |
Sep
(37) |
Oct
(13) |
Nov
(13) |
Dec
(14) |
2016 |
Jan
(22) |
Feb
(7) |
Mar
(23) |
Apr
(30) |
May
(10) |
Jun
(10) |
Jul
(15) |
Aug
(12) |
Sep
(22) |
Oct
(31) |
Nov
(5) |
Dec
(5) |
2017 |
Jan
(30) |
Feb
(25) |
Mar
(28) |
Apr
(4) |
May
(19) |
Jun
(13) |
Jul
(7) |
Aug
(1) |
Sep
(2) |
Oct
(5) |
Nov
(12) |
Dec
(2) |
2018 |
Jan
(7) |
Feb
|
Mar
(7) |
Apr
(2) |
May
(8) |
Jun
(18) |
Jul
(6) |
Aug
(3) |
Sep
(15) |
Oct
(33) |
Nov
(13) |
Dec
(7) |
2019 |
Jan
(5) |
Feb
(7) |
Mar
(30) |
Apr
(5) |
May
(4) |
Jun
(69) |
Jul
(86) |
Aug
(22) |
Sep
(6) |
Oct
(7) |
Nov
(5) |
Dec
(3) |
2020 |
Jan
(10) |
Feb
(12) |
Mar
(22) |
Apr
(5) |
May
(1) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(4) |
Feb
(11) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
|
Nov
(18) |
Dec
(2) |
2022 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Tomas G. <Tom...@ke...> - 2023-08-28 11:38:21
|
Great. I actually found it as well in the troubleshooting guide in the documentaiton. The documentation is pretty large so it can be hard to find everything. https://doc.primekey.com/ejbca/troubleshooting-guide/pki-management Regards, Tomas ________________________________ From: Jeremy Hansen via Ejbca-develop <ejb...@li...> Sent: Sunday, August 27, 2023 12:20 AM To: ejb...@li... <ejb...@li...> Cc: Jeremy Hansen <je...@sk...> Subject: Re: [Ejbca-develop] ERR_BAD_SSL_CLIENT_AUTH_CERT CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Figured this out from a post in another forum. This made it easy. I can’t find a “what do you do in this situation” in the docs. Maybe I missed it. "...I resolved the problem !! I regenerate the superadmin.p12 with the same procedure; so i did: ./ejbca.sh ra setuserstatus superadmin 10 ./ejbca.sh ra setclearpwd superadmin <MY PASSWD> ./ejbca.sh batch I imported the new superadmin.p12 file in my browser and know it's OK !!” -jeremy On Saturday, Aug 26, 2023 at 2:13 AM, Me <je...@sk...<mailto:je...@sk...>> wrote: It looks like my client certs may have expired for my EJBCA installation. Can anyone point me in the right direction on how to regenerate this without access to the web interface? Thanks -jeremy |
From: Moser B. <B....@co...> - 2023-08-28 07:51:33
|
Hi Jeremy, I would recommend using the EJBCA CLI (opt/ejbca/bin). You need SSH or physical access to your user management PKI machine. The basic commands look like this: # Set status to NEW, renew user with password $EjbcaCli ra setendentitystatus $EE_USER 10 $EjbcaCli ra setclearpwd $EE_USER $EE_PASS $EjbcaCli batch $EE_USER # Extract certificate hex serial number by Common Name (CN), register the user for a specific role (Administrator) Serial=$(keytool -list -v -keystore $Keystore -storepass $Password | grep -A 5 CN=$Username | grep "Serial number:" | cut -f3 -d" ") $EjbcaCli roles addrolemember --caname $CaName --role "$Userrole" --value $Serial --with WITH_SERIALNUMBER --description "$Username $Timestamp" Here is how we at Commend automated these tasks with two separated scripts. pki-user-management$ ./ejbca-enrole-cert.sh user password [ECDSA/RSA] [2048/4096/secp384r1] pki-user-registration$ ./ejbca-register-user-cert.sh user-common-name user-role keystore.p12 password [caname] [dryrun] #!/bin/bash # MIT License # Copyright © 2020 Commend International, author: Benjamin Moser # # Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without # restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom # the Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE # AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, # ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # # Script to (re)enrole ejbca management user certificate # USAGE=$' Script to (re)enrole ejbca management user certificate requires: * conf/batchtool.properties * keys.alg=RSA * keys.spec=2048 * ejbca-cli Usage: ./ejbca-enrole-cert.sh user password [ECDSA/RSA] [2048/4096/secp384r1] ' if [[ $# -lt 2 ]]; then echo "$USAGE" exit 1 fi # Config EjbcaCli="/opt/ejbca/ejbca/bin/ejbca.sh" BatchCfg="/opt/ejbca/ejbca/conf/batchtool.properties" Backup=`tr -dc '0-9' < /dev/urandom | head -c8` EE_USER=$1 EE_PASS=$2 EE_KEYALG=$3 EE_KEYSPEC=$4 echo EJBCA user certificate enrolement ... if [[ ! "$EE_USER" =~ ^[a-zA-Z.0-9_-]{4,200}$ ]] || [[ ! "$EE_PASS" =~ ^.{4,64}$ ]]; then echo "Error: invalid entity user or password" echo "$USAGE" exit 1 fi $EjbcaCli ra setendentitystatus $EE_USER 10 retVal=$? if [ $retVal -ne 0 ]; then echo "Error: EJBCA user certificate enrolement failed! Couldn't set entity status!" exit 1 fi $EjbcaCli ra setclearpwd $EE_USER $EE_PASS retVal=$? if [ $retVal -ne 0 ]; then echo "Error: EJBCA user certificate enrolement failed! Couldn't set credentials!" exit 1 fi # Check that the file "key_pass.txt" is present, if not create it with default user/pwd: if [ ! -f $BatchCfg ] then echo "Error: EJBCA user certificate enrolement failed! Couldn't find batch file $BatchCfg!" exit 1 fi if [ ! -z $EE_KEYALG ] && [ ! -z $EE_KEYSPEC ] then cp $BatchCfg "$BatchCfg.$Backup" echo "Batchtool.properties file $BatchCfg.$Backup backup created" sed -i "s/^keys.alg=.*$/keys.alg=${EE_KEYALG}/g" $BatchCfg sed -i "s/^keys.spec=.*$/keys.spec=${EE_KEYSPEC}/g" $BatchCfg echo "Batchtool.properties file $BatchCfg has been modified succesfully" cat $BatchCfg fi # batch command doesn't return an error, but find+grep status does $EjbcaCli batch $EE_USER # restore batch config file if [ -f "$BatchCfg.$Backup" ]; then echo "Batchtool.properties file $BatchCfg.$Backup backup restored" cp "$BatchCfg.$Backup" $BatchCfg cat $BatchCfg fi $EjbcaCli ra findendentity --username $EE_USER | grep "Status: 40" retVal=$? if [ $retVal -ne 0 ]; then echo "Error: EJBCA user certificate enrolement failed!" exit 1 fi echo EJBCA user certificate enrolement done! #!/bin/bash # MIT License # Copyright © 2020 Commend International, author: Benjamin Moser # # Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without # restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom # the Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE # AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, # ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. USAGE=$' Utility to register a EJBCA user certificate to access CA/RA/VA WebUI requires: * user certificate * ejbca-cli * keytool * config Usage: ./ejbca-register-user-cert.sh user-common-name user-role keystore.p12 password [caname] [dryrun] ' # Config EjbcaCli="/opt/ejbca/ejbca/bin/ejbca.sh" KeystoreDir="/opt/ejbca/ejbca/p12" Timestamp=$(date) Username=$1 Userrole=$2 Keystore=$3 Password=$4 CaName=$5 DryRun=$6 if [[ ! "$Username" =~ ^[a-zA-Z0-9_-]{4,200}$ ]] || [[ ! "$Password" =~ ^.{12,64}$ ]]; then echo "Error: invalid user or password" echo "$USAGE" exit 1 fi if [[ ! "$Keystore" =~ ^[a-zA-Z0-9_-]{4,200}.(p12|jks)$ ]]; then echo "Error: invalid keystore file name" echo "$USAGE" exit 1 fi Keystore="$KeystoreDir/$3" if ! [[ -f "$Keystore" ]]; then echo -e "Error: $Keystore file not found!" echo "$USAGE" exit 1; fi # User role may include space in it name if [[ ! "$Userrole" =~ ^([a-zA-Z0-9_-]| ){4,200}$ ]]; then echo "Error: invalid user role = $Userrole" echo "$USAGE" exit 1 fi if [[ -z "$CaName" ]]; then CaName=$'CommendManagementCA' fi if [[ ! "$CaName" =~ ^[a-zA-Z0-9_-]{4,200}$ ]]; then echo "Error: invalid ca name" echo "$USAGE" exit 1 fi if [[ -n "$DryRun" ]] && [[ "$DryRun" == "dryrun" ]]; then # override call to EJBCA EjbcaCli="echo run $EjbcaCli" fi # Extract certificate hex serial number by Common Name (CN) Serial=$(keytool -list -v -keystore $Keystore -storepass $Password | grep -A 5 CN=$Username | grep "Serial number:" | cut -f3 -d" ") if [[ ! "$Serial" =~ ^[a-fA-FZ0-9]{4,200}$ ]]; then echo "Error: invalid serial extracted " echo "$USAGE" keyttool --help exit 1 fi # Register user for a specific role $EjbcaCli roles addrolemember --caname $CaName --role "$Userrole" --value $Serial --with WITH_SERIALNUMBER --description "$Username $Timestamp" retVal=$? if [ $retVal -ne 0 ]; then echo "Error: EJBCA user certificate registration failed!" echo "$USAGE" $EjbcaCli roles addrolemember --help exit 1 fi echo "EJBCA user certificate registration finished!" With best regards, Benjamin Moser Lead Security Architect and Open Source Software Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> www.commend.com<http://www.commend.com/> Security and Communication by Commend FN 178618z / LG Salzburg From: Jeremy Hansen via Ejbca-develop <ejb...@li...> Date: Saturday, 26. August 2023 at 11:32 To: ejb...@li... <ejb...@li...> Cc: Jeremy Hansen <je...@sk...> Subject: [External] [Ejbca-develop] ERR_BAD_SSL_CLIENT_AUTH_CERT CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. It looks like my client certs may have expired for my EJBCA installation. Can anyone point me in the right direction on how to regenerate this without access to the web interface? Thanks -jeremy |
From: Moser B. <B....@co...> - 2023-08-28 07:26:17
|
Hi Jeremy, Please have a look at my previous post. We NEVER recommend renewing the superadmin user. We revoked and deleted the user after installation and created for each PKI administrator a separated user. This is a MUST for security audits and hence we MUST register our users again on the PKI instances. With best regards, Benjamin Moser Lead Security Architect and Open Source Software Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> www.commend.com<http://www.commend.com/> Security and Communication by Commend FN 178618z / LG Salzburg From: Jeremy Hansen via Ejbca-develop <ejb...@li...> Date: Sunday, 27. August 2023 at 00:21 To: ejb...@li... <ejb...@li...> Cc: Jeremy Hansen <je...@sk...> Subject: [External] Re: [Ejbca-develop] ERR_BAD_SSL_CLIENT_AUTH_CERT CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Figured this out from a post in another forum. This made it easy. I can’t find a “what do you do in this situation” in the docs. Maybe I missed it. "...I resolved the problem !! I regenerate the superadmin.p12 with the same procedure; so i did: ./ejbca.sh ra setuserstatus superadmin 10 ./ejbca.sh ra setclearpwd superadmin <MY PASSWD> ./ejbca.sh batch I imported the new superadmin.p12 file in my browser and know it's OK !!” -jeremy On Saturday, Aug 26, 2023 at 2:13 AM, Me <je...@sk...<mailto:je...@sk...>> wrote: It looks like my client certs may have expired for my EJBCA installation. Can anyone point me in the right direction on how to regenerate this without access to the web interface? Thanks -jeremy |
From: Jeremy H. <je...@sk...> - 2023-08-26 22:20:58
|
Figured this out from a post in another forum. This made it easy. I can’t find a “what do you do in this situation” in the docs. Maybe I missed it. "...I resolved the problem !! I regenerate the superadmin.p12 with the same procedure; so i did: ./ejbca.sh ra setuserstatus superadmin 10 ./ejbca.sh ra setclearpwd superadmin <MY PASSWD> ./ejbca.sh batch I imported the new superadmin.p12 file in my browser and know it's OK !!” -jeremy > On Saturday, Aug 26, 2023 at 2:13 AM, Me <je...@sk... (mailto:je...@sk...)> wrote: > It looks like my client certs may have expired for my EJBCA installation. Can anyone point me in the right direction on how to regenerate this without access to the web interface? > > Thanks > -jeremy > > > > |
From: Jeremy H. <je...@sk...> - 2023-08-26 09:31:56
|
It looks like my client certs may have expired for my EJBCA installation. Can anyone point me in the right direction on how to regenerate this without access to the web interface? Thanks -jeremy |
From: Tomas G. <Tom...@ke...> - 2023-05-22 09:32:23
|
Hi Jaime, There are more people using ARM based Mac. Perhaps you can add to this thread on the GitHub discussions page? https://github.com/Keyfactor/ejbca-ce/discussions/287 We have many users internally using Macs as well, so it's an interesting topic. Cheers, Tomas ________________________________ From: Jaime Hablutzel <hab...@gm...> Sent: Saturday, April 8, 2023 9:36 PM To: ejb...@li... <ejb...@li...> Subject: [Ejbca-develop] Any chance to get ARM 64 builds of keyfactor/ejbca-ce? You don't often get email from hab...@gm.... Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. I've been using keyfactor/ejbca-ce for some time already, but given that I'm using the Apple M1 processor in my workstation, I'm being forced to remotely connect to another Intel machine for every EJBCA Docker related stuff. Is there any chance that Keyfactor releases ARM 64 images as well for the Docker image builds? I think that a service like https://www.scaleway.com/en/hello-m1/ could be used to build those images. -- Jaime Hablutzel - +51 994690880 |
From: Jaime H. <hab...@gm...> - 2023-04-08 19:37:15
|
I've been using keyfactor/ejbca-ce for some time already, but given that I'm using the Apple M1 processor in my workstation, I'm being forced to remotely connect to another Intel machine for every EJBCA Docker related stuff. Is there any chance that Keyfactor releases ARM 64 images as well for the Docker image builds? I think that a service like https://www.scaleway.com/en/hello-m1/ could be used to build those images. -- Jaime Hablutzel - +51 994690880 |
From: Jeremy H. <je...@sk...> - 2022-08-10 05:05:23
|
This worked perfectly. Thank you for your help! -jeremy > On Tuesday, Aug 09, 2022 at 5:57 AM, Tomas Gustavsson <Tom...@ke... (mailto:Tom...@ke...)> wrote: > Hi, > > The alias is configured as part of the TLS configuration commands. It ends up in standalone.xml, which you can edit by hand. The keystore configuration in there points to an actual entry in the TLS keystores. So you just have to update standalone.xml to use the alias of the keystore you deployed. > > I hope that helped, let us know if you need more details. > > Cheers, > Tomas > > From: Jeremy Hansen via Ejbca-develop <ejb...@li...> > Sent: Tuesday, August 9, 2022 4:27 AM > To: Gregory Edigarov via Ejbca-develop <ejb...@li...> > Cc: Jeremy Hansen <je...@sk...> > Subject: Re: [Ejbca-develop] Port and certificate > > > CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. > > Here’s some logs: > > 2022-08-08 19:22:23,773 INFO [org.jboss.as.patching] (MSC service thread 1-7) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none > 2022-08-08 19:22:23,798 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /usr/share/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > 2022-08-08 19:22:23,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SSLRealm.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SSLRealm.key-manager: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363) > at java.lang.Thread.run(Thread.java:750) > Caused by: java.lang.IllegalStateException: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} > at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:179) > at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:128) > at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:93) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) > ... 6 more > Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} > at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:140) > at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:175) > ... 10 more > > > I’m following the docs here: > > https://doc.primekey.com/ejbca790/ejbca-operations/ejbca-operations-guide/ca-operations-guide/end-entities/ssl-certificate-expiration (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.primekey.com%2Fejbca790%2Fejbca-operations%2Fejbca-operations-guide%2Fca-operations-guide%2Fend-entities%2Fssl-certificate-expiration&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cad17bcc7889a4be80b8e08da79aecc90%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637956089539233054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=2WOi5dRkD3xw4k1Pa6yI7uXdLUPIHzoJEIS%2F%2FVQLhhs%3D&reserved=0) > > I’m actually trying to change it from localhost to ca.la1.blah.com. > > I’ve updated web.properties. DId the renew-keystore and deploy-keystore, but reguardless, it comes up with this error as if localhost is still defined somewhere. > > Thanks > -jeremy > > > > > > On Monday, Aug 08, 2022 at 5:27 PM, Jeremy Hansen <je...@sk... (mailto:je...@sk...)> wrote: > > What’s the graceful way to update the port and the certificate for the EjbCA interface? Right now I’m using Wildfly 10.1.0 and Ejbca CE 7.5.0-Snapshot Community. I’d like to put it in on standard 443 instead of 8443. > > > > Thanks > > -jeremy > > > > > > |
From: Tomas G. <Tom...@ke...> - 2022-08-09 17:33:00
|
Hi, The alias is configured as part of the TLS configuration commands. It ends up in standalone.xml, which you can edit by hand. The keystore configuration in there points to an actual entry in the TLS keystores. So you just have to update standalone.xml to use the alias of the keystore you deployed. I hope that helped, let us know if you need more details. Cheers, Tomas ________________________________ From: Jeremy Hansen via Ejbca-develop <ejb...@li...> Sent: Tuesday, August 9, 2022 4:27 AM To: Gregory Edigarov via Ejbca-develop <ejb...@li...> Cc: Jeremy Hansen <je...@sk...> Subject: Re: [Ejbca-develop] Port and certificate CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Here’s some logs: 2022-08-08 19:22:23,773 INFO [org.jboss.as.patching] (MSC service thread 1-7) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none 2022-08-08 19:22:23,798 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /usr/share/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost 2022-08-08 19:22:23,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SSLRealm.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SSLRealm.key-manager: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363) at java.lang.Thread.run(Thread.java:750) Caused by: java.lang.IllegalStateException: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:179) at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:128) at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:93) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) ... 6 more Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:140) at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:175) ... 10 more I’m following the docs here: https://doc.primekey.com/ejbca790/ejbca-operations/ejbca-operations-guide/ca-operations-guide/end-entities/ssl-certificate-expiration<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.primekey.com%2Fejbca790%2Fejbca-operations%2Fejbca-operations-guide%2Fca-operations-guide%2Fend-entities%2Fssl-certificate-expiration&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cad17bcc7889a4be80b8e08da79aecc90%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637956089539233054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=2WOi5dRkD3xw4k1Pa6yI7uXdLUPIHzoJEIS%2F%2FVQLhhs%3D&reserved=0> I’m actually trying to change it from localhost to ca.la1.blah.com. I’ve updated web.properties. DId the renew-keystore and deploy-keystore, but reguardless, it comes up with this error as if localhost is still defined somewhere. Thanks -jeremy On Monday, Aug 08, 2022 at 5:27 PM, Jeremy Hansen <je...@sk...<mailto:je...@sk...>> wrote: What’s the graceful way to update the port and the certificate for the EjbCA interface? Right now I’m using Wildfly 10.1.0 and Ejbca CE 7.5.0-Snapshot Community. I’d like to put it in on standard 443 instead of 8443. Thanks -jeremy |
From: Jeremy H. <je...@sk...> - 2022-08-09 02:27:58
|
Here’s some logs: 2022-08-08 19:22:23,773 INFO [org.jboss.as.patching] (MSC service thread 1-7) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none 2022-08-08 19:22:23,798 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /usr/share/wildfly/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost 2022-08-08 19:22:23,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SSLRealm.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SSLRealm.key-manager: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363) at java.lang.Thread.run(Thread.java:750) Caused by: java.lang.IllegalStateException: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:179) at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:128) at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:93) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) ... 6 more Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0085: The alias specified 'localhost' does not exist in the KeyStore, valid aliases are {ca.la1.blah.com} at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:140) at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:175) ... 10 more I’m following the docs here: https://doc.primekey.com/ejbca790/ejbca-operations/ejbca-operations-guide/ca-operations-guide/end-entities/ssl-certificate-expiration I’m actually trying to change it from localhost to ca.la1.blah.com. I’ve updated web.properties. DId the renew-keystore and deploy-keystore, but reguardless, it comes up with this error as if localhost is still defined somewhere. Thanks -jeremy > On Monday, Aug 08, 2022 at 5:27 PM, Jeremy Hansen <je...@sk... (mailto:je...@sk...)> wrote: > What’s the graceful way to update the port and the certificate for the EjbCA interface? Right now I’m using Wildfly 10.1.0 and Ejbca CE 7.5.0-Snapshot Community. I’d like to put it in on standard 443 instead of 8443. > > Thanks > -jeremy > > > |
From: Jeremy H. <je...@sk...> - 2022-08-09 00:44:23
|
What’s the graceful way to update the port and the certificate for the EjbCA interface? Right now I’m using Wildfly 10.1.0 and Ejbca CE 7.5.0-Snapshot Community. I’d like to put it in on standard 443 instead of 8443. Thanks -jeremy |
From: Tomas G. <Tom...@ke...> - 2022-06-13 12:23:07
|
>From now on, our main discussion forum is on GitHub. Please join us there to share knowledge or ask questions to other developers or the product team: EJBCA Discussions on GitHub<https://github.com/Keyfactor/ejbca-ce/discussions>. The SourceForge mailing lists will be discontinued during 2022. We also welcome you to sign up for our Newsletter on Keyfactor Community,<https://www.keyfactor.com/community/> to stay up to date on the latest news, software updates, hands-on tutorials and user workshops on all our open-source software. Best regards, Tomas [1]: https://github.com/Keyfactor/ejbca-ce/discussions [2]: https://www.keyfactor.com/community/ |
From: Gregory E. <edi...@qa...> - 2022-02-18 18:03:00
|
hello, i am trying to run ejbca in docker on the server like this: docker network create ejbca-network docker run -d --restart=always --network ejbca-network \ --name ejbca-database \ -e MYSQL_ROOT_PASSWORD=rootpassword \ -e MYSQL_DATABASE=ejbca \ -e MYSQL_USER=ejbca \ -e MYSQL_PASSWORD=ejbcapassword \ -v /data/ejbca-db:/var/lib/mysql \ library/mariadb --character-set-server=utf8 \ --collation-server=utf8_bin docker run -d --restart=always --network ejbca-network --name ejbca \ -e DATABASE_JDBC_URL='jdbc:mysql://ejbca-database:3306/ejbca?characterEncoding=UTF-8' \ -e DATABASE_USER=ejbca \ -e DATABASE_PASSWORD=ejbcapassword \ -p 8009:8009 \ -p 8443:8443 \ -p 8080:8080 \ -p 8081:8081 \ -p 8082:8082 \ primekey/ejbca-ce this part works, ejbca starts, i am able to download superadmin.p12, and import it to the browser. but when I am trying to login using the /ebjca/adminweb/ uri, it says: AUTHORIZATIONDENIED CAUSE: Client certificate or OAuth bearer token required. and I cannot move any further. my browser is: Chromium Version 98.0.4758.80 (Official Build) (64-bit) am I doing something wrong? thanks a lot in advance. -- With best regards, Gregory Edigarov |
From: Tomas G. <tom...@pr...> - 2022-01-10 12:21:07
|
If you want to feed a dynamic certificate extension value to an end entity you can do that through the Extended Information field. You can pass that in the UI (enable "Custom certificate extension data" in the EE profile). There is an example in the docs: https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/certificate-profiles-overview/custom-certificate-extensions If you run "clientToolBox EjbcaWsRaCli edtuser" the heptext will also show an example I believe. Cheers, Tomas ________________________________ From: Christian Felsing via Ejbca-develop <ejb...@li...> Sent: Wednesday, December 29, 2021 12:17 PM To: Ejbca-develop <ejb...@li...> Cc: Christian Felsing <pu...@fe...> Subject: [Ejbca-develop] Problem Aquiring Value for Custom Certificate Extensions CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Hello, in EJBCA 7.4.3.2 Community, in "System Configuration" -> "Custom Certificate Extensions" an OID 1.3.6.1.4.1.311.25.1 was created with following parameters: Label: msADGUID Extension Class: Basic Certificate Extension Critical: False Required: True Dynamic: True Encoding: DEROCTETSTRING Value: <not set> was created. In "Certificate Profile" it is possible to select this in "Used Custom Certificate Extension", but I found no way to aquire value for that attribute from either certificate-/entity-profie or CSR. Is there any way to get values for Custom Certificate Extensions from EJBCA forms or CSR? Christian _______________________________________________ Ejbca-develop mailing list Ejb...@li... https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cbd41dbe2bd1346167c8208d9cabf97f7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637763747524638851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kqAY5VaZpPpEt73iv3CBHk7MtHFgfRl40G1gMK2S1II%3D&reserved=0 |
From: Christian F. <pu...@fe...> - 2021-12-29 11:36:08
|
Hello, in EJBCA 7.4.3.2 Community, in "System Configuration" -> "Custom Certificate Extensions" an OID 1.3.6.1.4.1.311.25.1 was created with following parameters: Label: msADGUID Extension Class: Basic Certificate Extension Critical: False Required: True Dynamic: True Encoding: DEROCTETSTRING Value: <not set> was created. In "Certificate Profile" it is possible to select this in "Used Custom Certificate Extension", but I found no way to aquire value for that attribute from either certificate-/entity-profie or CSR. Is there any way to get values for Custom Certificate Extensions from EJBCA forms or CSR? Christian |
From: Tomas G. <tom...@pr...> - 2021-12-01 09:17:40
|
It's CRLData. IssuerDN and crlNumber that is not a unique combination for some records. Cheers, Tomas ________________________________ From: Randy Yu via Ejbca-develop <ejb...@li...> Sent: Tuesday, November 30, 2021 10:24 PM To: 'ejb...@li...' <ejb...@li...> Cc: Randy Yu <yu...@ec...> Subject: [Ejbca-develop] EJBCA 6.10.1.2 - NonUniqueResultException CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Recently have been seeing the following error when generating CRL or accessing the Admin homepage. What data or which tables should I be looking at for the cause of the error? Thanks. Randy javax.persistence.NonUniqueResultException javax.ejb.EJBException: javax.persistence.NonUniqueResultException at org.cesecore.certificates.crl.CrlStoreSessionBean.getLastCRLInfo(CrlStoreSessionBean.java:191) 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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view71.getLastCRLInfo(Unknown Source) at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.getLastCRLInfo(CAInterfaceBean.java:356) at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.getAuthorizedInternalCaCrlStatusInfos(CAInterfaceBean.java:276) at org.apache.jsp.main_jsp._jspService(main_jsp.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) 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: javax.persistence.NonUniqueResultException at org.cesecore.util.QueryResultWrapper.getSingleResult(QueryResultWrapper.java:67) at org.cesecore.util.QueryResultWrapper.getSingleResult(QueryResultWrapper.java:41) at org.cesecore.certificates.crl.CRLData.findByIssuerDNAndCRLNumber(CRLData.java:265) at org.cesecore.certificates.crl.CrlStoreSessionBean.getLastCRLInfo(CrlStoreSessionBean.java:167) ... 134 more |
From: Randy Yu <yu...@ec...> - 2021-11-30 21:39:35
|
Recently have been seeing the following error when generating CRL or accessing the Admin homepage. What data or which tables should I be looking at for the cause of the error? Thanks. Randy javax.persistence.NonUniqueResultException javax.ejb.EJBException: javax.persistence.NonUniqueResultException at org.cesecore.certificates.crl.CrlStoreSessionBean.getLastCRLInfo(CrlStoreSessionBean.java:191) 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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view71.getLastCRLInfo(Unknown Source) at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.getLastCRLInfo(CAInterfaceBean.java:356) at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.getAuthorizedInternalCaCrlStatusInfos(CAInterfaceBean.java:276) at org.apache.jsp.main_jsp._jspService(main_jsp.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) 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: javax.persistence.NonUniqueResultException at org.cesecore.util.QueryResultWrapper.getSingleResult(QueryResultWrapper.java:67) at org.cesecore.util.QueryResultWrapper.getSingleResult(QueryResultWrapper.java:41) at org.cesecore.certificates.crl.CRLData.findByIssuerDNAndCRLNumber(CRLData.java:265) at org.cesecore.certificates.crl.CrlStoreSessionBean.getLastCRLInfo(CrlStoreSessionBean.java:167) ... 134 more |
From: Tomas G. <tom...@pr...> - 2021-11-22 14:38:09
|
The EJBCA WS API is stable. It has been used in production in installations more than 10 years, and we make sure new releases are backwards compatible. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...> Sent: Friday, November 19, 2021 5:20 PM To: ejb...@li... <ejb...@li...>; Tomas Gustavsson <tom...@pr...> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Hi Tomas, Currently I have not made any more progress in understanding the slow down of the ejbca.sh client. I have looked at using the EjbcaWsRaCli. Running commands using this CLI tool does seem to be much quicker than using the ejbca.sh. I notice not all commands are implemented through the WS API. What is the current status of the WS API? Is it a stable public API or is it an API primarily used for testing? Regards, Arwyn From: Launchbury, Arwyn via Ejbca-develop <ejb...@li...> Sent: 17 November 2021 16:46 To: Tomas Gustavsson <tom...@pr...>; ejb...@li... Cc: Launchbury, Arwyn <Arw...@nc...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Thanks Tomas, That is definitely worth considering, and I will look into this a bit. I have run the stress test for single threads and for multiple threads and the newer EJBCA 7 was much quicker in multi thread and slightly quicker in single thread so I think we can confirm that EJBCA and cesecore server side are not at fault. This does mean that something is slower either in the client or with remote EJB commands. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 12 November 2021 09:56 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Great findings Arwyn, One thing perhaps that you may consider is to use the WS API, where clientToolBox has a CLI. You can perform the three commands you list using the local CLI with a single WS/WS CLI command if using a CSR: ./ejbcaClientToolBox.sh EjbcaWsRaCli certreq Or multiple commands as well if issuing keystores (pkcs12), with your "own" WS client you can do other things as well. The WS API may be faster if it's the CLI remote EJB commands that are slower in newer WildFly. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 3:43 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I currently do not believe the slow down is caused by the EJBCA or cesecore server side. I turned on trace logging for only ejbca and cesecore loggers on the server side. All of these log messages appeared within 0.75 seconds of each other for EJBCA6 and within 0.85 seconds of each other for EJBCA7. This means I don’t think there has been a significant change to the server side performance of EJBCA or cesecore logic. When running a bin/ejbca.sh command I have observed the client ejbca.sh JVM startup time to be very similar in both versions of EJBCA, at around 1 second. In the case of EJBCA 6, the EJBCA and cesecore log messages show up ~ 0.5 seconds after the JVM has fully started up. In the case of EJBCA 7 the EJBCA and cesecore log messages show up ~ 1.7 seconds after the JVM has started up. This makes me think that either the client is slower by ~1.2 seconds in the new version, or there is some slow down in wildfly and the EJBRemoteInvocation. This gives the total time for one ejbca.sh command to go from ~2.25 seconds in EJBCA 6 to ~3.55, with most of this difference coming from the change in the client. (I believe changing the logging levels have had a slight effect on the performance, which is why these values are different to my original comment). Over a typical certificate renewal I would call the ejbca.sh command three separate times. The three commands I run would be bin/ejbca.sh ra setendentitystatus --username " user.name" -S 10 bin/ejbca.sh ra setpwd --username "user.name” --password “password” bin/ejbca.sh createcert --username “user.name” –password “password” -c “/tmp/tmp_csr” -f “/opt/ejbca/p12/pem/user.name.pem” As the server typically takes less than a second to respond, the change to the client performance is resulting in this process taking between 1.5 and 2 times longer than previously. I’ve been having some trouble running the stress test tool but I will try to get results from that to confirm the client is the issue. You mention that the stress test tool is able to run without having to restart the JVM. This leads me to thinking that it may be possible to follow the same pattern when running my certificate renewal. Is it possible to run multiple bin/ejbca.sh commands without restarting the JVM? If the JVM is reused, it may mean that the slow down in the client that I have observed would not have such a large effect over a typical workflow. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 11 November 2021 09:39 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Can you rule out that it is anything on the client side that is slow? For performance measurement of EJBCA itself, we typically run a "clientToolBox stress" which is a nice stress test tool that runs multiple threads in a single client JVM, avoiding any JVM loading issues, and showing certificate issuance speed. You can test single threaded performance (measure latency) and multi-threaded performance measuring throughput. This tool has been available since EJBCA 4 and can be used throughout the times. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/command-line-interfaces/ejbca-client-toolbox<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-operations-guide*2Fcommand-line-interfaces*2Fejbca-client-toolbox__*3B!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7Le8vlvqY*24%26data%3D04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517929729*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3DhMGyL86zCgiRbfNy7DfbfLpBZp*2BtS4l0onx6OIW*2Fd*2F4*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm27Z-oghY%24&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C03c076467b5546d8c93c08d9ab788228%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637729356367508722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P3Acq60qComCb83uq0BfEvoZgntTuXBktwCXPFU4i9Q%3D&reserved=0> Cheers, Tomas ________________________________ From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: Thursday, November 11, 2021 10:26 AM To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Sorry, I didn't mean trace logging for all of WildFly, I was thinking about trace logging for EJBCA. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/logging#Logging-DebugLogging<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-ca-concept-guide*2Flogging*Logging-DebugLogging__*3BIw!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7LGO9Rnhg*24%26data%3D04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517939677*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D0*2B*2BJB08tVQoz8xR*2BCHSZYgDkxNb5ETwe4ksEP4NrwCg*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm2V_Lyhww%24&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C03c076467b5546d8c93c08d9ab788228%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637729356367518676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cS%2FSlxuCnJZismHfsJJ2Lpj4kXX62GZcG3j6rT5gmkQ%3D&reserved=0> Thousands of CAs sounds like a quite special use case. Not a very normal use case. For sure EJBCA 7 is running in production issuing hundreds of certificates per second, from dozens of CAs, but I haven't been digging around with thousands of CAs yet personally. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 9:59 AM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi Tomas, I have now enabled trace logging on the client side. I have seen the longest message is the following, which takes approximately 0.6 seconds. I have been unable to find a similar log message in the log of the EJBCA 6 client. TRACE [SecurityProviderSaslClientFactory] - Created SaslClient for mechanism JBOSS-LOCAL-USER, using Provider WildFlyElytron and protocol remote The above log message always occurs between the following two DEBUG log messages, which seems to be where most of the slow down is seen. 2021-11-08 14:16:52,865 DEBUG [DiscoveryEJBClientInterceptor] - DiscoveryEJBClientInterceptor: calling executeDiscovery(locator = StatelessEJBLocator for "ejbca/cesecore-ejb/GlobalConfigurationSessionBean", view is interface org.cesecore.configuration.GlobalConfigurationSessionRemote, affinity is None, weak affinity = None) 2021-11-08 14:16:53,298 DEBUG [DelegatingBasicLogger] - Received MODULE_AVAILABLE(8) message from node <host> for module ejbca/certstore Another log message that seems to be taking a while in the client log is the following. This takes approximately 0.3 seconds the first time it shows up, but is much faster on subsequent appearances inside the same ejbca.sh call. 2021-11-10 09:11:56,605 TRACE [AuthenticationContextConfigurationClient] - getAuthenticationConfiguration uri=http-remoting://localhost:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, MatchRule=[abstractType=ejb,abstractTypeAuthority=jboss,host=localhost,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-protocol=http-remoting,set-port=4447,providers-supplier=org.wildfly.security.provider.util.ProviderServiceLoaderSupplier@93e09b04,mechanism-properties={javax.security.sasl.policy.noanonymous=false, javax.security.sasl.policy.noplaintext=true, wildfly.sasl.local-user.quiet-auth=true}] I have been doing this upgrade testing on my system where I have 500 CAs configured. My system is only used for testing, as the production system would be at EJBCA 6 currently. I would expect there to be a few thousand CAs on the production system. Regards, Arwyn From: Tomas Gustavsson via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: 09 November 2021 08:53 To: ejb...@li...<mailto:ejb...@li...> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Have you enabled debug logging? That should show clearly if there is anything in EJBCA that takes time. Question: do you have 500 CAs configured? Is this a production use case? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Monday, November 8, 2021 6:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I think my previous message regarding the client may have been incorrect. In the EJBCA 7 case I’m getting a io.undertow.request log in the server log approximately 1s after calling ejbca.sh, which is when I think the client JVM has started up. However there is then an approximately 1 second gap before the first cesecore log shows up (org.cesecore.configuration.GlobalConfigurationSessionBean). During this time the server does not seem to be doing anything, but the client is. In the EJBCA 6 case the first server log appears approximately 1 second after the ejbca.sh command is called, but it then takes only ~0.3 seconds for the cesecore log to show up. So it looks like the client is now taking ~2 seconds to connect after the upgrade, vs the old client taking ~1.2 seconds. You mention a slow client has been observed before, is there a way of finding out the cause and finding a way to speed up the client startup? I have now checked all of the DB indexes in the doc/sql-scripts/create-index-ejbca.sql script. After putting all indexes in place it does not seem to have had an effect on the total time. I have tested this and observed the slow down for up to about 500 CAs. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 18:21 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 Sounds like you are missing a database index. Check the recommended database indexes. Do you have many CAs, and/or CA certificates? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Friday, November 5, 2021 7:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thank you for the response. Currently we believe the issue is server side. I have compared the time between the ejbca.sh cli command being called and messages appearing in the server.log. This time was the same for both EJBCA 6 and EJBCA 7. I have tried profiling the older version of EJBCA 6 to compare it to the results we found for EJBCA 7. The getCAInternal function was taking approximately 0.05 seconds on the old version, approximately 10 times quicker than in EJBCA 7. I could not find getCertificateProfile when running EJBCA 6. These are the only functions from the ejbca or cesecore packages that seemed to be taking a long time in EJBCA 7, and as there is such a large difference in these functions after the upgrade we think this could be the cause of the issues. Has there been any changes to the internal EJBCA caching from the upgrade? Is there any specific options that mean EJBCA does not cache certificates anymore? Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 08:25 To: ejb...@li...<mailto:ejb...@li...> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 *External Message* - Use caution before opening links or attachments If anything, the performance of EJBCA should be better not worse after an upgrade. Did you check recommended indexes to add new database indexes that should be there. There are some new ones that we recommend. See doc/sql-scripts for the recommended indexes. As you already checked slow queries though, it may or may not help anything. If it just startup of the cli command that takes time, or does every request take time if you for example run a stress test? I.e. identify if its the client or server that has slowdown. You can check the server.log to see when a request come in and how long it takes to process. We have seen cases where for various reasons the startup/init time of java on the client side takes time, i.e. not EJBCA that is slow but the start-up of the JVM for the CLI client side process. Regards, Tomas ________________________________ From: Launchbury, Arwyn via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: Thursday, November 4, 2021 6:17 PM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi, We are currently in the process of upgrading the version of EJBCA we use and have noticed a significant decrease in performance. Our previous installation used EJBCA version 6.3.1.1, jboss version 7.1.1, and opendk 7. We have tried to upgrade to EJBCA version 7.4.3.2, wildfly version 18.0.1, and openjdk 8. We have noticed that ejbca.sh commands take approximately twice as long after the upgrade, for example ./ejbca.sh ra setendentitystatus went from ~1.5 seconds before the upgrade to ~3 seconds after the upgrade, and .ejbca.sh createcert went from ~2 seconds to ~4 seconds. We have tried some of the options in the PerformanceTuning (https://doc.primekey.com/ejbca743/ejbca-installation/application-servers/wildfly-18-jboss-eap-7-3#WildFly18/JBossEAP7.3-PerformanceTuning<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdoc.primekey.com*2Fejbca743*2Fejbca-installation*2Fapplication-servers*2Fwildfly-18-jboss-eap-7-3*23WildFly18*2FJBossEAP7.3-PerformanceTuning*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cb5562e5e7ab14034f90808d99fba0f08*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637716444467209936*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DeKHxGCeaet56ecbgaoxt6WzH4*2F*2FLzB9Zw7T*2Ft5eYBEQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!In4Qlw!6ZvD7OSOz-ZOVXXibdUGr8TXgIluCtaXVSPBS0iknh_KKTh-trtTeYreMBdyiA9e9GI*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cd1ea972107fb4d26293a08d9a0882a3e*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637717328989428655*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DBEAkcfNI7HxZ5iFmsFpWTfvJRTVqjZAtgUL1TF2nlvI*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKiUlKioqKioqKioqKioqJSUqKioqJSUlJSUlJSUlJSUlJSUlJSU!!In4Qlw!_2cNsYkEMpPutSXEorm2ptooFtWhc5Jm_SZI6aA_0-guiyQ8dkI9smRCjrBx1rbvaWU*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Ce351c5fc7ff64a58a4e408d9a2db3098*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637719884629212861*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DzQOUT2OHUnYk3*2FkG33oixtRpI*2BXE6*2Bjxw5rYv32X8O4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!8-KVx3UAT0IxCIX12v4XCzVWZ8GHzkq_jDBw5LrqWPF1ZcRlbItU0ZJmT4tM4IUl8eU*24&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C03c076467b5546d8c93c08d9ab788228%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637729356367528641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ev7%2FadApOWw9eGODqoJRMJEK12QcMKaGpol65GggZKk%3D&reserved=0>) section of the documentation, which has had no significant effect on the performance. We have tried profiling the EJBCA process, but have not yet found anything that is obviously causing the performance issues. Currently we have seen that both Lorg/cesecore/certificates/certificateprofile/CertificateProfileSessionBean:::getCertificateProfile and Lorg/cesecore/certificates/ca/CaSessionBean:::getCAInternal take approximately 0.5 seconds each during a setendentitystatus run. These seem to be taking a long time but we're not sure if they are the actual cause of the performance issues. We currently don't believe the MySQL DB is the cause of the performance issues as there were no entries in the Slow Query Log for any time greater than 50ms. Does anyone have any suggestions on how we could improve the performance of our installation, or how we would find the source of the performance issues? Kind Regards, Arwyn |
From: Launchbury, A. <Arw...@nc...> - 2021-11-19 16:20:31
|
Hi Tomas, Currently I have not made any more progress in understanding the slow down of the ejbca.sh client. I have looked at using the EjbcaWsRaCli. Running commands using this CLI tool does seem to be much quicker than using the ejbca.sh. I notice not all commands are implemented through the WS API. What is the current status of the WS API? Is it a stable public API or is it an API primarily used for testing? Regards, Arwyn From: Launchbury, Arwyn via Ejbca-develop <ejb...@li...> Sent: 17 November 2021 16:46 To: Tomas Gustavsson <tom...@pr...>; ejb...@li... Cc: Launchbury, Arwyn <Arw...@nc...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Thanks Tomas, That is definitely worth considering, and I will look into this a bit. I have run the stress test for single threads and for multiple threads and the newer EJBCA 7 was much quicker in multi thread and slightly quicker in single thread so I think we can confirm that EJBCA and cesecore server side are not at fault. This does mean that something is slower either in the client or with remote EJB commands. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 12 November 2021 09:56 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Great findings Arwyn, One thing perhaps that you may consider is to use the WS API, where clientToolBox has a CLI. You can perform the three commands you list using the local CLI with a single WS/WS CLI command if using a CSR: ./ejbcaClientToolBox.sh EjbcaWsRaCli certreq Or multiple commands as well if issuing keystores (pkcs12), with your "own" WS client you can do other things as well. The WS API may be faster if it's the CLI remote EJB commands that are slower in newer WildFly. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 3:43 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I currently do not believe the slow down is caused by the EJBCA or cesecore server side. I turned on trace logging for only ejbca and cesecore loggers on the server side. All of these log messages appeared within 0.75 seconds of each other for EJBCA6 and within 0.85 seconds of each other for EJBCA7. This means I don't think there has been a significant change to the server side performance of EJBCA or cesecore logic. When running a bin/ejbca.sh command I have observed the client ejbca.sh JVM startup time to be very similar in both versions of EJBCA, at around 1 second. In the case of EJBCA 6, the EJBCA and cesecore log messages show up ~ 0.5 seconds after the JVM has fully started up. In the case of EJBCA 7 the EJBCA and cesecore log messages show up ~ 1.7 seconds after the JVM has started up. This makes me think that either the client is slower by ~1.2 seconds in the new version, or there is some slow down in wildfly and the EJBRemoteInvocation. This gives the total time for one ejbca.sh command to go from ~2.25 seconds in EJBCA 6 to ~3.55, with most of this difference coming from the change in the client. (I believe changing the logging levels have had a slight effect on the performance, which is why these values are different to my original comment). Over a typical certificate renewal I would call the ejbca.sh command three separate times. The three commands I run would be bin/ejbca.sh ra setendentitystatus --username " user.name" -S 10 bin/ejbca.sh ra setpwd --username "user.name" --password "password" bin/ejbca.sh createcert --username "user.name" -password "password" -c "/tmp/tmp_csr" -f "/opt/ejbca/p12/pem/user.name.pem" As the server typically takes less than a second to respond, the change to the client performance is resulting in this process taking between 1.5 and 2 times longer than previously. I've been having some trouble running the stress test tool but I will try to get results from that to confirm the client is the issue. You mention that the stress test tool is able to run without having to restart the JVM. This leads me to thinking that it may be possible to follow the same pattern when running my certificate renewal. Is it possible to run multiple bin/ejbca.sh commands without restarting the JVM? If the JVM is reused, it may mean that the slow down in the client that I have observed would not have such a large effect over a typical workflow. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 11 November 2021 09:39 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Can you rule out that it is anything on the client side that is slow? For performance measurement of EJBCA itself, we typically run a "clientToolBox stress" which is a nice stress test tool that runs multiple threads in a single client JVM, avoiding any JVM loading issues, and showing certificate issuance speed. You can test single threaded performance (measure latency) and multi-threaded performance measuring throughput. This tool has been available since EJBCA 4 and can be used throughout the times. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/command-line-interfaces/ejbca-client-toolbox<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-operations-guide*2Fcommand-line-interfaces*2Fejbca-client-toolbox__*3B!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7Le8vlvqY*24&data=04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517929729*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=hMGyL86zCgiRbfNy7DfbfLpBZp*2BtS4l0onx6OIW*2Fd*2F4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm27Z-oghY$> Cheers, Tomas ________________________________ From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: Thursday, November 11, 2021 10:26 AM To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Sorry, I didn't mean trace logging for all of WildFly, I was thinking about trace logging for EJBCA. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/logging#Logging-DebugLogging<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-ca-concept-guide*2Flogging*Logging-DebugLogging__*3BIw!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7LGO9Rnhg*24&data=04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517939677*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=0*2B*2BJB08tVQoz8xR*2BCHSZYgDkxNb5ETwe4ksEP4NrwCg*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm2V_Lyhww$> Thousands of CAs sounds like a quite special use case. Not a very normal use case. For sure EJBCA 7 is running in production issuing hundreds of certificates per second, from dozens of CAs, but I haven't been digging around with thousands of CAs yet personally. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 9:59 AM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi Tomas, I have now enabled trace logging on the client side. I have seen the longest message is the following, which takes approximately 0.6 seconds. I have been unable to find a similar log message in the log of the EJBCA 6 client. TRACE [SecurityProviderSaslClientFactory] - Created SaslClient for mechanism JBOSS-LOCAL-USER, using Provider WildFlyElytron and protocol remote The above log message always occurs between the following two DEBUG log messages, which seems to be where most of the slow down is seen. 2021-11-08 14:16:52,865 DEBUG [DiscoveryEJBClientInterceptor] - DiscoveryEJBClientInterceptor: calling executeDiscovery(locator = StatelessEJBLocator for "ejbca/cesecore-ejb/GlobalConfigurationSessionBean", view is interface org.cesecore.configuration.GlobalConfigurationSessionRemote, affinity is None, weak affinity = None) 2021-11-08 14:16:53,298 DEBUG [DelegatingBasicLogger] - Received MODULE_AVAILABLE(8) message from node <host> for module ejbca/certstore Another log message that seems to be taking a while in the client log is the following. This takes approximately 0.3 seconds the first time it shows up, but is much faster on subsequent appearances inside the same ejbca.sh call. 2021-11-10 09:11:56,605 TRACE [AuthenticationContextConfigurationClient] - getAuthenticationConfiguration uri=http-remoting://localhost:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, MatchRule=[abstractType=ejb,abstractTypeAuthority=jboss,host=localhost,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-protocol=http-remoting,set-port=4447,providers-supplier=org.wildfly.security.provider.util.ProviderServiceLoaderSupplier@93e09b04,mechanism-properties={javax.security.sasl.policy.noanonymous=false, javax.security.sasl.policy.noplaintext=true, wildfly.sasl.local-user.quiet-auth=true}] I have been doing this upgrade testing on my system where I have 500 CAs configured. My system is only used for testing, as the production system would be at EJBCA 6 currently. I would expect there to be a few thousand CAs on the production system. Regards, Arwyn From: Tomas Gustavsson via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: 09 November 2021 08:53 To: ejb...@li...<mailto:ejb...@li...> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Have you enabled debug logging? That should show clearly if there is anything in EJBCA that takes time. Question: do you have 500 CAs configured? Is this a production use case? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Monday, November 8, 2021 6:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I think my previous message regarding the client may have been incorrect. In the EJBCA 7 case I'm getting a io.undertow.request log in the server log approximately 1s after calling ejbca.sh, which is when I think the client JVM has started up. However there is then an approximately 1 second gap before the first cesecore log shows up (org.cesecore.configuration.GlobalConfigurationSessionBean). During this time the server does not seem to be doing anything, but the client is. In the EJBCA 6 case the first server log appears approximately 1 second after the ejbca.sh command is called, but it then takes only ~0.3 seconds for the cesecore log to show up. So it looks like the client is now taking ~2 seconds to connect after the upgrade, vs the old client taking ~1.2 seconds. You mention a slow client has been observed before, is there a way of finding out the cause and finding a way to speed up the client startup? I have now checked all of the DB indexes in the doc/sql-scripts/create-index-ejbca.sql script. After putting all indexes in place it does not seem to have had an effect on the total time. I have tested this and observed the slow down for up to about 500 CAs. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 18:21 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 Sounds like you are missing a database index. Check the recommended database indexes. Do you have many CAs, and/or CA certificates? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Friday, November 5, 2021 7:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thank you for the response. Currently we believe the issue is server side. I have compared the time between the ejbca.sh cli command being called and messages appearing in the server.log. This time was the same for both EJBCA 6 and EJBCA 7. I have tried profiling the older version of EJBCA 6 to compare it to the results we found for EJBCA 7. The getCAInternal function was taking approximately 0.05 seconds on the old version, approximately 10 times quicker than in EJBCA 7. I could not find getCertificateProfile when running EJBCA 6. These are the only functions from the ejbca or cesecore packages that seemed to be taking a long time in EJBCA 7, and as there is such a large difference in these functions after the upgrade we think this could be the cause of the issues. Has there been any changes to the internal EJBCA caching from the upgrade? Is there any specific options that mean EJBCA does not cache certificates anymore? Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 08:25 To: ejb...@li...<mailto:ejb...@li...> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 *External Message* - Use caution before opening links or attachments If anything, the performance of EJBCA should be better not worse after an upgrade. Did you check recommended indexes to add new database indexes that should be there. There are some new ones that we recommend. See doc/sql-scripts for the recommended indexes. As you already checked slow queries though, it may or may not help anything. If it just startup of the cli command that takes time, or does every request take time if you for example run a stress test? I.e. identify if its the client or server that has slowdown. You can check the server.log to see when a request come in and how long it takes to process. We have seen cases where for various reasons the startup/init time of java on the client side takes time, i.e. not EJBCA that is slow but the start-up of the JVM for the CLI client side process. Regards, Tomas ________________________________ From: Launchbury, Arwyn via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: Thursday, November 4, 2021 6:17 PM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi, We are currently in the process of upgrading the version of EJBCA we use and have noticed a significant decrease in performance. Our previous installation used EJBCA version 6.3.1.1, jboss version 7.1.1, and opendk 7. We have tried to upgrade to EJBCA version 7.4.3.2, wildfly version 18.0.1, and openjdk 8. We have noticed that ejbca.sh commands take approximately twice as long after the upgrade, for example ./ejbca.sh ra setendentitystatus went from ~1.5 seconds before the upgrade to ~3 seconds after the upgrade, and .ejbca.sh createcert went from ~2 seconds to ~4 seconds. We have tried some of the options in the PerformanceTuning (https://doc.primekey.com/ejbca743/ejbca-installation/application-servers/wildfly-18-jboss-eap-7-3#WildFly18/JBossEAP7.3-PerformanceTuning<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdoc.primekey.com*2Fejbca743*2Fejbca-installation*2Fapplication-servers*2Fwildfly-18-jboss-eap-7-3*23WildFly18*2FJBossEAP7.3-PerformanceTuning*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cb5562e5e7ab14034f90808d99fba0f08*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637716444467209936*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DeKHxGCeaet56ecbgaoxt6WzH4*2F*2FLzB9Zw7T*2Ft5eYBEQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!In4Qlw!6ZvD7OSOz-ZOVXXibdUGr8TXgIluCtaXVSPBS0iknh_KKTh-trtTeYreMBdyiA9e9GI*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cd1ea972107fb4d26293a08d9a0882a3e*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637717328989428655*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DBEAkcfNI7HxZ5iFmsFpWTfvJRTVqjZAtgUL1TF2nlvI*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKiUlKioqKioqKioqKioqJSUqKioqJSUlJSUlJSUlJSUlJSUlJSU!!In4Qlw!_2cNsYkEMpPutSXEorm2ptooFtWhc5Jm_SZI6aA_0-guiyQ8dkI9smRCjrBx1rbvaWU*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Ce351c5fc7ff64a58a4e408d9a2db3098*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637719884629212861*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DzQOUT2OHUnYk3*2FkG33oixtRpI*2BXE6*2Bjxw5rYv32X8O4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!8-KVx3UAT0IxCIX12v4XCzVWZ8GHzkq_jDBw5LrqWPF1ZcRlbItU0ZJmT4tM4IUl8eU*24>) section of the documentation, which has had no significant effect on the performance. We have tried profiling the EJBCA process, but have not yet found anything that is obviously causing the performance issues. Currently we have seen that both Lorg/cesecore/certificates/certificateprofile/CertificateProfileSessionBean:::getCertificateProfile and Lorg/cesecore/certificates/ca/CaSessionBean:::getCAInternal take approximately 0.5 seconds each during a setendentitystatus run. These seem to be taking a long time but we're not sure if they are the actual cause of the performance issues. We currently don't believe the MySQL DB is the cause of the performance issues as there were no entries in the Slow Query Log for any time greater than 50ms. Does anyone have any suggestions on how we could improve the performance of our installation, or how we would find the source of the performance issues? Kind Regards, Arwyn |
From: Launchbury, A. <Arw...@nc...> - 2021-11-17 16:46:17
|
Thanks Tomas, That is definitely worth considering, and I will look into this a bit. I have run the stress test for single threads and for multiple threads and the newer EJBCA 7 was much quicker in multi thread and slightly quicker in single thread so I think we can confirm that EJBCA and cesecore server side are not at fault. This does mean that something is slower either in the client or with remote EJB commands. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...> Sent: 12 November 2021 09:56 To: Launchbury, Arwyn <Arw...@nc...>; ejb...@li... Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Great findings Arwyn, One thing perhaps that you may consider is to use the WS API, where clientToolBox has a CLI. You can perform the three commands you list using the local CLI with a single WS/WS CLI command if using a CSR: ./ejbcaClientToolBox.sh EjbcaWsRaCli certreq Or multiple commands as well if issuing keystores (pkcs12), with your "own" WS client you can do other things as well. The WS API may be faster if it's the CLI remote EJB commands that are slower in newer WildFly. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 3:43 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I currently do not believe the slow down is caused by the EJBCA or cesecore server side. I turned on trace logging for only ejbca and cesecore loggers on the server side. All of these log messages appeared within 0.75 seconds of each other for EJBCA6 and within 0.85 seconds of each other for EJBCA7. This means I don't think there has been a significant change to the server side performance of EJBCA or cesecore logic. When running a bin/ejbca.sh command I have observed the client ejbca.sh JVM startup time to be very similar in both versions of EJBCA, at around 1 second. In the case of EJBCA 6, the EJBCA and cesecore log messages show up ~ 0.5 seconds after the JVM has fully started up. In the case of EJBCA 7 the EJBCA and cesecore log messages show up ~ 1.7 seconds after the JVM has started up. This makes me think that either the client is slower by ~1.2 seconds in the new version, or there is some slow down in wildfly and the EJBRemoteInvocation. This gives the total time for one ejbca.sh command to go from ~2.25 seconds in EJBCA 6 to ~3.55, with most of this difference coming from the change in the client. (I believe changing the logging levels have had a slight effect on the performance, which is why these values are different to my original comment). Over a typical certificate renewal I would call the ejbca.sh command three separate times. The three commands I run would be bin/ejbca.sh ra setendentitystatus --username " user.name" -S 10 bin/ejbca.sh ra setpwd --username "user.name" --password "password" bin/ejbca.sh createcert --username "user.name" -password "password" -c "/tmp/tmp_csr" -f "/opt/ejbca/p12/pem/user.name.pem" As the server typically takes less than a second to respond, the change to the client performance is resulting in this process taking between 1.5 and 2 times longer than previously. I've been having some trouble running the stress test tool but I will try to get results from that to confirm the client is the issue. You mention that the stress test tool is able to run without having to restart the JVM. This leads me to thinking that it may be possible to follow the same pattern when running my certificate renewal. Is it possible to run multiple bin/ejbca.sh commands without restarting the JVM? If the JVM is reused, it may mean that the slow down in the client that I have observed would not have such a large effect over a typical workflow. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 11 November 2021 09:39 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Can you rule out that it is anything on the client side that is slow? For performance measurement of EJBCA itself, we typically run a "clientToolBox stress" which is a nice stress test tool that runs multiple threads in a single client JVM, avoiding any JVM loading issues, and showing certificate issuance speed. You can test single threaded performance (measure latency) and multi-threaded performance measuring throughput. This tool has been available since EJBCA 4 and can be used throughout the times. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/command-line-interfaces/ejbca-client-toolbox<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-operations-guide*2Fcommand-line-interfaces*2Fejbca-client-toolbox__*3B!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7Le8vlvqY*24&data=04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517929729*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=hMGyL86zCgiRbfNy7DfbfLpBZp*2BtS4l0onx6OIW*2Fd*2F4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm27Z-oghY$> Cheers, Tomas ________________________________ From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: Thursday, November 11, 2021 10:26 AM To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Sorry, I didn't mean trace logging for all of WildFly, I was thinking about trace logging for EJBCA. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/logging#Logging-DebugLogging<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdoc.primekey.com*2Fejbca*2Fejbca-operations*2Fejbca-ca-concept-guide*2Flogging*Logging-DebugLogging__*3BIw!!In4Qlw!8nNxnuGaxSyzwunRmKOIxMC8KZxIMaueNRWOVicq6Xa0vGl-oyFya0kknO7LGO9Rnhg*24&data=04*7C01*7Ctomas.gustavsson*40primekey.com*7C99b31a6ee64c405a7c0608d9a521b651*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637722386517939677*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=0*2B*2BJB08tVQoz8xR*2BCHSZYgDkxNb5ETwe4ksEP4NrwCg*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!84kFMzmODICRf-xtXXZQyO9KAjrjsTeIMgJbP1LCqLzmYVZcOtWO6XUdwGm2V_Lyhww$> Thousands of CAs sounds like a quite special use case. Not a very normal use case. For sure EJBCA 7 is running in production issuing hundreds of certificates per second, from dozens of CAs, but I haven't been digging around with thousands of CAs yet personally. Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Thursday, November 11, 2021 9:59 AM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi Tomas, I have now enabled trace logging on the client side. I have seen the longest message is the following, which takes approximately 0.6 seconds. I have been unable to find a similar log message in the log of the EJBCA 6 client. TRACE [SecurityProviderSaslClientFactory] - Created SaslClient for mechanism JBOSS-LOCAL-USER, using Provider WildFlyElytron and protocol remote The above log message always occurs between the following two DEBUG log messages, which seems to be where most of the slow down is seen. 2021-11-08 14:16:52,865 DEBUG [DiscoveryEJBClientInterceptor] - DiscoveryEJBClientInterceptor: calling executeDiscovery(locator = StatelessEJBLocator for "ejbca/cesecore-ejb/GlobalConfigurationSessionBean", view is interface org.cesecore.configuration.GlobalConfigurationSessionRemote, affinity is None, weak affinity = None) 2021-11-08 14:16:53,298 DEBUG [DelegatingBasicLogger] - Received MODULE_AVAILABLE(8) message from node <host> for module ejbca/certstore Another log message that seems to be taking a while in the client log is the following. This takes approximately 0.3 seconds the first time it shows up, but is much faster on subsequent appearances inside the same ejbca.sh call. 2021-11-10 09:11:56,605 TRACE [AuthenticationContextConfigurationClient] - getAuthenticationConfiguration uri=http-remoting://localhost:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, MatchRule=[abstractType=ejb,abstractTypeAuthority=jboss,host=localhost,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost,set-protocol=http-remoting,set-port=4447,providers-supplier=org.wildfly.security.provider.util.ProviderServiceLoaderSupplier@93e09b04,mechanism-properties={javax.security.sasl.policy.noanonymous=false, javax.security.sasl.policy.noplaintext=true, wildfly.sasl.local-user.quiet-auth=true}] I have been doing this upgrade testing on my system where I have 500 CAs configured. My system is only used for testing, as the production system would be at EJBCA 6 currently. I would expect there to be a few thousand CAs on the production system. Regards, Arwyn From: Tomas Gustavsson via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: 09 November 2021 08:53 To: ejb...@li...<mailto:ejb...@li...> Cc: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: Re: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 Have you enabled debug logging? That should show clearly if there is anything in EJBCA that takes time. Question: do you have 500 CAs configured? Is this a production use case? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Monday, November 8, 2021 6:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>>; ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thanks Tomas, I think my previous message regarding the client may have been incorrect. In the EJBCA 7 case I'm getting a io.undertow.request log in the server log approximately 1s after calling ejbca.sh, which is when I think the client JVM has started up. However there is then an approximately 1 second gap before the first cesecore log shows up (org.cesecore.configuration.GlobalConfigurationSessionBean). During this time the server does not seem to be doing anything, but the client is. In the EJBCA 6 case the first server log appears approximately 1 second after the ejbca.sh command is called, but it then takes only ~0.3 seconds for the cesecore log to show up. So it looks like the client is now taking ~2 seconds to connect after the upgrade, vs the old client taking ~1.2 seconds. You mention a slow client has been observed before, is there a way of finding out the cause and finding a way to speed up the client startup? I have now checked all of the DB indexes in the doc/sql-scripts/create-index-ejbca.sql script. After putting all indexes in place it does not seem to have had an effect on the total time. I have tested this and observed the slow down for up to about 500 CAs. Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 18:21 To: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 Sounds like you are missing a database index. Check the recommended database indexes. Do you have many CAs, and/or CA certificates? Cheers, Tomas ________________________________ From: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Sent: Friday, November 5, 2021 7:14 PM To: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Subject: RE: Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Thank you for the response. Currently we believe the issue is server side. I have compared the time between the ejbca.sh cli command being called and messages appearing in the server.log. This time was the same for both EJBCA 6 and EJBCA 7. I have tried profiling the older version of EJBCA 6 to compare it to the results we found for EJBCA 7. The getCAInternal function was taking approximately 0.05 seconds on the old version, approximately 10 times quicker than in EJBCA 7. I could not find getCertificateProfile when running EJBCA 6. These are the only functions from the ejbca or cesecore packages that seemed to be taking a long time in EJBCA 7, and as there is such a large difference in these functions after the upgrade we think this could be the cause of the issues. Has there been any changes to the internal EJBCA caching from the upgrade? Is there any specific options that mean EJBCA does not cache certificates anymore? Regards, Arwyn From: Tomas Gustavsson <tom...@pr...<mailto:tom...@pr...>> Sent: 05 November 2021 08:25 To: ejb...@li...<mailto:ejb...@li...> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: Re: Decreased Performance after upgrade to EJBCA Version 7 *External Message* - Use caution before opening links or attachments If anything, the performance of EJBCA should be better not worse after an upgrade. Did you check recommended indexes to add new database indexes that should be there. There are some new ones that we recommend. See doc/sql-scripts for the recommended indexes. As you already checked slow queries though, it may or may not help anything. If it just startup of the cli command that takes time, or does every request take time if you for example run a stress test? I.e. identify if its the client or server that has slowdown. You can check the server.log to see when a request come in and how long it takes to process. We have seen cases where for various reasons the startup/init time of java on the client side takes time, i.e. not EJBCA that is slow but the start-up of the JVM for the CLI client side process. Regards, Tomas ________________________________ From: Launchbury, Arwyn via Ejbca-develop <ejb...@li...<mailto:ejb...@li...>> Sent: Thursday, November 4, 2021 6:17 PM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Cc: Launchbury, Arwyn <Arw...@nc...<mailto:Arw...@nc...>> Subject: [Ejbca-develop] Decreased Performance after upgrade to EJBCA Version 7 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Hi, We are currently in the process of upgrading the version of EJBCA we use and have noticed a significant decrease in performance. Our previous installation used EJBCA version 6.3.1.1, jboss version 7.1.1, and opendk 7. We have tried to upgrade to EJBCA version 7.4.3.2, wildfly version 18.0.1, and openjdk 8. We have noticed that ejbca.sh commands take approximately twice as long after the upgrade, for example ./ejbca.sh ra setendentitystatus went from ~1.5 seconds before the upgrade to ~3 seconds after the upgrade, and .ejbca.sh createcert went from ~2 seconds to ~4 seconds. We have tried some of the options in the PerformanceTuning (https://doc.primekey.com/ejbca743/ejbca-installation/application-servers/wildfly-18-jboss-eap-7-3#WildFly18/JBossEAP7.3-PerformanceTuning<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdoc.primekey.com*2Fejbca743*2Fejbca-installation*2Fapplication-servers*2Fwildfly-18-jboss-eap-7-3*23WildFly18*2FJBossEAP7.3-PerformanceTuning*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cb5562e5e7ab14034f90808d99fba0f08*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637716444467209936*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DeKHxGCeaet56ecbgaoxt6WzH4*2F*2FLzB9Zw7T*2Ft5eYBEQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!In4Qlw!6ZvD7OSOz-ZOVXXibdUGr8TXgIluCtaXVSPBS0iknh_KKTh-trtTeYreMBdyiA9e9GI*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Cd1ea972107fb4d26293a08d9a0882a3e*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637717328989428655*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DBEAkcfNI7HxZ5iFmsFpWTfvJRTVqjZAtgUL1TF2nlvI*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKiUlKioqKioqKioqKioqJSUqKioqJSUlJSUlJSUlJSUlJSUlJSU!!In4Qlw!_2cNsYkEMpPutSXEorm2ptooFtWhc5Jm_SZI6aA_0-guiyQ8dkI9smRCjrBx1rbvaWU*24*26data*3D04*7C01*7Ctomas.gustavsson*40primekey.com*7Ce351c5fc7ff64a58a4e408d9a2db3098*7Cc9ed4b459f70418aaa58f04c80848ca9*7C0*7C0*7C637719884629212861*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DzQOUT2OHUnYk3*2FkG33oixtRpI*2BXE6*2Bjxw5rYv32X8O4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUl!!In4Qlw!8-KVx3UAT0IxCIX12v4XCzVWZ8GHzkq_jDBw5LrqWPF1ZcRlbItU0ZJmT4tM4IUl8eU*24>) section of the documentation, which has had no significant effect on the performance. We have tried profiling the EJBCA process, but have not yet found anything that is obviously causing the performance issues. Currently we have seen that both Lorg/cesecore/certificates/certificateprofile/CertificateProfileSessionBean:::getCertificateProfile and Lorg/cesecore/certificates/ca/CaSessionBean:::getCAInternal take approximately 0.5 seconds each during a setendentitystatus run. These seem to be taking a long time but we're not sure if they are the actual cause of the performance issues. We currently don't believe the MySQL DB is the cause of the performance issues as there were no entries in the Slow Query Log for any time greater than 50ms. Does anyone have any suggestions on how we could improve the performance of our installation, or how we would find the source of the performance issues? Kind Regards, Arwyn |
From: Moser B. <B....@co...> - 2021-11-15 15:04:07
|
Hi Tomas, Thank you for clarification and for the bug report. Anyway the option with "force local key generation" will not work for us, because our existing productive CA has ECC keys for signing and the defaultKey has not been defined. This is why we wanted to use another Cryto Token with an new RSA key for Key recovery. If I do understand your response, then there is not a solution for our problem. Right? With best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> www.commend.com<http://www.commend.com/> Security and Communication by Commend FN 178618z / LG Salzburg Von: Tomas Gustavsson via Ejbca-develop <ejb...@li...> Gesendet: Montag, 15. November 2021 09:43 An: ejb...@li... Cc: Tomas Gustavsson <tom...@pr...> Betreff: [External] Re: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, There is probably a misunderstanding of what the option "Force local key generation" means. This is an option that is solely used for when you have an External RA connected over Peers with the CA. This enables you to have a central CA, but a RA that is local to another organization (or department) and forcing key generation to happen, and recovery data to be stored, locally on the RA. Say for extra secretive departments that don't want the CA to keep their keys. the External RA using Peers is an "Enterprise only" feature and thus not available. The option should have been hidden in Community, this was an oversight. I created this issue: https://jira.primekey.se/browse/ECA-10401<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.primekey.se%2Fbrowse%2FECA-10401&data=04%7C01%7Cb.moser%40commend.com%7C4149e3eb286f45a3247a08d9a818ce99%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637725646775423063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZuSDVSZrWRXcKobkvU41JBHt3scU2BlyP%2FPrTYZZ4z4%3D&reserved=0> Just run key recovery without the option enabled and it should work as expected, with key recovery data stored in, and recoverable from, the CA. Regards, Tomas ________________________________ From: Moser Benjamin <B....@co...<mailto:B....@co...>> Sent: Friday, November 12, 2021 12:28 PM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Dear community users, We are struggling with the Key Recovery bug found in EJBCA Community Edition v6.10.1.2. We enabled "Force local key generation" in the "System Configuration -> Basic Configuration". We created an extra Crypto Token with a RSA key pair, because our CAs use ECC key pairs which cannot be used for key encryption. We add a new EE user with "Key Recovery" enabled. 1) When we try to enroll the user on RA Web with username and code we see a NullPointerException. In the server logs we find an AuthorizationDeniedException and the NullPointerException. 2021-11-12 10:53:28,809 DEBUG [org.ejbca.core.model.era.RaMasterApiProxyBean] (default task-31) Creating locally stored key pair for end entity 'keyrecovery-test-user' 2021-11-12 10:53:28,810 ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component RaMasterApiProxyBean for method public abstract byte[] org.ejbca.core.model.era.RaMasterApi.generateKeyStore(org.cesecore.authentication.tokens.AuthenticationToken,org.cesecore.certificates.endentity.EndEntityInformation) throws org.cesecore.authorization.AuthorizationDeniedException,org.ejbca.core.EjbcaException: javax.ejb.EJBException: java.lang.NullPointerException 2) When we try to enroll the user on Public Web with username and code we see that a key stores has been created. In the server logs we find an NoSuchAlgorithmException and cannot find provider supporting 1.2.840.10045.2.1. This is caused by selecting the wrong Crypto Token from Test issuing CA that only supports an ECC signkey. 2021-11-11 21:43:23,521 DEBUG [org.ejbca.core.ejb.ra.KeyStoreCreateSessionBean] (default task-2) Saving generated keys for recovery for user: keyrecovery-test-user 2021-11-11 21:43:23,521 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;172.31.31.132;;;;resource0=/ca/2073369223 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (default task-2) Extended service with request class 'org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAServiceRequest' called for CA ' Test Issuing CA' 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService] (default task-2) Encrypting using alias 'signKey' from crypto token 1955349239 2021-11-11 21:43:23,530 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;KEYRECOVERY_ADDDATA;FAILURE;KEYRECOVERY;EJBCA;172.31.31.132;2073369223;5C9F72ACC846D322;keyrecovery-test-useryyyy;msg=Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International. 2021-11-11 21:43:23,534 ERROR [org.ejbca.core.ejb.keyrecovery.KeyRecoverySessionBean] (default task-2) Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International.: org.cesecore.certificates.ca.extendedservices.IllegalExtendedCAServiceRequestException: java.lang.IllegalStateException: Failed to encrypt keys: exception wrapping content key: cannot create cipher: Cannot find any provider supporting 1.2.840.10045.2.1 at org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService.extendedService(KeyRecoveryCAService.java:126) at org.cesecore.certificates.ca.CA.extendedService(CA.java:1133) at org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean.extendedService(CAAdminSessionBean.java:3260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting 1.2.840.10045.2.1 at javax.crypto.Cipher.getInstance(Cipher.java:539) at org.bouncycastle.jcajce.util.DefaultJcaJceHelper.createCipher(Unknown Source) ... 257 more Use Case: We need to enable key recovery for ECC signing certificates that are used for secure boot on long-running embedded devices. The keyEncryptKey is immutable on existing CAs, hence we enabled the "Force local key generation" with a new Crypto Token. This seems to be two bug, which were neither raised nor fixed until now: ad 1) RA Web cannot be used to enroll a user with key recovery enabled Ad 2) Public Web always uses CA Crypto Token to enroll a user with key recovery enabled Your feed is appreciated and with best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JHkBxj3sCboTlvP2UOIYo6y1iuY34dqOOipJ8fWDgEs%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Cb.moser%40commend.com%7C4149e3eb286f45a3247a08d9a818ce99%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637725646775433055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MeLs0U7BAnjjw4vmaRy57I4JuKxPYBN5UcHC8Xui%2Bfs%3D&reserved=0> Security and Communication by Commend FN 178618z / LG Salzburg _______________________________________________ Ejbca-develop mailing list Ejb...@li...<mailto:Ejb...@li...> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZMiBEjl7vp6MliCb9kVwIxcNRwlGVtiajOohf3tG%2Beo%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Cb.moser%40commend.com%7C4149e3eb286f45a3247a08d9a818ce99%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637725646775433055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xNjZKRd41U6XgH13JHPITLhh%2FoCkD9pZ6mof4wHF4aU%3D&reserved=0> |
From: Tomas G. <tom...@pr...> - 2021-11-15 14:54:00
|
Correct, you can't specify a separate crypto token for that. What you can easily do is to generate a RSA key in your CAs crypto token and configure the keyEncrypt key in the CA. The keyEncrypt key will then be used to encrypt key recovery data. Setting the keyEncrypt key is not possible in the Web UI after CA creation, I know that, but there is a CLI command specifically for this ??. Cheers, Tomas ________________________________ From: Moser Benjamin <B....@co...> Sent: Monday, November 15, 2021 3:31 PM To: ejb...@li... <ejb...@li...> Cc: Tomas Gustavsson <tom...@pr...> Subject: AW: [External] Re: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Hi Tomas, Thank you for clarification and for the bug report. Anyway the option with “force local key generation” will not work for us, because our existing productive CA has ECC keys for signing and the defaultKey has not been defined. This is why we wanted to use another Cryto Token with an new RSA key for Key recovery. If I do understand your response, then there is not a solution for our problem. Right? With best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> www.commend.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C342a285c639c41b21de708d9a844a11d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637725836121578971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FcEsxOZ5E%2BfvtmmGCQ5yKbGxdJaGXZwchsB%2BUJW%2Fd10%3D&reserved=0> Security and Communication by Commend FN 178618z / LG Salzburg Von: Tomas Gustavsson via Ejbca-develop <ejb...@li...> Gesendet: Montag, 15. November 2021 09:43 An: ejb...@li... Cc: Tomas Gustavsson <tom...@pr...> Betreff: [External] Re: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, There is probably a misunderstanding of what the option "Force local key generation" means. This is an option that is solely used for when you have an External RA connected over Peers with the CA. This enables you to have a central CA, but a RA that is local to another organization (or department) and forcing key generation to happen, and recovery data to be stored, locally on the RA. Say for extra secretive departments that don't want the CA to keep their keys. the External RA using Peers is an "Enterprise only" feature and thus not available. The option should have been hidden in Community, this was an oversight. I created this issue: https://jira.primekey.se/browse/ECA-10401<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.primekey.se%2Fbrowse%2FECA-10401&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C342a285c639c41b21de708d9a844a11d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637725836121578971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pnNO9phgtnGXbxqXHkhlHrxtSYOCwZioRar9y8sHeSg%3D&reserved=0> Just run key recovery without the option enabled and it should work as expected, with key recovery data stored in, and recoverable from, the CA. Regards, Tomas ________________________________ From: Moser Benjamin <B....@co...<mailto:B....@co...>> Sent: Friday, November 12, 2021 12:28 PM To: ejb...@li...<mailto:ejb...@li...> <ejb...@li...<mailto:ejb...@li...>> Subject: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke...<mailto:In...@ke...> with any questions. Dear community users, We are struggling with the Key Recovery bug found in EJBCA Community Edition v6.10.1.2. We enabled "Force local key generation" in the "System Configuration -> Basic Configuration". We created an extra Crypto Token with a RSA key pair, because our CAs use ECC key pairs which cannot be used for key encryption. We add a new EE user with "Key Recovery" enabled. 1) When we try to enroll the user on RA Web with username and code we see a NullPointerException. In the server logs we find an AuthorizationDeniedException and the NullPointerException. 2021-11-12 10:53:28,809 DEBUG [org.ejbca.core.model.era.RaMasterApiProxyBean] (default task-31) Creating locally stored key pair for end entity 'keyrecovery-test-user' 2021-11-12 10:53:28,810 ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component RaMasterApiProxyBean for method public abstract byte[] org.ejbca.core.model.era.RaMasterApi.generateKeyStore(org.cesecore.authentication.tokens.AuthenticationToken,org.cesecore.certificates.endentity.EndEntityInformation) throws org.cesecore.authorization.AuthorizationDeniedException,org.ejbca.core.EjbcaException: javax.ejb.EJBException: java.lang.NullPointerException 2) When we try to enroll the user on Public Web with username and code we see that a key stores has been created. In the server logs we find an NoSuchAlgorithmException and cannot find provider supporting 1.2.840.10045.2.1. This is caused by selecting the wrong Crypto Token from Test issuing CA that only supports an ECC signkey. 2021-11-11 21:43:23,521 DEBUG [org.ejbca.core.ejb.ra.KeyStoreCreateSessionBean] (default task-2) Saving generated keys for recovery for user: keyrecovery-test-user 2021-11-11 21:43:23,521 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;172.31.31.132;;;;resource0=/ca/2073369223 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (default task-2) Extended service with request class 'org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAServiceRequest' called for CA ' Test Issuing CA' 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService] (default task-2) Encrypting using alias 'signKey' from crypto token 1955349239 2021-11-11 21:43:23,530 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;KEYRECOVERY_ADDDATA;FAILURE;KEYRECOVERY;EJBCA;172.31.31.132;2073369223;5C9F72ACC846D322;keyrecovery-test-useryyyy;msg=Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International. 2021-11-11 21:43:23,534 ERROR [org.ejbca.core.ejb.keyrecovery.KeyRecoverySessionBean] (default task-2) Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International.: org.cesecore.certificates.ca.extendedservices.IllegalExtendedCAServiceRequestException: java.lang.IllegalStateException: Failed to encrypt keys: exception wrapping content key: cannot create cipher: Cannot find any provider supporting 1.2.840.10045.2.1 at org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService.extendedService(KeyRecoveryCAService.java:126) at org.cesecore.certificates.ca.CA.extendedService(CA.java:1133) at org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean.extendedService(CAAdminSessionBean.java:3260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting 1.2.840.10045.2.1 at javax.crypto.Cipher.getInstance(Cipher.java:539) at org.bouncycastle.jcajce.util.DefaultJcaJceHelper.createCipher(Unknown Source) ... 257 more Use Case: We need to enable key recovery for ECC signing certificates that are used for secure boot on long-running embedded devices. The keyEncryptKey is immutable on existing CAs, hence we enabled the "Force local key generation" with a new Crypto Token. This seems to be two bug, which were neither raised nor fixed until now: ad 1) RA Web cannot be used to enroll a user with key recovery enabled Ad 2) Public Web always uses CA Crypto Token to enroll a user with key recovery enabled Your feed is appreciated and with best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co...<mailto:b....@co...> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JHkBxj3sCboTlvP2UOIYo6y1iuY34dqOOipJ8fWDgEs%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C342a285c639c41b21de708d9a844a11d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637725836121588924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NylY9WbnTAjaAWKXgp3u9UiQNKBClh7pQWLH0uBz%2Bq0%3D&reserved=0> Security and Communication by Commend FN 178618z / LG Salzburg _______________________________________________ Ejbca-develop mailing list Ejb...@li...<mailto:Ejb...@li...> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZMiBEjl7vp6MliCb9kVwIxcNRwlGVtiajOohf3tG%2Beo%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C342a285c639c41b21de708d9a844a11d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637725836121588924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6cUuYWFbrgIrwCVLk9QVMATDG1GOSxi%2B9upddRk4Lek%3D&reserved=0> |
From: Tomas G. <tom...@pr...> - 2021-11-15 09:17:11
|
Hi, There is probably a misunderstanding of what the option "Force local key generation" means. This is an option that is solely used for when you have an External RA connected over Peers with the CA. This enables you to have a central CA, but a RA that is local to another organization (or department) and forcing key generation to happen, and recovery data to be stored, locally on the RA. Say for extra secretive departments that don't want the CA to keep their keys. the External RA using Peers is an "Enterprise only" feature and thus not available. The option should have been hidden in Community, this was an oversight. I created this issue: https://jira.primekey.se/browse/ECA-10401 Just run key recovery without the option enabled and it should work as expected, with key recovery data stored in, and recoverable from, the CA. Regards, Tomas ________________________________ From: Moser Benjamin <B....@co...> Sent: Friday, November 12, 2021 12:28 PM To: ejb...@li... <ejb...@li...> Subject: [Ejbca-develop] Key recovery with force local key generation doesn't work in EJBCA Community Edition CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email In...@ke... with any questions. Dear community users, We are struggling with the Key Recovery bug found in EJBCA Community Edition v6.10.1.2. We enabled "Force local key generation" in the "System Configuration -> Basic Configuration". We created an extra Crypto Token with a RSA key pair, because our CAs use ECC key pairs which cannot be used for key encryption. We add a new EE user with "Key Recovery" enabled. 1) When we try to enroll the user on RA Web with username and code we see a NullPointerException. In the server logs we find an AuthorizationDeniedException and the NullPointerException. 2021-11-12 10:53:28,809 DEBUG [org.ejbca.core.model.era.RaMasterApiProxyBean] (default task-31) Creating locally stored key pair for end entity 'keyrecovery-test-user' 2021-11-12 10:53:28,810 ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component RaMasterApiProxyBean for method public abstract byte[] org.ejbca.core.model.era.RaMasterApi.generateKeyStore(org.cesecore.authentication.tokens.AuthenticationToken,org.cesecore.certificates.endentity.EndEntityInformation) throws org.cesecore.authorization.AuthorizationDeniedException,org.ejbca.core.EjbcaException: javax.ejb.EJBException: java.lang.NullPointerException 2) When we try to enroll the user on Public Web with username and code we see that a key stores has been created. In the server logs we find an NoSuchAlgorithmException and cannot find provider supporting 1.2.840.10045.2.1. This is caused by selecting the wrong Crypto Token from Test issuing CA that only supports an ECC signkey. 2021-11-11 21:43:23,521 DEBUG [org.ejbca.core.ejb.ra.KeyStoreCreateSessionBean] (default task-2) Saving generated keys for recovery for user: keyrecovery-test-user 2021-11-11 21:43:23,521 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;172.31.31.132;;;;resource0=/ca/2073369223 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (default task-2) Extended service with request class 'org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAServiceRequest' called for CA ' Test Issuing CA' 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService] (default task-2) Encrypting using alias 'signKey' from crypto token 1955349239 2021-11-11 21:43:23,530 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;KEYRECOVERY_ADDDATA;FAILURE;KEYRECOVERY;EJBCA;172.31.31.132;2073369223;5C9F72ACC846D322;keyrecovery-test-useryyyy;msg=Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International. 2021-11-11 21:43:23,534 ERROR [org.ejbca.core.ejb.keyrecovery.KeyRecoverySessionBean] (default task-2) Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International.: org.cesecore.certificates.ca.extendedservices.IllegalExtendedCAServiceRequestException: java.lang.IllegalStateException: Failed to encrypt keys: exception wrapping content key: cannot create cipher: Cannot find any provider supporting 1.2.840.10045.2.1 at org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService.extendedService(KeyRecoveryCAService.java:126) at org.cesecore.certificates.ca.CA.extendedService(CA.java:1133) at org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean.extendedService(CAAdminSessionBean.java:3260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting 1.2.840.10045.2.1 at javax.crypto.Cipher.getInstance(Cipher.java:539) at org.bouncycastle.jcajce.util.DefaultJcaJceHelper.createCipher(Unknown Source) ... 257 more Use Case: We need to enable key recovery for ECC signing certificates that are used for secure boot on long-running embedded devices. The keyEncryptKey is immutable on existing CAs, hence we enabled the "Force local key generation" with a new Crypto Token. This seems to be two bug, which were neither raised nor fixed until now: ad 1) RA Web cannot be used to enroll a user with key recovery enabled Ad 2) Public Web always uses CA Crypto Token to enroll a user with key recovery enabled Your feed is appreciated and with best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co... https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.commend.com%2F&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JHkBxj3sCboTlvP2UOIYo6y1iuY34dqOOipJ8fWDgEs%3D&reserved=0 Security and Communication by Commend FN 178618z / LG Salzburg _______________________________________________ Ejbca-develop mailing list Ejb...@li... https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C877a191ce34f45494f1008d9a5e53284%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637723226939382190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZMiBEjl7vp6MliCb9kVwIxcNRwlGVtiajOohf3tG%2Beo%3D&reserved=0 |
From: Moser B. <B....@co...> - 2021-11-12 14:01:59
|
Dear community users, We are struggling with the Key Recovery bug found in EJBCA Community Edition v6.10.1.2. We enabled "Force local key generation" in the "System Configuration -> Basic Configuration". We created an extra Crypto Token with a RSA key pair, because our CAs use ECC key pairs which cannot be used for key encryption. We add a new EE user with "Key Recovery" enabled. 1) When we try to enroll the user on RA Web with username and code we see a NullPointerException. In the server logs we find an AuthorizationDeniedException and the NullPointerException. 2021-11-12 10:53:28,809 DEBUG [org.ejbca.core.model.era.RaMasterApiProxyBean] (default task-31) Creating locally stored key pair for end entity 'keyrecovery-test-user' 2021-11-12 10:53:28,810 ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component RaMasterApiProxyBean for method public abstract byte[] org.ejbca.core.model.era.RaMasterApi.generateKeyStore(org.cesecore.authentication.tokens.AuthenticationToken,org.cesecore.certificates.endentity.EndEntityInformation) throws org.cesecore.authorization.AuthorizationDeniedException,org.ejbca.core.EjbcaException: javax.ejb.EJBException: java.lang.NullPointerException 2) When we try to enroll the user on Public Web with username and code we see that a key stores has been created. In the server logs we find an NoSuchAlgorithmException and cannot find provider supporting 1.2.840.10045.2.1. This is caused by selecting the wrong Crypto Token from Test issuing CA that only supports an ECC signkey. 2021-11-11 21:43:23,521 DEBUG [org.ejbca.core.ejb.ra.KeyStoreCreateSessionBean] (default task-2) Saving generated keys for recovery for user: keyrecovery-test-user 2021-11-11 21:43:23,521 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;172.31.31.132;;;;resource0=/ca/2073369223 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (default task-2) Extended service with request class 'org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAServiceRequest' called for CA ' Test Issuing CA' 2021-11-11 21:43:23,528 DEBUG [org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService] (default task-2) Encrypting using alias 'signKey' from crypto token 1955349239 2021-11-11 21:43:23,530 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-2) 2021-11-11 21:43:23+01:00;KEYRECOVERY_ADDDATA;FAILURE;KEYRECOVERY;EJBCA;172.31.31.132;2073369223;5C9F72ACC846D322;keyrecovery-test-useryyyy;msg=Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International. 2021-11-11 21:43:23,534 ERROR [org.ejbca.core.ejb.keyrecovery.KeyRecoverySessionBean] (default task-2) Error when trying to add keyrecovery data for certificate with serial number 5c9f72acc846d322, issuer CN=commend-test-issuing-ca,OU=IMS,O=Commend International.: org.cesecore.certificates.ca.extendedservices.IllegalExtendedCAServiceRequestException: java.lang.IllegalStateException: Failed to encrypt keys: exception wrapping content key: cannot create cipher: Cannot find any provider supporting 1.2.840.10045.2.1 at org.ejbca.core.model.ca.caadmin.extendedcaservices.KeyRecoveryCAService.extendedService(KeyRecoveryCAService.java:126) at org.cesecore.certificates.ca.CA.extendedService(CA.java:1133) at org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean.extendedService(CAAdminSessionBean.java:3260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting 1.2.840.10045.2.1 at javax.crypto.Cipher.getInstance(Cipher.java:539) at org.bouncycastle.jcajce.util.DefaultJcaJceHelper.createCipher(Unknown Source) ... 257 more Use Case: We need to enable key recovery for ECC signing certificates that are used for secure boot on long-running embedded devices. The keyEncryptKey is immutable on existing CAs, hence we enabled the "Force local key generation" with a new Crypto Token. This seems to be two bug, which were neither raised nor fixed until now: ad 1) RA Web cannot be used to enroll a user with key recovery enabled Ad 2) Public Web always uses CA Crypto Token to enroll a user with key recovery enabled Your feed is appreciated and with best regards Benjamin Moser Lead Security Architect and OSS Officer Commend International GmbH 5020 Salzburg, Saalachstrasse 51 T +43-662-85 62 25 F +43-662-85 62 26 b....@co... www.commend.com Security and Communication by Commend FN 178618z / LG Salzburg |