Menu
▾
▴
ejbca-develop — Development discussions
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: John K. <sta...@gm...> - 2019-08-30 19:28:45
|
Thank you very much for researching this Tomas. 1. We cannot remove SunEC from the java.security file since it is hardcoded in the SunPKCS11 provider that it MUST call SunEC (I checked in the OpenJDK code) - so unless there's a way to avoid the SunPKCS11 provider and still use our PKCS11 lib, I can't see how to do this. 2. I see the native libsunec.so file in both my Centos installation (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.222.b10-0.el7_6.x86_64/jre/lib/amd64/libsunec.so) and my Ubuntu laptop (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libsunec.so) I have tried explicitly adding the native lib location to both LD_LIBRARY_PATH and (in the clientToolBox sh file) the -Djava.library.path and this does not work. Note also that I don't see the warning that the native lib could not be loaded in any of my log files. I could setup my Ubuntu-based dev laptop to connect to the HSM, but right now, I have no good evidence that doing so would fix this issue. - johnk On 8/30/19 4:52 AM, Tomas Gustavsson wrote: > > Hi, > > This seems to be a common bug specific to CentOS. You'll find many > references (with other applications), for example: > https://github.com/oracle/graal/issues/951 > > Perhaps editing the java.security file and removing SunEC helps? As > suggested in the link above. > > I'm not able to help as I don't have a CentOS connected with an HSM, but > I'd say it's a bug in CentOS, which probably does not happen on RHEL (or > Ubuntu which I am running in development). > > Regards, > Tomas > On 2019-08-29 18:47, John Kemp wrote: >> Thanks Tomas, >> >> I am running Centos 7.6. I did a yum update, which did update Java >> packages, but still have the same error after a reboot + restart of EJBCA. >> >> How can I update NSS packages outside of yum, or what other packages >> should I be looking at? >> >> - johnk >> >> On 8/28/19 2:07 AM, Tomas Gustavsson wrote: >>> >>> Hi, >>> >>> This error: >>> "java.lang.RuntimeException: Cannot load SunEC provider" >>> >>> indicates an issue error with the JDK installation. We've had report of >>> it before, We've seen it depend on non-updated NSS libraries on >>> RHEL/CentOS. >>> See here for example: >>> https://jira.primekey.se/browse/ECA-5701 >>> >>> The solution is to upgrade all libraries in your system. Which CentOS >>> are you running, the latest should be fine. >>> >>> Regards, >>> Tomas >>> >>> >>> On 2019-08-28 01:10, John Kemp wrote: >>>> Hi, >>>> >>>> I am trying to create a P-256 EC key on my HSM using the >>>> PKCS11HSMKeyTool, and this fails, although RSA keys are just fine. Any >>>> hint on configuration here? >>>> >>>> EJBCA 6.15.2.1, OpenJDK 1.8.0.212, Safenet Luna 6 HSM running on >>>> Centos 7. >>>> >>>> - johnk >>>> >>>> [johnk@foo clientToolBox]$ dzdo ./ejbcaClientToolBox.sh PKCS11HSMKeyTool >>>> generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecTEST 1 >>>> >>>> Using Slot Reference Type: Slot Number. >>>> PKCS11 Token [SunPKCS11-libshim.so-slot1] Password: >>>> Command could not be executed. See log for stack trace. >>>> 2019-08-27 20:34:58,988 ERROR [org.ejbca.ui.cli.HSMKeyTool] Command >>>> 'PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so >>>> secp256r1 ecdsaTEST 1' could not be executed. >>>> >>>> java.lang.RuntimeException: Cannot load SunEC provider >>>> at >>>> sun.security.pkcs11.P11ECKeyFactory.getSunECProvider(P11ECKeyFactory.java:55) >>>> >>>> >>>> at >>>> sun.security.pkcs11.P11ECKeyFactory.getECParameterSpec(P11ECKeyFactory.java:71) >>>> >>>> >>>> at >>>> sun.security.pkcs11.P11KeyPairGenerator.initialize(P11KeyPairGenerator.java:154) >>>> >>>> >>>> at >>>> sun.security.pkcs11.P11KeyPairGenerator.<init>(P11KeyPairGenerator.java:140) >>>> >>>> >>>> at >>>> sun.security.pkcs11.SunPKCS11$P11Service.newInstance0(SunPKCS11.java:1004) >>>> >>>> at >>>> sun.security.pkcs11.SunPKCS11$P11Service.newInstance(SunPKCS11.java:981) >>>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >>>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:206) >>>> at >>>> java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:279) >>>> at >>>> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:409) >>>> >>>> >>>> at >>>> org.cesecore.keys.util.KeyStoreTools.generateEC(KeyStoreTools.java:250) >>>> at >>>> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:350) >>>> >>>> >>>> at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:243) >>>> at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:723) >>>> at >>>> org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) >>>> at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:67) >>>> >>>> >>>> _______________________________________________ >>>> Ejbca-develop mailing list >>>> Ejb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >>> >>> >>> _______________________________________________ >>> Ejbca-develop mailing list >>> Ejb...@li... >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >>> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-30 08:52:26
|
Hi, This seems to be a common bug specific to CentOS. You'll find many references (with other applications), for example: https://github.com/oracle/graal/issues/951 Perhaps editing the java.security file and removing SunEC helps? As suggested in the link above. I'm not able to help as I don't have a CentOS connected with an HSM, but I'd say it's a bug in CentOS, which probably does not happen on RHEL (or Ubuntu which I am running in development). Regards, Tomas On 2019-08-29 18:47, John Kemp wrote: > Thanks Tomas, > > I am running Centos 7.6. I did a yum update, which did update Java > packages, but still have the same error after a reboot + restart of EJBCA. > > How can I update NSS packages outside of yum, or what other packages > should I be looking at? > > - johnk > > On 8/28/19 2:07 AM, Tomas Gustavsson wrote: >> >> Hi, >> >> This error: >> "java.lang.RuntimeException: Cannot load SunEC provider" >> >> indicates an issue error with the JDK installation. We've had report of >> it before, We've seen it depend on non-updated NSS libraries on >> RHEL/CentOS. >> See here for example: >> https://jira.primekey.se/browse/ECA-5701 >> >> The solution is to upgrade all libraries in your system. Which CentOS >> are you running, the latest should be fine. >> >> Regards, >> Tomas >> >> >> On 2019-08-28 01:10, John Kemp wrote: >>> Hi, >>> >>> I am trying to create a P-256 EC key on my HSM using the >>> PKCS11HSMKeyTool, and this fails, although RSA keys are just fine. Any >>> hint on configuration here? >>> >>> EJBCA 6.15.2.1, OpenJDK 1.8.0.212, Safenet Luna 6 HSM running on >>> Centos 7. >>> >>> - johnk >>> >>> [johnk@foo clientToolBox]$ dzdo ./ejbcaClientToolBox.sh PKCS11HSMKeyTool >>> generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecTEST 1 >>> >>> Using Slot Reference Type: Slot Number. >>> PKCS11 Token [SunPKCS11-libshim.so-slot1] Password: >>> Command could not be executed. See log for stack trace. >>> 2019-08-27 20:34:58,988 ERROR [org.ejbca.ui.cli.HSMKeyTool] Command >>> 'PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so >>> secp256r1 ecdsaTEST 1' could not be executed. >>> >>> java.lang.RuntimeException: Cannot load SunEC provider >>> at >>> sun.security.pkcs11.P11ECKeyFactory.getSunECProvider(P11ECKeyFactory.java:55) >>> >>> >>> at >>> sun.security.pkcs11.P11ECKeyFactory.getECParameterSpec(P11ECKeyFactory.java:71) >>> >>> >>> at >>> sun.security.pkcs11.P11KeyPairGenerator.initialize(P11KeyPairGenerator.java:154) >>> >>> >>> at >>> sun.security.pkcs11.P11KeyPairGenerator.<init>(P11KeyPairGenerator.java:140) >>> >>> >>> at >>> sun.security.pkcs11.SunPKCS11$P11Service.newInstance0(SunPKCS11.java:1004) >>> >>> at >>> sun.security.pkcs11.SunPKCS11$P11Service.newInstance(SunPKCS11.java:981) >>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:206) >>> at >>> java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:279) >>> at >>> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:409) >>> >>> >>> at >>> org.cesecore.keys.util.KeyStoreTools.generateEC(KeyStoreTools.java:250) >>> at >>> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:350) >>> >>> >>> at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:243) >>> at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:723) >>> at >>> org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) >>> at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:67) >>> >>> >>> _______________________________________________ >>> Ejbca-develop mailing list >>> Ejb...@li... >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: John K. <sta...@gm...> - 2019-08-29 16:47:22
|
Thanks Tomas, I am running Centos 7.6. I did a yum update, which did update Java packages, but still have the same error after a reboot + restart of EJBCA. How can I update NSS packages outside of yum, or what other packages should I be looking at? - johnk On 8/28/19 2:07 AM, Tomas Gustavsson wrote: > > Hi, > > This error: > "java.lang.RuntimeException: Cannot load SunEC provider" > > indicates an issue error with the JDK installation. We've had report of > it before, We've seen it depend on non-updated NSS libraries on RHEL/CentOS. > See here for example: > https://jira.primekey.se/browse/ECA-5701 > > The solution is to upgrade all libraries in your system. Which CentOS > are you running, the latest should be fine. > > Regards, > Tomas > > > On 2019-08-28 01:10, John Kemp wrote: >> Hi, >> >> I am trying to create a P-256 EC key on my HSM using the >> PKCS11HSMKeyTool, and this fails, although RSA keys are just fine. Any >> hint on configuration here? >> >> EJBCA 6.15.2.1, OpenJDK 1.8.0.212, Safenet Luna 6 HSM running on Centos 7. >> >> - johnk >> >> [johnk@foo clientToolBox]$ dzdo ./ejbcaClientToolBox.sh PKCS11HSMKeyTool >> generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecTEST 1 >> >> Using Slot Reference Type: Slot Number. >> PKCS11 Token [SunPKCS11-libshim.so-slot1] Password: >> Command could not be executed. See log for stack trace. >> 2019-08-27 20:34:58,988 ERROR [org.ejbca.ui.cli.HSMKeyTool] Command >> 'PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so >> secp256r1 ecdsaTEST 1' could not be executed. >> >> java.lang.RuntimeException: Cannot load SunEC provider >> at >> sun.security.pkcs11.P11ECKeyFactory.getSunECProvider(P11ECKeyFactory.java:55) >> >> at >> sun.security.pkcs11.P11ECKeyFactory.getECParameterSpec(P11ECKeyFactory.java:71) >> >> at >> sun.security.pkcs11.P11KeyPairGenerator.initialize(P11KeyPairGenerator.java:154) >> >> at >> sun.security.pkcs11.P11KeyPairGenerator.<init>(P11KeyPairGenerator.java:140) >> >> at >> sun.security.pkcs11.SunPKCS11$P11Service.newInstance0(SunPKCS11.java:1004) >> at >> sun.security.pkcs11.SunPKCS11$P11Service.newInstance(SunPKCS11.java:981) >> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >> at sun.security.jca.GetInstance.getInstance(GetInstance.java:206) >> at >> java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:279) >> at >> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:409) >> >> at >> org.cesecore.keys.util.KeyStoreTools.generateEC(KeyStoreTools.java:250) >> at >> org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:350) >> >> at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:243) >> at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:723) >> at >> org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) >> at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:67) >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-28 06:08:03
|
Hi, This error: "java.lang.RuntimeException: Cannot load SunEC provider" indicates an issue error with the JDK installation. We've had report of it before, We've seen it depend on non-updated NSS libraries on RHEL/CentOS. See here for example: https://jira.primekey.se/browse/ECA-5701 The solution is to upgrade all libraries in your system. Which CentOS are you running, the latest should be fine. Regards, Tomas On 2019-08-28 01:10, John Kemp wrote: > Hi, > > I am trying to create a P-256 EC key on my HSM using the > PKCS11HSMKeyTool, and this fails, although RSA keys are just fine. Any > hint on configuration here? > > EJBCA 6.15.2.1, OpenJDK 1.8.0.212, Safenet Luna 6 HSM running on Centos 7. > > - johnk > > [johnk@foo clientToolBox]$ dzdo ./ejbcaClientToolBox.sh PKCS11HSMKeyTool > generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecTEST 1 > > Using Slot Reference Type: Slot Number. > PKCS11 Token [SunPKCS11-libshim.so-slot1] Password: > Command could not be executed. See log for stack trace. > 2019-08-27 20:34:58,988 ERROR [org.ejbca.ui.cli.HSMKeyTool] Command > 'PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so > secp256r1 ecdsaTEST 1' could not be executed. > > java.lang.RuntimeException: Cannot load SunEC provider > at > sun.security.pkcs11.P11ECKeyFactory.getSunECProvider(P11ECKeyFactory.java:55) > > at > sun.security.pkcs11.P11ECKeyFactory.getECParameterSpec(P11ECKeyFactory.java:71) > > at > sun.security.pkcs11.P11KeyPairGenerator.initialize(P11KeyPairGenerator.java:154) > > at > sun.security.pkcs11.P11KeyPairGenerator.<init>(P11KeyPairGenerator.java:140) > > at > sun.security.pkcs11.SunPKCS11$P11Service.newInstance0(SunPKCS11.java:1004) > at > sun.security.pkcs11.SunPKCS11$P11Service.newInstance(SunPKCS11.java:981) > at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > at sun.security.jca.GetInstance.getInstance(GetInstance.java:206) > at > java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:279) > at > org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:409) > > at > org.cesecore.keys.util.KeyStoreTools.generateEC(KeyStoreTools.java:250) > at > org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:350) > > at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:243) > at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:723) > at > org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) > at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:67) > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: John K. <sta...@gm...> - 2019-08-27 23:11:07
|
Hi, I am trying to create a P-256 EC key on my HSM using the PKCS11HSMKeyTool, and this fails, although RSA keys are just fine. Any hint on configuration here? EJBCA 6.15.2.1, OpenJDK 1.8.0.212, Safenet Luna 6 HSM running on Centos 7. - johnk [johnk@foo clientToolBox]$ dzdo ./ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecTEST 1 Using Slot Reference Type: Slot Number. PKCS11 Token [SunPKCS11-libshim.so-slot1] Password: Command could not be executed. See log for stack trace. 2019-08-27 20:34:58,988 ERROR [org.ejbca.ui.cli.HSMKeyTool] Command 'PKCS11HSMKeyTool generate /usr/safenet/lunaclient/lib/libshim.so secp256r1 ecdsaTEST 1' could not be executed. java.lang.RuntimeException: Cannot load SunEC provider at sun.security.pkcs11.P11ECKeyFactory.getSunECProvider(P11ECKeyFactory.java:55) at sun.security.pkcs11.P11ECKeyFactory.getECParameterSpec(P11ECKeyFactory.java:71) at sun.security.pkcs11.P11KeyPairGenerator.initialize(P11KeyPairGenerator.java:154) at sun.security.pkcs11.P11KeyPairGenerator.<init>(P11KeyPairGenerator.java:140) at sun.security.pkcs11.SunPKCS11$P11Service.newInstance0(SunPKCS11.java:1004) at sun.security.pkcs11.SunPKCS11$P11Service.newInstance(SunPKCS11.java:981) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:206) at java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:279) at org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:409) at org.cesecore.keys.util.KeyStoreTools.generateEC(KeyStoreTools.java:250) at org.cesecore.keys.util.KeyStoreTools.generateKeyPair(KeyStoreTools.java:350) at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:243) at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:723) at org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:67) |
|
From: Tomas G. <to...@pr...> - 2019-08-19 05:38:41
|
Hi Jaime,
I hope you saw the commits of the other issues you reported.
I still want to analyze this issue a little more. Are you available?
Regards,
Tomas
On 2019-08-05 12:47, Tomas Gustavsson wrote:
> Hi,
>
> I'm not sure I fully understand. The patch below simply removes the 20K
> limit right, so if there were 100K rows needing to be re-puplished they
> would all be right?
>
> The 20K limit existed also before r32384 though. This is what I don't
> see in the code, what change r32384 did to the 20K limit.
> Can you point me to that?
>
> Cheers,
> Tomas
>
> On 2019-07-26 01:36, Jaime Hablutzel wrote:
>> Since r32384, around 20k queries to the DB are being produced from
>> PublisherQueueSessionBean#plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated
>> if it succeds at least once in publishing qeued data.
>>
>> Below is a patch where it is worth noting that the 20K limit has been
>> removed as it doesn't make sense anymore cause the transactions are
>> currently circumscribed to the chunks of 100 records processed with each
>> call to PublisherQueueSessionBean#doChunk:
>>
>>
>> ---
>> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionLocal.java
>> (revision 32884)
>> +++
>> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionLocal.java
>> (date 1564089225333)
>> @@ -102,12 +102,10 @@
>> /**
>> * Intended for use from PublishQueueProcessWorker.
>> *
>> - * Publishing algorithm that is a plain fifo queue, but limited to
>> selecting entries to republish at 100 records at a time. It will select
>> from the database for this particular publisher id, and process
>> + * Publishing algorithm that is a plain fifo queue, but limited to
>> selecting entries to publish at 100 records at a time. It will select
>> from the database for this particular publisher, and process
>> * the record that is returned one by one. The records are ordered
>> by date, descending so the oldest record is returned first.
>> * Publishing is tried every time for every record returned, with
>> no limit.
>> * Repeat this process as long as we actually manage to publish
>> something this is because when publishing starts to work we want to
>> publish everything in one go, if possible.
>> - * However we don't want to publish more than 20000 certificates
>> each time, because we want to commit to the database some time as well.
>> - * Now, the OCSP publisher uses a non-transactional data source so
>> it commits every time so...
>> */
>> PublishingResult
>> plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(AuthenticationToken
>> admin, BasePublisher publisher);
>>
>> ---
>> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublishingResult.java
>> (revision 32884)
>> +++
>> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublishingResult.java
>> (date 1564088515443)
>> @@ -18,8 +18,7 @@
>>
>> /**
>> * Represents a return type for publishing operations. Successes and
>> failures are stored in sets containing the fingerprints of what's being
>> stored
>> - * due to the fact that the publisher will by default retry 20,000
>> times on a failed attempt, so the "failures" will be per attempted
>> certificate
>> - * and not all attempts.
>> + * where the "failures" will be per attempted certificate and not all
>> attempts.
>> *
>> * @version $Id: PublishingResult.java 32392 2019-05-22 18:45:21Z
>> mikekushner $
>> *
>> ---
>> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionBean.java
>> (revision 32884)
>> +++
>> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionBean.java
>> (date 1564093297113)
>> @@ -278,12 +278,11 @@
>> PublishingResult result = new PublishingResult();
>> // Repeat this process as long as we actually manage to publish
>> something
>> // this is because when publishing starts to work we want to
>> publish everything in one go, if possible.
>> - // However we don't want to publish more than 20000
>> certificates each time, because we want to commit to the database some
>> time as well.
>> - int totalcount = 0;
>> + PublishingResult chunkResult;
>> do {
>> - result.append(publisherQueueSession.doChunk(admin, publisher));
>> - totalcount += result.getSuccesses();
>> - } while ((result.getSuccesses() > 0) && (totalcount < 20000));
>> + chunkResult = publisherQueueSession.doChunk(admin, publisher);
>> + result.append(chunkResult);
>> + } while (chunkResult.getSuccesses() > 0);
>> return result;
>> }
>>
>> @@ -296,7 +295,6 @@
>>
>> /**
>> * @param admin
>> - * @param publisherId
>> * @param publisher
>> *
>> * @return how many publishing operations that succeeded and failed */
>>
>>
>>
>> --
>>
>> Jaime Hablutzel - +51 994690880
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|
|
From: Tomas G. <to...@pr...> - 2019-08-15 16:19:56
|
Hi Randy, There is quite some documentation on how to upgrade. https://download.primekey.com/docs/EJBCA-Enterprise/6_15_2/Upgrading_EJBCA.html https://blog.ejbca.org/2017/12/the-definitive-ejbca-upgrade-guide.html Regarding migration with export/import, there are a bunch of guides outlining both a process and details to migrate from other CA products. You can follow approximately the same process from EJBCA->EJBCA. https://download.primekey.se/docs/EJBCA-Enterprise/latest/Migrating_from_other_CAs_to_EJBCA.html My colleagues in San Mateo have helped to do quite some such migrations, retaining full history and certificate operations. Regards, Tomas On 2019-08-15 15:55, Randy Yu wrote: > Hi Tomas, > > Is there a set of instructions/steps you can provide that could achieve such data migration straight to the current version? > > -----Original Message----- > From: Tomas Gustavsson <to...@pr...> > Sent: Thursday, August 15, 2019 6:51 AM > To: ejb...@li... > Subject: Re: [Ejbca-develop] EJBCA data export/import to new install > > > Hi Randy, > > Yes we have done such migrations before. > >> Also, if certificate history is taken into account, does EJBCA account >> for serial number collisions? > > Not sure I understand the question, since you have all certificates in the database there can be no (undetected) serial number collisions. In any case the likelihood is extremely small that you would even encounter it. > > Cheers, > Tomas > > On 2019-08-14 18:38, Randy Yu wrote: >> In a plan to move towards a Cloud HSM solution, the requirement is the >> current EJBCA 6.15.x on RHEL7 platform. If we were to move from a >> legacy EJBCA 4.0.16 platform, is there a process to export data for >> the following items and import them to the new platform? >> >> >> >> 1. All historical certificate history 2. All historical CRL history >> >> >> >> Also, if certificate history is taken into account, does EJBCA account >> for serial number collisions? >> >> >> >> Thanks. >> >> >> >> Randy >> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist >> s.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=02%7C01% >> 7Cyu%40echoworx.com%7C2036b91203d34d0e7da408d7216e9255%7C0445f7885dae4 >> 68ba264cf3ab42eb2d6%7C0%7C0%7C637014631105488088&sdata=DyxfOAZHgw1 >> PcniiANnINUXFyAOeEyhGC03%2F9s8XTyg%3D&reserved=0 >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=02%7C01%7Cyu%40echoworx.com%7C2036b91203d34d0e7da408d7216e9255%7C0445f7885dae468ba264cf3ab42eb2d6%7C0%7C0%7C637014631105488088&sdata=DyxfOAZHgw1PcniiANnINUXFyAOeEyhGC03%2F9s8XTyg%3D&reserved=0 > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Randy Yu <yu...@ec...> - 2019-08-15 13:55:48
|
Hi Tomas, Is there a set of instructions/steps you can provide that could achieve such data migration straight to the current version? -----Original Message----- From: Tomas Gustavsson <to...@pr...> Sent: Thursday, August 15, 2019 6:51 AM To: ejb...@li... Subject: Re: [Ejbca-develop] EJBCA data export/import to new install Hi Randy, Yes we have done such migrations before. > Also, if certificate history is taken into account, does EJBCA account > for serial number collisions? Not sure I understand the question, since you have all certificates in the database there can be no (undetected) serial number collisions. In any case the likelihood is extremely small that you would even encounter it. Cheers, Tomas On 2019-08-14 18:38, Randy Yu wrote: > In a plan to move towards a Cloud HSM solution, the requirement is the > current EJBCA 6.15.x on RHEL7 platform. If we were to move from a > legacy EJBCA 4.0.16 platform, is there a process to export data for > the following items and import them to the new platform? > > > > 1. All historical certificate history 2. All historical CRL history > > > > Also, if certificate history is taken into account, does EJBCA account > for serial number collisions? > > > > Thanks. > > > > Randy > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=02%7C01% > 7Cyu%40echoworx.com%7C2036b91203d34d0e7da408d7216e9255%7C0445f7885dae4 > 68ba264cf3ab42eb2d6%7C0%7C0%7C637014631105488088&sdata=DyxfOAZHgw1 > PcniiANnINUXFyAOeEyhGC03%2F9s8XTyg%3D&reserved=0 > _______________________________________________ Ejbca-develop mailing list Ejb...@li... https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fejbca-develop&data=02%7C01%7Cyu%40echoworx.com%7C2036b91203d34d0e7da408d7216e9255%7C0445f7885dae468ba264cf3ab42eb2d6%7C0%7C0%7C637014631105488088&sdata=DyxfOAZHgw1PcniiANnINUXFyAOeEyhGC03%2F9s8XTyg%3D&reserved=0 |
|
From: Tomas G. <to...@pr...> - 2019-08-15 10:51:33
|
Hi Randy, Yes we have done such migrations before. > Also, if certificate history is taken into account, does EJBCA account > for serial number collisions? Not sure I understand the question, since you have all certificates in the database there can be no (undetected) serial number collisions. In any case the likelihood is extremely small that you would even encounter it. Cheers, Tomas On 2019-08-14 18:38, Randy Yu wrote: > In a plan to move towards a Cloud HSM solution, the requirement is the > current EJBCA 6.15.x on RHEL7 platform. If we were to move from a > legacy EJBCA 4.0.16 platform, is there a process to export data for the > following items and import them to the new platform? > > > > 1. All historical certificate history > 2. All historical CRL history > > > > Also, if certificate history is taken into account, does EJBCA account > for serial number collisions? > > > > Thanks. > > > > Randy > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Randy Yu <yu...@ec...> - 2019-08-14 16:38:43
|
In a plan to move towards a Cloud HSM solution, the requirement is the current EJBCA 6.15.x on RHEL7 platform. If we were to move from a legacy EJBCA 4.0.16 platform, is there a process to export data for the following items and import them to the new platform? 1. All historical certificate history 2. All historical CRL history Also, if certificate history is taken into account, does EJBCA account for serial number collisions? Thanks. Randy |
|
From: Tomas G. <to...@pr...> - 2019-08-09 09:14:18
|
Hi Jaime, I committed your patch, a slightly modified version under the jira issue: https://jira.primekey.se/browse/ECA-8412 Regards, Tomas On 2019-08-05 13:07, Tomas Gustavsson wrote: > Hi Jaime, > > Nice find, thanks. > > The logging got a bit misplaced in r32446 and a bit more cleanup was > needed I think. How about this patch, making the returns more structured? > > Can you create an issue in Jira for this? > > Regards, > Tomas > > > On 2019-07-26 02:25, Jaime Hablutzel wrote: >> PublishQueueProcessWorker is currently always reporting a NO_ACTION >> result, even when there are successes or failures. Patch follows: >> >> --- >> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java >> (revision 32884) >> +++ >> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java >> (date 1564026429457) >> @@ -111,7 +111,7 @@ >> int publisherId = Integer.valueOf(ids[i]); >> // Get everything from the queue for this >> publisher id >> BasePublisher publisher = >> publisherSession.getPublisher(publisherId); >> - >> publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(), >> publisher); >> + >> publishingResult.append(publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(), >> publisher)); >> } >> } else { >> log.debug("No publisher ids configured for worker."); >> @@ -121,23 +121,25 @@ >> runmap.put(this.serviceName, Boolean.FALSE); >> } >> } >> - } else { >> - log.info >> <http://log.info>(InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm", >> PublishQueueProcessWorker.class.getName())); >> - } >> - log.trace("<work"); >> - if (publishingResult.getSuccesses() == 0 && >> publishingResult.getFailures() == 0) { >> - return new ServiceExecutionResult(Result.NO_ACTION, >> - "Publishing Queue Service " + serviceName + " ran, >> but the publishing queue was either empty or the publisher(s) could not >> connect."); >> - } else { >> - if (publishingResult.getFailures() != 0) { >> - return new ServiceExecutionResult(Result.FAILURE, >> - "Publishing Queue Service " + serviceName + " >> ran with " + publishingResult.getFailures() + " failed publishing >> operations" >> - + (publishingResult.getSuccesses() == 0 >> ? "." >> - : " and " + >> publishingResult.getSuccesses() + " successful publishing operations.")); >> - } else { >> - return new ServiceExecutionResult(Result.SUCCESS, >> "Publishing Queue Service " + serviceName + " ran with " >> - + publishingResult.getSuccesses() + " >> successful publishing operations."); >> + log.trace("<work"); >> + if (publishingResult.getSuccesses() == 0 && >> publishingResult.getFailures() == 0) { >> + return new ServiceExecutionResult(Result.NO_ACTION, >> + "Publishing Queue Service " + serviceName + " >> ran, but the publishing queue was either empty or the publisher(s) could >> not connect."); >> + } else { >> + if (publishingResult.getFailures() != 0) { >> + return new ServiceExecutionResult(Result.FAILURE, >> + "Publishing Queue Service " + serviceName + >> " ran with " + publishingResult.getFailures() + " failed publishing >> operations" >> + + (publishingResult.getSuccesses() >> == 0 ? "." >> + : " and " + >> publishingResult.getSuccesses() + " successful publishing operations.")); >> + } else { >> + return new ServiceExecutionResult(Result.SUCCESS, >> "Publishing Queue Service " + serviceName + " ran with " >> + + publishingResult.getSuccesses() + " >> successful publishing operations."); >> + } >> } >> + } else { >> + String msg = >> InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm", >> PublishQueueProcessWorker.class.getName()); >> + log.info <http://log.info>(msg); >> + return new ServiceExecutionResult(Result.NO_ACTION, msg); >> } >> } >> >> -- >> Jaime Hablutzel - +51 994690880 >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Tomas G. <to...@pr...> - 2019-08-09 09:01:21
|
Hi Jaime, I committed your patch for this issue as this Jira issue. https://jira.primekey.se/browse/ECA-8411 Did you have time to look at the other issues you reported? Regards, Tomas On 2019-08-05 12:35, Tomas Gustavsson wrote: > Hi Jaime, > > This issue, with the simple patch looks really good. I see the issue you > have reproduced. > > Could you create a jira issue for this? > > Also, the documentation for "Use queue for CRLs" in > https://download.primekey.com/docs/EJBCA-Enterprise/6_15_2/Publishers.html > should be updated I think. It should be clear that even if you use > direct publishing, and it works, the CRL will be stored in the queue if > this is enabled. > > A java comment for the patch line would be good as well. > > // publishStatus can only be eityher STATUS_PENDING or STATUS_SUCCESS, > for CRLs we want to store with the actual status, that may be > STATUS_SUCCESS if it was published directly above > > Cheers, > Tomas > > On 2019-07-26 00:58, Jaime Hablutzel wrote: >> If a publisher with the following settings is configured: >> >> * *No direct publishing, only use queue:* Disabled >> * *Keep successfully published items in database:* Enabled >> * *Use queue for CRLs:* Enabled >> >> And it publishes a CRL successfully, the CRL will be kept in the >> publisher queue with STATUS_PENDING anyway and something like a Publish >> Queue Process Service will be required to process it again and mark it >> with STATUS_SUCCESS, resulting in the CRL published twice, instead of >> only once. >> >> A simple patch follows: >> >> --- >> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherSessionBean.java >> (revision 32884) >> +++ >> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherSessionBean.java >> (date 1563994959367) >> @@ -309,7 +309,7 @@ >> pqvd.setUserDN(issuerDn); >> String fp = CertTools.getFingerprintAsString(incrl); >> try { >> - publisherQueueSession.addQueueData(id, >> PublisherConst.PUBLISH_TYPE_CRL, fp, pqvd, PublisherConst.STATUS_PENDING); >> + publisherQueueSession.addQueueData(id, >> PublisherConst.PUBLISH_TYPE_CRL, fp, pqvd, publishStatus); >> String msg = >> intres.getLocalizedMessage("publisher.storequeue", name, fp, "CRL"); >> log.info <http://log.info>(msg); >> } catch (CreateException e) { >> -- >> Jaime Hablutzel - +51 994690880 >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-05 11:07:39
|
Hi Jaime,
Nice find, thanks.
The logging got a bit misplaced in r32446 and a bit more cleanup was
needed I think. How about this patch, making the returns more structured?
Can you create an issue in Jira for this?
Regards,
Tomas
On 2019-07-26 02:25, Jaime Hablutzel wrote:
> PublishQueueProcessWorker is currently always reporting a NO_ACTION
> result, even when there are successes or failures. Patch follows:
>
> ---
> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
> (revision 32884)
> +++
> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
> (date 1564026429457)
> @@ -111,7 +111,7 @@
> int publisherId = Integer.valueOf(ids[i]);
> // Get everything from the queue for this
> publisher id
> BasePublisher publisher =
> publisherSession.getPublisher(publisherId);
> -
> publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
> publisher);
> +
> publishingResult.append(publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
> publisher));
> }
> } else {
> log.debug("No publisher ids configured for worker.");
> @@ -121,23 +121,25 @@
> runmap.put(this.serviceName, Boolean.FALSE);
> }
> }
> - } else {
> - log.info
> <http://log.info>(InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
> PublishQueueProcessWorker.class.getName()));
> - }
> - log.trace("<work");
> - if (publishingResult.getSuccesses() == 0 &&
> publishingResult.getFailures() == 0) {
> - return new ServiceExecutionResult(Result.NO_ACTION,
> - "Publishing Queue Service " + serviceName + " ran,
> but the publishing queue was either empty or the publisher(s) could not
> connect.");
> - } else {
> - if (publishingResult.getFailures() != 0) {
> - return new ServiceExecutionResult(Result.FAILURE,
> - "Publishing Queue Service " + serviceName + "
> ran with " + publishingResult.getFailures() + " failed publishing
> operations"
> - + (publishingResult.getSuccesses() == 0
> ? "."
> - : " and " +
> publishingResult.getSuccesses() + " successful publishing operations."));
> - } else {
> - return new ServiceExecutionResult(Result.SUCCESS,
> "Publishing Queue Service " + serviceName + " ran with "
> - + publishingResult.getSuccesses() + "
> successful publishing operations.");
> + log.trace("<work");
> + if (publishingResult.getSuccesses() == 0 &&
> publishingResult.getFailures() == 0) {
> + return new ServiceExecutionResult(Result.NO_ACTION,
> + "Publishing Queue Service " + serviceName + "
> ran, but the publishing queue was either empty or the publisher(s) could
> not connect.");
> + } else {
> + if (publishingResult.getFailures() != 0) {
> + return new ServiceExecutionResult(Result.FAILURE,
> + "Publishing Queue Service " + serviceName +
> " ran with " + publishingResult.getFailures() + " failed publishing
> operations"
> + + (publishingResult.getSuccesses()
> == 0 ? "."
> + : " and " +
> publishingResult.getSuccesses() + " successful publishing operations."));
> + } else {
> + return new ServiceExecutionResult(Result.SUCCESS,
> "Publishing Queue Service " + serviceName + " ran with "
> + + publishingResult.getSuccesses() + "
> successful publishing operations.");
> + }
> }
> + } else {
> + String msg =
> InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
> PublishQueueProcessWorker.class.getName());
> + log.info <http://log.info>(msg);
> + return new ServiceExecutionResult(Result.NO_ACTION, msg);
> }
> }
>
> --
> Jaime Hablutzel - +51 994690880
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|
|
From: Tomas G. <to...@pr...> - 2019-08-05 10:47:20
|
Hi,
I'm not sure I fully understand. The patch below simply removes the 20K
limit right, so if there were 100K rows needing to be re-puplished they
would all be right?
The 20K limit existed also before r32384 though. This is what I don't
see in the code, what change r32384 did to the 20K limit.
Can you point me to that?
Cheers,
Tomas
On 2019-07-26 01:36, Jaime Hablutzel wrote:
> Since r32384, around 20k queries to the DB are being produced from
> PublisherQueueSessionBean#plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated
> if it succeds at least once in publishing qeued data.
>
> Below is a patch where it is worth noting that the 20K limit has been
> removed as it doesn't make sense anymore cause the transactions are
> currently circumscribed to the chunks of 100 records processed with each
> call to PublisherQueueSessionBean#doChunk:
>
>
> ---
> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionLocal.java
> (revision 32884)
> +++
> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionLocal.java
> (date 1564089225333)
> @@ -102,12 +102,10 @@
> /**
> * Intended for use from PublishQueueProcessWorker.
> *
> - * Publishing algorithm that is a plain fifo queue, but limited to
> selecting entries to republish at 100 records at a time. It will select
> from the database for this particular publisher id, and process
> + * Publishing algorithm that is a plain fifo queue, but limited to
> selecting entries to publish at 100 records at a time. It will select
> from the database for this particular publisher, and process
> * the record that is returned one by one. The records are ordered
> by date, descending so the oldest record is returned first.
> * Publishing is tried every time for every record returned, with
> no limit.
> * Repeat this process as long as we actually manage to publish
> something this is because when publishing starts to work we want to
> publish everything in one go, if possible.
> - * However we don't want to publish more than 20000 certificates
> each time, because we want to commit to the database some time as well.
> - * Now, the OCSP publisher uses a non-transactional data source so
> it commits every time so...
> */
> PublishingResult
> plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(AuthenticationToken
> admin, BasePublisher publisher);
>
> ---
> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublishingResult.java
> (revision 32884)
> +++
> modules/ejbca-ejb-interface/src/org/ejbca/core/ejb/ca/publisher/PublishingResult.java
> (date 1564088515443)
> @@ -18,8 +18,7 @@
>
> /**
> * Represents a return type for publishing operations. Successes and
> failures are stored in sets containing the fingerprints of what's being
> stored
> - * due to the fact that the publisher will by default retry 20,000
> times on a failed attempt, so the "failures" will be per attempted
> certificate
> - * and not all attempts.
> + * where the "failures" will be per attempted certificate and not all
> attempts.
> *
> * @version $Id: PublishingResult.java 32392 2019-05-22 18:45:21Z
> mikekushner $
> *
> ---
> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionBean.java
> (revision 32884)
> +++
> modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherQueueSessionBean.java
> (date 1564093297113)
> @@ -278,12 +278,11 @@
> PublishingResult result = new PublishingResult();
> // Repeat this process as long as we actually manage to publish
> something
> // this is because when publishing starts to work we want to
> publish everything in one go, if possible.
> - // However we don't want to publish more than 20000
> certificates each time, because we want to commit to the database some
> time as well.
> - int totalcount = 0;
> + PublishingResult chunkResult;
> do {
> - result.append(publisherQueueSession.doChunk(admin, publisher));
> - totalcount += result.getSuccesses();
> - } while ((result.getSuccesses() > 0) && (totalcount < 20000));
> + chunkResult = publisherQueueSession.doChunk(admin, publisher);
> + result.append(chunkResult);
> + } while (chunkResult.getSuccesses() > 0);
> return result;
> }
>
> @@ -296,7 +295,6 @@
>
> /**
> * @param admin
> - * @param publisherId
> * @param publisher
> *
> * @return how many publishing operations that succeeded and failed */
>
>
>
> --
>
> Jaime Hablutzel - +51 994690880
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|
|
From: Tomas G. <to...@pr...> - 2019-08-05 10:35:13
|
Hi Jaime, This issue, with the simple patch looks really good. I see the issue you have reproduced. Could you create a jira issue for this? Also, the documentation for "Use queue for CRLs" in https://download.primekey.com/docs/EJBCA-Enterprise/6_15_2/Publishers.html should be updated I think. It should be clear that even if you use direct publishing, and it works, the CRL will be stored in the queue if this is enabled. A java comment for the patch line would be good as well. // publishStatus can only be eityher STATUS_PENDING or STATUS_SUCCESS, for CRLs we want to store with the actual status, that may be STATUS_SUCCESS if it was published directly above Cheers, Tomas On 2019-07-26 00:58, Jaime Hablutzel wrote: > If a publisher with the following settings is configured: > > * *No direct publishing, only use queue:* Disabled > * *Keep successfully published items in database:* Enabled > * *Use queue for CRLs:* Enabled > > And it publishes a CRL successfully, the CRL will be kept in the > publisher queue with STATUS_PENDING anyway and something like a Publish > Queue Process Service will be required to process it again and mark it > with STATUS_SUCCESS, resulting in the CRL published twice, instead of > only once. > > A simple patch follows: > > --- > modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherSessionBean.java > (revision 32884) > +++ > modules/ejbca-ejb/src/org/ejbca/core/ejb/ca/publisher/PublisherSessionBean.java > (date 1563994959367) > @@ -309,7 +309,7 @@ > pqvd.setUserDN(issuerDn); > String fp = CertTools.getFingerprintAsString(incrl); > try { > - publisherQueueSession.addQueueData(id, > PublisherConst.PUBLISH_TYPE_CRL, fp, pqvd, PublisherConst.STATUS_PENDING); > + publisherQueueSession.addQueueData(id, > PublisherConst.PUBLISH_TYPE_CRL, fp, pqvd, publishStatus); > String msg = > intres.getLocalizedMessage("publisher.storequeue", name, fp, "CRL"); > log.info <http://log.info>(msg); > } catch (CreateException e) { > -- > Jaime Hablutzel - +51 994690880 > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-05 10:26:36
|
Hi, There is no other API in EJBCA itself. You can query the database of course, but you already knew that :-) I also wrote a small guide how to integrate with Graylog (or similar log systems like Splunk) to query the logs efficiently. https://download.primekey.com/docs/EJBCA-Enterprise/6_15_2/Logging.html#src-23858529_id-.Loggingv6.15.0-Graylog Cheers, Tomas On 2019-07-21 22:07, Jaime Hablutzel wrote: > Are there any other methods available for querying the audit log > different than going through the Admin GUI's "Supervision Functions > > Audit Log"?, maybe a CLI tool or a WS API?. > > I'm especially interested in a method that would allow to filter log > entries based on some text in the details message too, for example, to > identify CAA validation events. > > -- > Jaime Hablutzel - +51 994690880 > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-05 10:24:00
|
Hi Jaime,
To be fair, the intent of RFC5280 is to make sure that a revocation
entry is included in at least one CRL, not exactly one. To protect users.
There are several ways where an entry is included in more than one CRL
with EJBCA. Another way is for example when you revoke more than 10K
records at a time, as EJBCA will only archive max 10K records each time
in order to protect against too long CRL generation times.
Anyhow, back to the questions below. Just using "now" misses the point
that delta CRLs can be used, and a revocation entry must be included in
the base CRL. This could probably be fixed by checking if it is a delta
CRL that is being generated...
Another corner case is when a certificate expired during CRL generation.
Large CRLs can take a long time to be generated, and is a certificate
expired between the listing of certificates to include on the CRL and
the actual completion of the CRL generation.
Another thing to think about with EJBCA is that you always have to
consider huge scale distributed systems, where databases are clustered
and CRL generation nodes can be spread out, and CRLs can be more than
hundred MB.
One thing we found out is that if anything can go wrong, it will
eventually when there are thousands of installations of that sort. Due
to this, the current code is the "safest" one I can think of to ensure
that each revocation is definitely at least on one base CRL.
It can be one two yes, but the likelihood that it will be missed is low.
(if generating delta CRLs it will be on only one base CRL).
Due to the above I don't plan to change this as it is hard to feel
absolutely safe with a small fix, and also with any complicated fix.
(Of course, parsing the last CRL looking for records is not an option
due to the time it can take on large CRLs)
Cheers,
Tomas
On 2019-07-20 02:36, Jaime Hablutzel wrote:
> From RFC 5280, "3.3. Revocation":
>
> An entry MUST NOT be removed
> from the CRL until it appears on one regularly scheduled CRL issued
> beyond the revoked certificate’s validity period.
>
>
> But, if you look carefully at the following code
> from org.ejbca.core.ejb.crl.PublishingCrlSessionBean#internalCreateCRL (r32721):
>
> for (final RevokedCertInfo revokedCertInfo : revokedCertificates) {
> ...
> if ( !keepexpiredcertsoncrl && revokedCertInfo.getExpireDate() !=
> null && *revokedCertInfo.getExpireDate().before(lastCrlCreationDate)* ) {
> ...
> noConflictCertificateStoreSession.setStatus(archiveAdmin,
> revokedCertInfo.getCertificateFingerprint(),
> CertificateConstants.CERT_ARCHIVED);
> } else {
> ...
> }
> }
> final byte[] crlBytes = generateAndStoreCRL(admin, ca,
> crlPartitionIndex, revokedCertificates, lastBaseCrlInfo, false);
>
> You can see that the highlighted snippet won't become true until it is
> executed for a second time after a given certificate has expired,
> producing that expired certificate entries get into two CRLs instead of
> only one.
>
> So, is there are reason to keep that code like that instead of replacing
> it with something like the following:
>
> if ( !keepexpiredcertsoncrl && revokedCertInfo.getExpireDate() != null
> && *revokedCertInfo.getExpireDate().before(now)* ) {
>
> Which would allow to include the expired certificate entries in only one
> CRL beyond the certificate validity period, providing this way a more
> precise RFC 5280 implementation?.
>
> PS: The previous is not a production ready patch as it could have side
> effects that haven't been checked in detail.
>
> --
> Jaime Hablutzel - +51 994690880
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|
|
From: Tomas G. <to...@pr...> - 2019-08-05 10:02:40
|
Hi, You can configure everything around key bindings and OCSP key bindings using ejbca.sh CLI. We have customers who have made a "CLI GUI" using the ejbca.sh CLI in the back-end. See: bin/ejbca.sh keybind and bin/ejbca.sh ocsp Regards, Tomas --- PrimeKey Tech Days 2019 Stockholm, Sweden 17-18 September www.primekey.com/tech-days On 2019-07-31 15:56, ohaya--- via Ejbca-develop wrote: > Hi, > > When we deploy systems here, as much as possible, we want to have all > materials for the installation prepared ahead of time. > > So, for example, we if the installation requires a server cert and key, > we pre-generate the key and cert and provide those to the installers. > > When we install the EJBCA OCSP responder now, when we are creating the > Internal Key Binding, it looks like we have to generate a CSR by > clicking the "CSR" button, then get that CSR signed to get the cert by > our CA, and then import the CA-issued cert to create the Internal Key > Binding. > > If we have an appropriate (e.g., with purpose OCSPSigning, etc.) cert > and key already prepared and issued by our own CA, is there a way to > create the Internal Key Binding for OCSP responder using those > pre-staged cert and key? > > In other words, we want to be able to create the Internal Key > Binding/OCSPKeyBinding, but instead of creating the CSR in the Adminweb, > we want to just import our own pre-prepared cert and key. > > Is there a way to do that? > > Thanks, > Jim > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-05 09:06:50
|
Hi, Your default responder doesnt exists. CN=simpleca,OU=simplecaou,O=simplecao,C=US Wasn't the use case from the beginning that every OCSP response should be signed by the "default responder"? Regards, Tomas On 2019-07-31 14:36, ohaya--- via Ejbca-develop wrote: > Hi Tomas, > > I just re-imported that same CA cert and CRL for the CA that was giving > me the problem with the OCSP responses yesterday, using a random "name", > and then restarted the standalone.sh (I restarted it twice actually), > and this is what I get in the server logging: > > > 2019-07-31 11:53:18,560 DEBUG > [org.cesecore.certificates.ca.internal.CaCertificateCache] > (ServerService Thread Pool -- 97) Found the following CA certificates : > CN=ORCxxxxx,...,C=US,17 > CN=DYYY,...,C=US,14 > CN=simpleca,OU=simplecaou,O=simplecao,C=US,15CF58B49A5 > CN=ManagementCA,O=EJBCA Sample,C=SE,63E9453741C9A8F61061282BE36185F4E9D495B6 > > The "CN=ORCxxx,...,C=US" is the one I am trying to test OCSP requests > with, and now I get this when I run the "openssl ocsp..." test request: > > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD > Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52 > Serial Number: 3731 > Request Extensions: > OCSP Nonce: > 0410C2666B492B583E8ACC716D3698B245AB > Responder Error: unauthorized (6) > > > and in the server.log I get the following when I run the test request: > > 12:04:57,036 INFO > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (default task-1) Received OCSP request for certificate with serNo: 3731, > and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip > 192.168.20.148. > 12:04:57,049 ERROR > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (default task-1) Unable to find CA certificate by issuer name hash: > dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: > CN=simpleca,OU=simplecaou,O=simplecao,C=US. > > > > So now that I re-imported the CA (with a random Name) and the CRL and > restarted, I am getting the same problem with OCSP requests not working > again. > > > Notice the message above in the server log that two of the numbers after > the CA strings are really short (2 digits each): > > CN=ORCxxxxx,...,C=US,17 > CN=DYYY,...,C=US,14 > > > From what you said, those numbers are the name hash. Is that normal for > them to be just 2 digits? > > Is that maybe why the OCSP responses that I am testing for the > "CN=ORCxxxxx,...,C=US" CA are failing now again? > > Thanks, > Jim > > > > On Wednesday, July 31, 2019, 8:12:45 AM UTC, Tomas Gustavsson > <to...@pr...> wrote: > > > > No that is incorrect. The "Name" is not used for anything related to OCSP. > > The "Issuer Name Hash" as referenced in the log is defined in OCSP RFC > 6960 and is based on the subject DN of the CA certificate. > > The Name you enter as name of the CA is an arbitrary string. Typically > something like "My CA v1". > > In a debug log of EJBCA it will show regularly (first during startup) > which CA certificates are loaded by EJBCA. Something like: > > 2019-07-31 10:08:32,086 DEBUG > [org.cesecore.certificates.ca.internal.CaCertificateCache] > (ServerService Thread Pool -- 78) Found the following CA certificates : > CN=TestExportRemoveRestoreCA3,131F6952BCE09394 > CN=TestServiceService_TestCA1,3BCF13B76E51DE31 > CN=RenamedTestCA,4FE83A6F12880043 > CN=TestServiceService_TestCA2,3301346766C4FF66 > > There is a cache time, and the CA certificate cache is reloaded as a > time interval specified in cache.properties. Always during restart of > course. When importing a new CA certificate, which is only an "External > CA" and can not be used to answer OCSP queries, it takes some time > before it appears in the cache. > OCSP Key Binding are set up to answer queries for "External CAs", you > can either use a "default responder" (which I think is what we discussed > before right?), or you can issue a specific OCSP responder certificate > for all/any CAs. > > Regards, > Tomas > > On 2019-07-30 22:41, ohaya--- via Ejbca-develop wrote: >> Hi, >> >> I was just able to get OCSP responses working with this CA/CRL, and I >> *think* that the answer was that EJBCA OCSP Responder did not like the >> *NAME* that I used/entered when I created the Certificate Authority in >> the EJBCA Adminweb!!! >> >> What I mean is the adminweb page with the URL >> https://XXXXX:8443/ejbca/adminweb/ca/editcas/editcas.jsp, where you use >> the "Import CA Certificate..." button. >> >> It appears that EJBCA OCSP Responder actually uses the "Name" value (and >> I guess that is what it hashes to get the name hash) to match the issuer >> on the incoming OCSP request. >> >> There seems to be SOME KIND OF RULE for that Name, but what is that >> rule, EXACTLY? >> >> My best guess is that that Name has to match the filename of the CA >> cert/PEM, EXACTLY, including the case of the filename, but NOT INCLUDING >> the file extension. >> >> In other words, if the CA cert PEM file is "joe_foo.pem", then you have >> to enter "joe_foo" for the Name field when creating the new CA in the >> Adminweb. >> >> And, "JOE_FOO" or "JoE_FoO" does not work... it has to be "joe_foo". >> >> Another example is if the CA cert PEM file is >> "This_is_mY_cert.crt.pem.crt", then, for the Name you enter when you >> create the CA in the Admin web, you have to enter: >> >> This_is_mY_cert.crt.pem >> >> Is that correct? Can anyone confirm what the actual Name string has to >> be? >> >> This is a kind of time killer... spent almost a whole day trying to >> figure this one out :(... >> >> Jim >> >> >> >> On Tuesday, July 30, 2019, 7:45:20 PM UTC, oh...@ya... > <mailto:oh...@ya...> >> <oh...@ya... <mailto:oh...@ya...>> wrote: >> >> >> Also, FYI, here is the response I get when I test the OCSP request using >> "openssl ocsp": >> >> OCSP Request Data: >> Version: 1 (0x0) >> Requestor List: >> Certificate ID: >> Hash Algorithm: sha1 >> Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD >> Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52 >> Serial Number: 3732 >> Request Extensions: >> OCSP Nonce: >> 04109186E755667555C98040988194088E5D >> Responder Error: unauthorized (6) >> >> >> NOTICE the "Responder Error: unauthorized (6)" error. >> >> I have even deleted the CA from EJBCA OCSP responder and then >> re-imported that CA's cert and the latest CRL and I am still getting the >> same error. >> >> Thanks, >> Jim >> >> On Tuesday, July 30, 2019, 4:37:49 PM UTC, oh...@ya... > <mailto:oh...@ya...> >> <oh...@ya... <mailto:oh...@ya...>> wrote: >> >> >> Hi, >> >> I am circling back and trying to do some OCSP response testing with the >> EJBCA OCSP responder, but when I run "openssl ocsp" testing, I am >> getting an error (from the EJBCA logging): >> >> 16:25:35,230 INFO >> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] >> (default task-7) Received OCSP request for certificate with serNo: 3a1b, >> and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip >> 192.168.xx.yy. >> 16:25:35,236 ERROR >> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] >> (default task-7) Unable to find CA certificate by issuer name hash: >> dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: >> CN=xxxx. >> >> I think that I have that CA imported into EJBCA and also the latest CRL. >> >> Is there a way to find out what that issuer name that it is looking for >> from the "issuer name hash"? >> >> I'm guessing there probably isn't, so how can I debug why it is not able >> to find the CA (and CRL from that CA) in EJBCA? >> >> Thanks, >> Jim > >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... > <mailto:Ejb...@li...> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > <mailto:Ejb...@li...> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-08-03 07:02:44
|
Hi Jaime,
I think it's great to have it here for initial discussion, and then create an issue. It's been vacation times here in Sweden, which is why it's been slow. I'm back next week and plan to look at your issues, which I am sure are interesting.
Expect more discussion during next week.
Cheers,
Tomas
On August 2, 2019 5:19:24 PM GMT+02:00, Jaime Hablutzel <hab...@gm...> wrote:
>Did you have the chance to take a look at my latest bug report emails?.
>
>Anyway, for reporting these type of minor bugs, maybe it would be
>better to
>directly create JIRA issues or is it still a good idea to post these
>reports here first to allow for previous discussion?.
>
>On Thu, Jul 25, 2019, 7:25 PM Jaime Hablutzel <hab...@gm...>
>wrote:
>
>> PublishQueueProcessWorker is currently always reporting a NO_ACTION
>> result, even when there are successes or failures. Patch follows:
>>
>> ---
>>
>modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
>> (revision 32884)
>> +++
>>
>modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
>> (date 1564026429457)
>> @@ -111,7 +111,7 @@
>> int publisherId = Integer.valueOf(ids[i]);
>> // Get everything from the queue for this
>> publisher id
>> BasePublisher publisher =
>> publisherSession.getPublisher(publisherId);
>> -
>>
>publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
>> publisher);
>> +
>>
>publishingResult.append(publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
>> publisher));
>> }
>> } else {
>> log.debug("No publisher ids configured for
>worker.");
>> @@ -121,23 +121,25 @@
>> runmap.put(this.serviceName, Boolean.FALSE);
>> }
>> }
>> - } else {
>> -
>log.info(InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
>> PublishQueueProcessWorker.class.getName()));
>> - }
>> - log.trace("<work");
>> - if (publishingResult.getSuccesses() == 0 &&
>> publishingResult.getFailures() == 0) {
>> - return new ServiceExecutionResult(Result.NO_ACTION,
>> - "Publishing Queue Service " + serviceName + "
>ran,
>> but the publishing queue was either empty or the publisher(s) could
>not
>> connect.");
>> - } else {
>> - if (publishingResult.getFailures() != 0) {
>> - return new ServiceExecutionResult(Result.FAILURE,
>> - "Publishing Queue Service " + serviceName +
>" ran
>> with " + publishingResult.getFailures() + " failed publishing
>operations"
>> - + (publishingResult.getSuccesses()
>== 0 ?
>> "."
>> - : " and " +
>> publishingResult.getSuccesses() + " successful publishing
>operations."));
>> - } else {
>> - return new ServiceExecutionResult(Result.SUCCESS,
>> "Publishing Queue Service " + serviceName + " ran with "
>> - + publishingResult.getSuccesses() + "
>successful
>> publishing operations.");
>> + log.trace("<work");
>> + if (publishingResult.getSuccesses() == 0 &&
>> publishingResult.getFailures() == 0) {
>> + return new ServiceExecutionResult(Result.NO_ACTION,
>> + "Publishing Queue Service " + serviceName +
>"
>> ran, but the publishing queue was either empty or the publisher(s)
>could
>> not connect.");
>> + } else {
>> + if (publishingResult.getFailures() != 0) {
>> + return new
>ServiceExecutionResult(Result.FAILURE,
>> + "Publishing Queue Service " +
>serviceName + "
>> ran with " + publishingResult.getFailures() + " failed publishing
>> operations"
>> + +
>(publishingResult.getSuccesses() ==
>> 0 ? "."
>> + : " and " +
>> publishingResult.getSuccesses() + " successful publishing
>operations."));
>> + } else {
>> + return new
>ServiceExecutionResult(Result.SUCCESS,
>> "Publishing Queue Service " + serviceName + " ran with "
>> + + publishingResult.getSuccesses() + "
>> successful publishing operations.");
>> + }
>> }
>> + } else {
>> + String msg =
>>
>InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
>> PublishQueueProcessWorker.class.getName());
>> + log.info(msg);
>> + return new ServiceExecutionResult(Result.NO_ACTION,
>msg);
>> }
>> }
>>
>> --
>> Jaime Hablutzel - +51 994690880
>>
|
|
From: Jaime H. <hab...@gm...> - 2019-08-02 15:19:46
|
Did you have the chance to take a look at my latest bug report emails?.
Anyway, for reporting these type of minor bugs, maybe it would be better to
directly create JIRA issues or is it still a good idea to post these
reports here first to allow for previous discussion?.
On Thu, Jul 25, 2019, 7:25 PM Jaime Hablutzel <hab...@gm...> wrote:
> PublishQueueProcessWorker is currently always reporting a NO_ACTION
> result, even when there are successes or failures. Patch follows:
>
> ---
> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
> (revision 32884)
> +++
> modules/ejbca-common-web/src/org/ejbca/core/model/services/workers/PublishQueueProcessWorker.java
> (date 1564026429457)
> @@ -111,7 +111,7 @@
> int publisherId = Integer.valueOf(ids[i]);
> // Get everything from the queue for this
> publisher id
> BasePublisher publisher =
> publisherSession.getPublisher(publisherId);
> -
> publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
> publisher);
> +
> publishingResult.append(publisherQueueSession.plainFifoTryAlwaysLimit100EntriesOrderByTimeCreated(getAdmin(),
> publisher));
> }
> } else {
> log.debug("No publisher ids configured for worker.");
> @@ -121,23 +121,25 @@
> runmap.put(this.serviceName, Boolean.FALSE);
> }
> }
> - } else {
> - log.info(InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
> PublishQueueProcessWorker.class.getName()));
> - }
> - log.trace("<work");
> - if (publishingResult.getSuccesses() == 0 &&
> publishingResult.getFailures() == 0) {
> - return new ServiceExecutionResult(Result.NO_ACTION,
> - "Publishing Queue Service " + serviceName + " ran,
> but the publishing queue was either empty or the publisher(s) could not
> connect.");
> - } else {
> - if (publishingResult.getFailures() != 0) {
> - return new ServiceExecutionResult(Result.FAILURE,
> - "Publishing Queue Service " + serviceName + " ran
> with " + publishingResult.getFailures() + " failed publishing operations"
> - + (publishingResult.getSuccesses() == 0 ?
> "."
> - : " and " +
> publishingResult.getSuccesses() + " successful publishing operations."));
> - } else {
> - return new ServiceExecutionResult(Result.SUCCESS,
> "Publishing Queue Service " + serviceName + " ran with "
> - + publishingResult.getSuccesses() + " successful
> publishing operations.");
> + log.trace("<work");
> + if (publishingResult.getSuccesses() == 0 &&
> publishingResult.getFailures() == 0) {
> + return new ServiceExecutionResult(Result.NO_ACTION,
> + "Publishing Queue Service " + serviceName + "
> ran, but the publishing queue was either empty or the publisher(s) could
> not connect.");
> + } else {
> + if (publishingResult.getFailures() != 0) {
> + return new ServiceExecutionResult(Result.FAILURE,
> + "Publishing Queue Service " + serviceName + "
> ran with " + publishingResult.getFailures() + " failed publishing
> operations"
> + + (publishingResult.getSuccesses() ==
> 0 ? "."
> + : " and " +
> publishingResult.getSuccesses() + " successful publishing operations."));
> + } else {
> + return new ServiceExecutionResult(Result.SUCCESS,
> "Publishing Queue Service " + serviceName + " ran with "
> + + publishingResult.getSuccesses() + "
> successful publishing operations.");
> + }
> }
> + } else {
> + String msg =
> InternalEjbcaResources.getInstance().getLocalizedMessage("services.alreadyrunninginvm",
> PublishQueueProcessWorker.class.getName());
> + log.info(msg);
> + return new ServiceExecutionResult(Result.NO_ACTION, msg);
> }
> }
>
> --
> Jaime Hablutzel - +51 994690880
>
|
|
From: <oh...@ya...> - 2019-07-31 13:56:54
|
Hi, When we deploy systems here, as much as possible, we want to have all materials for the installation prepared ahead of time. So, for example, we if the installation requires a server cert and key, we pre-generate the key and cert and provide those to the installers. When we install the EJBCA OCSP responder now, when we are creating the Internal Key Binding, it looks like we have to generate a CSR by clicking the "CSR" button, then get that CSR signed to get the cert by our CA, and then import the CA-issued cert to create the Internal Key Binding. If we have an appropriate (e.g., with purpose OCSPSigning, etc.) cert and key already prepared and issued by our own CA, is there a way to create the Internal Key Binding for OCSP responder using those pre-staged cert and key? In other words, we want to be able to create the Internal Key Binding/OCSPKeyBinding, but instead of creating the CSR in the Adminweb, we want to just import our own pre-prepared cert and key. Is there a way to do that? Thanks,Jim |
|
From: <oh...@ya...> - 2019-07-31 12:36:23
|
Hi Tomas,
I just re-imported that same CA cert and CRL for the CA that was giving me the problem with the OCSP responses yesterday, using a random "name", and then restarted the standalone.sh (I restarted it twice actually), and this is what I get in the server logging:
2019-07-31 11:53:18,560 DEBUG [org.cesecore.certificates.ca.internal.CaCertificateCache] (ServerService Thread Pool -- 97) Found the following CA certificates :
CN=ORCxxxxx,...,C=US,17
CN=DYYY,...,C=US,14
CN=simpleca,OU=simplecaou,O=simplecao,C=US,15CF58B49A5
CN=ManagementCA,O=EJBCA Sample,C=SE,63E9453741C9A8F61061282BE36185F4E9D495B6
The "CN=ORCxxx,...,C=US" is the one I am trying to test OCSP requests with, and now I get this when I run the "openssl ocsp..." test request:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD
Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52
Serial Number: 3731
Request Extensions:
OCSP Nonce:
0410C2666B492B583E8ACC716D3698B245AB
Responder Error: unauthorized (6)
and in the server.log I get the following when I run the test request:
12:04:57,036 INFO [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-1) Received OCSP request for certificate with serNo: 3731, and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip 192.168.20.148.
12:04:57,049 ERROR [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-1) Unable to find CA certificate by issuer name hash: dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: CN=simpleca,OU=simplecaou,O=simplecao,C=US.
So now that I re-imported the CA (with a random Name) and the CRL and restarted, I am getting the same problem with OCSP requests not working again.
Notice the message above in the server log that two of the numbers after the CA strings are really short (2 digits each):
CN=ORCxxxxx,...,C=US,17
CN=DYYY,...,C=US,14
>From what you said, those numbers are the name hash. Is that normal for them to be just 2 digits?
Is that maybe why the OCSP responses that I am testing for the "CN=ORCxxxxx,...,C=US" CA are failing now again?
Thanks,Jim
On Wednesday, July 31, 2019, 8:12:45 AM UTC, Tomas Gustavsson <to...@pr...> wrote:
No that is incorrect. The "Name" is not used for anything related to OCSP.
The "Issuer Name Hash" as referenced in the log is defined in OCSP RFC
6960 and is based on the subject DN of the CA certificate.
The Name you enter as name of the CA is an arbitrary string. Typically
something like "My CA v1".
In a debug log of EJBCA it will show regularly (first during startup)
which CA certificates are loaded by EJBCA. Something like:
2019-07-31 10:08:32,086 DEBUG
[org.cesecore.certificates.ca.internal.CaCertificateCache]
(ServerService Thread Pool -- 78) Found the following CA certificates :
CN=TestExportRemoveRestoreCA3,131F6952BCE09394
CN=TestServiceService_TestCA1,3BCF13B76E51DE31
CN=RenamedTestCA,4FE83A6F12880043
CN=TestServiceService_TestCA2,3301346766C4FF66
There is a cache time, and the CA certificate cache is reloaded as a
time interval specified in cache.properties. Always during restart of
course. When importing a new CA certificate, which is only an "External
CA" and can not be used to answer OCSP queries, it takes some time
before it appears in the cache.
OCSP Key Binding are set up to answer queries for "External CAs", you
can either use a "default responder" (which I think is what we discussed
before right?), or you can issue a specific OCSP responder certificate
for all/any CAs.
Regards,
Tomas
On 2019-07-30 22:41, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I was just able to get OCSP responses working with this CA/CRL, and I
> *think* that the answer was that EJBCA OCSP Responder did not like the
> *NAME* that I used/entered when I created the Certificate Authority in
> the EJBCA Adminweb!!!
>
> What I mean is the adminweb page with the URL
> https://XXXXX:8443/ejbca/adminweb/ca/editcas/editcas.jsp, where you use
> the "Import CA Certificate..." button.
>
> It appears that EJBCA OCSP Responder actually uses the "Name" value (and
> I guess that is what it hashes to get the name hash) to match the issuer
> on the incoming OCSP request.
>
> There seems to be SOME KIND OF RULE for that Name, but what is that
> rule, EXACTLY?
>
> My best guess is that that Name has to match the filename of the CA
> cert/PEM, EXACTLY, including the case of the filename, but NOT INCLUDING
> the file extension.
>
> In other words, if the CA cert PEM file is "joe_foo.pem", then you have
> to enter "joe_foo" for the Name field when creating the new CA in the
> Adminweb.
>
> And, "JOE_FOO" or "JoE_FoO" does not work... it has to be "joe_foo".
>
> Another example is if the CA cert PEM file is
> "This_is_mY_cert.crt.pem.crt", then, for the Name you enter when you
> create the CA in the Admin web, you have to enter:
>
> This_is_mY_cert.crt.pem
>
> Is that correct? Can anyone confirm what the actual Name string has to
> be?
>
> This is a kind of time killer... spent almost a whole day trying to
> figure this one out :(...
>
> Jim
>
>
>
> On Tuesday, July 30, 2019, 7:45:20 PM UTC, oh...@ya...
> <oh...@ya...> wrote:
>
>
> Also, FYI, here is the response I get when I test the OCSP request using
> "openssl ocsp":
>
> OCSP Request Data:
> Version: 1 (0x0)
> Requestor List:
> Certificate ID:
> Hash Algorithm: sha1
> Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD
> Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52
> Serial Number: 3732
> Request Extensions:
> OCSP Nonce:
> 04109186E755667555C98040988194088E5D
> Responder Error: unauthorized (6)
>
>
> NOTICE the "Responder Error: unauthorized (6)" error.
>
> I have even deleted the CA from EJBCA OCSP responder and then
> re-imported that CA's cert and the latest CRL and I am still getting the
> same error.
>
> Thanks,
> Jim
>
> On Tuesday, July 30, 2019, 4:37:49 PM UTC, oh...@ya...
> <oh...@ya...> wrote:
>
>
> Hi,
>
> I am circling back and trying to do some OCSP response testing with the
> EJBCA OCSP responder, but when I run "openssl ocsp" testing, I am
> getting an error (from the EJBCA logging):
>
> 16:25:35,230 INFO
> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean]
> (default task-7) Received OCSP request for certificate with serNo: 3a1b,
> and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip
> 192.168.xx.yy.
> 16:25:35,236 ERROR
> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean]
> (default task-7) Unable to find CA certificate by issuer name hash:
> dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder:
> CN=xxxx.
>
> I think that I have that CA imported into EJBCA and also the latest CRL.
>
> Is there a way to find out what that issuer name that it is looking for
> from the "issuer name hash"?
>
> I'm guessing there probably isn't, so how can I debug why it is not able
> to find the CA (and CRL from that CA) in EJBCA?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Tomas G. <to...@pr...> - 2019-07-31 08:12:22
|
No that is incorrect. The "Name" is not used for anything related to OCSP. The "Issuer Name Hash" as referenced in the log is defined in OCSP RFC 6960 and is based on the subject DN of the CA certificate. The Name you enter as name of the CA is an arbitrary string. Typically something like "My CA v1". In a debug log of EJBCA it will show regularly (first during startup) which CA certificates are loaded by EJBCA. Something like: 2019-07-31 10:08:32,086 DEBUG [org.cesecore.certificates.ca.internal.CaCertificateCache] (ServerService Thread Pool -- 78) Found the following CA certificates : CN=TestExportRemoveRestoreCA3,131F6952BCE09394 CN=TestServiceService_TestCA1,3BCF13B76E51DE31 CN=RenamedTestCA,4FE83A6F12880043 CN=TestServiceService_TestCA2,3301346766C4FF66 There is a cache time, and the CA certificate cache is reloaded as a time interval specified in cache.properties. Always during restart of course. When importing a new CA certificate, which is only an "External CA" and can not be used to answer OCSP queries, it takes some time before it appears in the cache. OCSP Key Binding are set up to answer queries for "External CAs", you can either use a "default responder" (which I think is what we discussed before right?), or you can issue a specific OCSP responder certificate for all/any CAs. Regards, Tomas On 2019-07-30 22:41, ohaya--- via Ejbca-develop wrote: > Hi, > > I was just able to get OCSP responses working with this CA/CRL, and I > *think* that the answer was that EJBCA OCSP Responder did not like the > *NAME* that I used/entered when I created the Certificate Authority in > the EJBCA Adminweb!!! > > What I mean is the adminweb page with the URL > https://XXXXX:8443/ejbca/adminweb/ca/editcas/editcas.jsp, where you use > the "Import CA Certificate..." button. > > It appears that EJBCA OCSP Responder actually uses the "Name" value (and > I guess that is what it hashes to get the name hash) to match the issuer > on the incoming OCSP request. > > There seems to be SOME KIND OF RULE for that Name, but what is that > rule, EXACTLY? > > My best guess is that that Name has to match the filename of the CA > cert/PEM, EXACTLY, including the case of the filename, but NOT INCLUDING > the file extension. > > In other words, if the CA cert PEM file is "joe_foo.pem", then you have > to enter "joe_foo" for the Name field when creating the new CA in the > Adminweb. > > And, "JOE_FOO" or "JoE_FoO" does not work... it has to be "joe_foo". > > Another example is if the CA cert PEM file is > "This_is_mY_cert.crt.pem.crt", then, for the Name you enter when you > create the CA in the Admin web, you have to enter: > > This_is_mY_cert.crt.pem > > Is that correct? Can anyone confirm what the actual Name string has to > be? > > This is a kind of time killer... spent almost a whole day trying to > figure this one out :(... > > Jim > > > > On Tuesday, July 30, 2019, 7:45:20 PM UTC, oh...@ya... > <oh...@ya...> wrote: > > > Also, FYI, here is the response I get when I test the OCSP request using > "openssl ocsp": > > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD > Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52 > Serial Number: 3732 > Request Extensions: > OCSP Nonce: > 04109186E755667555C98040988194088E5D > Responder Error: unauthorized (6) > > > NOTICE the "Responder Error: unauthorized (6)" error. > > I have even deleted the CA from EJBCA OCSP responder and then > re-imported that CA's cert and the latest CRL and I am still getting the > same error. > > Thanks, > Jim > > On Tuesday, July 30, 2019, 4:37:49 PM UTC, oh...@ya... > <oh...@ya...> wrote: > > > Hi, > > I am circling back and trying to do some OCSP response testing with the > EJBCA OCSP responder, but when I run "openssl ocsp" testing, I am > getting an error (from the EJBCA logging): > > 16:25:35,230 INFO > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (default task-7) Received OCSP request for certificate with serNo: 3a1b, > and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip > 192.168.xx.yy. > 16:25:35,236 ERROR > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (default task-7) Unable to find CA certificate by issuer name hash: > dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: > CN=xxxx. > > I think that I have that CA imported into EJBCA and also the latest CRL. > > Is there a way to find out what that issuer name that it is looking for > from the "issuer name hash"? > > I'm guessing there probably isn't, so how can I debug why it is not able > to find the CA (and CRL from that CA) in EJBCA? > > Thanks, > Jim > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: <oh...@ya...> - 2019-07-30 20:41:29
|
Hi,
I was just able to get OCSP responses working with this CA/CRL, and I *think* that the answer was that EJBCA OCSP Responder did not like the *NAME* that I used/entered when I created the Certificate Authority in the EJBCA Adminweb!!!
What I mean is the adminweb page with the URL https://XXXXX:8443/ejbca/adminweb/ca/editcas/editcas.jsp, where you use the "Import CA Certificate..." button.
It appears that EJBCA OCSP Responder actually uses the "Name" value (and I guess that is what it hashes to get the name hash) to match the issuer on the incoming OCSP request.
There seems to be SOME KIND OF RULE for that Name, but what is that rule, EXACTLY?
My best guess is that that Name has to match the filename of the CA cert/PEM, EXACTLY, including the case of the filename, but NOT INCLUDING the file extension.
In other words, if the CA cert PEM file is "joe_foo.pem", then you have to enter "joe_foo" for the Name field when creating the new CA in the Adminweb.
And, "JOE_FOO" or "JoE_FoO" does not work... it has to be "joe_foo".
Another example is if the CA cert PEM file is "This_is_mY_cert.crt.pem.crt", then, for the Name you enter when you create the CA in the Admin web, you have to enter:
This_is_mY_cert.crt.pem
Is that correct? Can anyone confirm what the actual Name string has to be?
This is a kind of time killer... spent almost a whole day trying to figure this one out :(...
Jim
On Tuesday, July 30, 2019, 7:45:20 PM UTC, oh...@ya... <oh...@ya...> wrote:
Also, FYI, here is the response I get when I test the OCSP request using "openssl ocsp":
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD
Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52
Serial Number: 3732
Request Extensions:
OCSP Nonce:
04109186E755667555C98040988194088E5D
Responder Error: unauthorized (6)
NOTICE the "Responder Error: unauthorized (6)" error.
I have even deleted the CA from EJBCA OCSP responder and then re-imported that CA's cert and the latest CRL and I am still getting the same error.
Thanks,Jim
On Tuesday, July 30, 2019, 4:37:49 PM UTC, oh...@ya... <oh...@ya...> wrote:
Hi,
I am circling back and trying to do some OCSP response testing with the EJBCA OCSP responder, but when I run "openssl ocsp" testing, I am getting an error (from the EJBCA logging):
16:25:35,230 INFO [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-7) Received OCSP request for certificate with serNo: 3a1b, and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip 192.168.xx.yy.
16:25:35,236 ERROR [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-7) Unable to find CA certificate by issuer name hash: dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: CN=xxxx.
I think that I have that CA imported into EJBCA and also the latest CRL.
Is there a way to find out what that issuer name that it is looking for from the "issuer name hash"?
I'm guessing there probably isn't, so how can I debug why it is not able to find the CA (and CRL from that CA) in EJBCA?
Thanks,Jim
|
106 messages has been excluded from this view by a project administrator.
