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: Manuel D. <ma...@de...> - 2014-11-30 13:32:32
|
Hi, On Sun, Nov 30, 2014 at 6:18 AM, Eilaf Essam <eil...@ho...> wrote: > Hi, i used this command : > ./ejbcaClientToolBox.sh PKCS11HSMKeyTool generate > /root/Utimaco/libcs_pkcs11_R2.so 1024 signKey 0 > > slot 0 is already initialized and with so pin and user pin. I recommend you try adding the user PIN to the tool with "-password thePIN" ~manuel |
|
From: Eilaf E. <eil...@ho...> - 2014-11-30 05:18:26
|
Hi, i used this command : ./ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /root/Utimaco/libcs_pkcs11_R2.so 1024 signKey 0 slot 0 is already initialized and with so pin and user pin. Date: Fri, 28 Nov 2014 16:05:45 +0100 From: br...@ma... To: ejb...@li... Subject: Re: [Ejbca-develop] error generating keys using clientToolBox On Thu, 27 Nov 2014 16:22:06 +0400 Eilaf Essam <eil...@ho...> wrote: > Hi, > I am trying to generate keys on utimaco HSM using ejbca clientToolBox, > I > am using ejbca 6.2.0 with jboss7 and java 1.7 , I used the same > configuration on ejbca 6.0.4 with jboss7 and java 1.6 and everything > worked perfectly, but now with ejbca 6.2.0 I am getting this error: > > ERROR > [org.ejbca.ui.cli.HSMKeyTool] Command 'PKCS11HSMKeyTool generate > /root/Utimaco/libcs_pkcs11_R2.so null pkcs11 1024 key 0' could not be > executed. > java.security.ProviderException: Initialization failed > at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:311) > at sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java:392) > at java.security.Signature$Delegate.engineInitSign(Signature.java:1127) > at java.security.Signature.initSign(Signature.java:511) > at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source) > at org.ejbca.util.keystore.KeyStoreContainerBase.getSelfCertificate(KeyStoreContainerBase.java:136) > at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:308) > at org.ejbca.util.keystore.KeyStoreContainerBase.generateRSA(KeyStoreContainerBase.java:201) > at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:236) > at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:213) > at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:453) > at org.ejbca.ui.cli.PKCS11HSMKeyTool.execute(PKCS11HSMKeyTool.java:47) > at org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) > at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:66) > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OBJECT_HANDLE_INVALID > at sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method) > at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:303) > ... 13 more > > I > am not sure this problem is related to ejbca or openjdk, could u please > tell me how what could be causing the problem and how i can solve it > > Thanks for your time. > Eilaf Essam What was the exact command you used? Best regards -- Branko Majic Jabber: br...@ma... Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: br...@ma... Молим вас да додатке шаљете искључиво у слободним форматима. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Ejbca-develop mailing list Ejb...@li... https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Michael S. <mi...@st...> - 2014-11-28 15:09:26
|
Branko Majic <br...@ma...> wrote > If you are using GUI, there's an activate (iirc) button on the page > with OCSP key bindings as well. Thanks for your reply. Yes, I know. But I'm writing a small how-to for admins describing the setup of a stand-alone OCSP responder. And most actions should be automated possibly via puppet/exec. Ciao, Michael. |
|
From: Branko M. <br...@ma...> - 2014-11-28 15:05:57
|
On Thu, 27 Nov 2014 16:22:06 +0400 Eilaf Essam <eil...@ho...> wrote: > Hi, > I am trying to generate keys on utimaco HSM using ejbca clientToolBox, > I > am using ejbca 6.2.0 with jboss7 and java 1.7 , I used the same > configuration on ejbca 6.0.4 with jboss7 and java 1.6 and everything > worked perfectly, but now with ejbca 6.2.0 I am getting this error: > > ERROR > [org.ejbca.ui.cli.HSMKeyTool] Command 'PKCS11HSMKeyTool generate > /root/Utimaco/libcs_pkcs11_R2.so null pkcs11 1024 key 0' could not be > executed. > java.security.ProviderException: Initialization failed > at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:311) > at sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java:392) > at java.security.Signature$Delegate.engineInitSign(Signature.java:1127) > at java.security.Signature.initSign(Signature.java:511) > at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source) > at org.ejbca.util.keystore.KeyStoreContainerBase.getSelfCertificate(KeyStoreContainerBase.java:136) > at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:308) > at org.ejbca.util.keystore.KeyStoreContainerBase.generateRSA(KeyStoreContainerBase.java:201) > at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:236) > at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:213) > at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:453) > at org.ejbca.ui.cli.PKCS11HSMKeyTool.execute(PKCS11HSMKeyTool.java:47) > at org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40) > at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:66) > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OBJECT_HANDLE_INVALID > at sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method) > at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:303) > ... 13 more > > I > am not sure this problem is related to ejbca or openjdk, could u please > tell me how what could be causing the problem and how i can solve it > > Thanks for your time. > Eilaf Essam What was the exact command you used? Best regards -- Branko Majic Jabber: br...@ma... Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: br...@ma... Молим вас да додатке шаљете искључиво у слободним форматима. |
|
From: Branko M. <br...@ma...> - 2014-11-28 15:04:05
|
If you are using GUI, there's an activate (iirc) button on the page with OCSP key bindings as well. Best regards On Fri, 28 Nov 2014 14:11:49 +0100 "Michael Ströder" <mi...@st...> wrote: > It turned out that this command has to be used at the *end*: > > /opt/ejbca/bin/ejbca.sh keybind setstatus --name KB_OCSP_Server_1 -v ACTIVE > > Ciao, Michael. > > On Thu, 27 Nov 2014 13:30:10 +0100 "Michael Ströder" <mi...@st...> > wrote > > > Tomas Gustavsson <to...@pr...> wrote: > > > > > > CA certificates are loaded (by type) at startup. The responder will log > > > during startup which CA certificates it finds. The hashes are calculated > > > and looked up in this cache (which is refreshed now and then), so no db > > > lookup for hashes. > > > > How can I see which issuer name/key hashes are currently in the cache? > > If I hit [Clear All Caches] is there a forced re-load of the OCSP responder's > > cache? > > > > It seems the CAs are loaded (see below) but it does not work. > > > > I've initialized completely with ejbca.sh (see below). > > > > But in the adminweb the links from the OCSPKeyBinding to the CA cert and the > > OCSP responder cert result in 404. > > The Crypto Token does work when hitting [Test]. > > > > I can easily send the log_statement output of the postgresql DB server if > > that would help. > > > > Ciao, Michael. > > > > --------------------------- setup commands --------------------------- > > > > cd /opt/ejbca > > ant clientToolBox > > > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname Interims-CA -f > > /opt/ejbca/p12/Interims-CA.crt > > /opt/ejbca/bin/ejbca.sh ca importcert --caname Interims-CA -f > > /opt/ejbca/p12/superadmin.crt --username superadmin --password null -a ACTIVE > > --certprofile ENDUSER --eeprofile EMPTY > > /opt/ejbca/bin/ejbca.sh roles addadmin --role "Super Administrator Role" > > --caname "Interims-CA" --with WITH_COMMONNAME --type TYPE_EQUALCASE --value > > "SuperAdmin" > > > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Root-CA-1-2014-10 -f > > p12/TestRootCA1201410.cacert.pem > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Admin-CA-1-2014-10 > > -f p12/TestAdminCA1201410.pem > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Email-CA-1-2014-10 > > -f p12/TestEmailCA1201410.pem > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Server-CA-1-2014-10 > > -f p12/TestServerCA1201410.pem > > > > /opt/ejbca/bin/ejbca.sh ca editca --caname CA_Test-Server-CA-1-2014-10 > > --field externalCdp --value > > 'http://vm-ejbca-ca-03.example.com:8080/ejbca/publicweb/webdist/certdist?cmd= > > crl&issuer=CN%3dTest+Server-CA+%231+2014-10%2cOU%3dITO%2cC%3dDE' [..] > > > > /opt/ejbca/bin/ejbca.sh cryptotoken create --token CT_OCSP1 --type > > SoftCryptoToken --autoactivate true --pin null > > /opt/ejbca/bin/ejbca.sh cryptotoken generatekey --token CT_OCSP1 --alias > > privatesignkeyalias --keyspec 2048 > > > > /opt/ejbca/bin/ejbca.sh keybind create --name KB_OCSP_Server_1 --token > > CT_OCSP1 --type OcspKeyBinding --alias privatesignkeyalias --sigalg > > SHA1WithRSA --verbose --status ACTIVE --cert null > > /opt/ejbca/bin/ejbca.sh keybind setstatus --name KB_OCSP_Server_1 -v ACTIVE > > /opt/ejbca/bin/ejbca.sh keybind gencsr --name KB_OCSP_Server_1 -f > > /opt/ejbca/p12/KB_OCSP_Server_1.csr --verbose > > > > /opt/ejbca/dist/clientToolBox/ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req > > ocsp-server-ca-vm-ejbca-ocsp-01 secret p12/KB_OCSP_Server_1.csr PEM NONE > > /opt/ejbca/p12/ > > > > /opt/ejbca/bin/ejbca.sh keybind import --name KB_OCSP_Server_1 -f > > /opt/ejbca/p12/ocsp-server-ca-vm-ejbca-ocsp-01.pem --verbose > > > > ------------------------- startup log ------------------------- > > > > 13:07:51,667 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > > service thread 1-3) Initialized CA: Interims-CA, with expire time: Mon Oct 07 > > 16:16:51 CEST 2024 > > 13:07:51,729 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > > service thread 1-3) Initialized CA: CA_Test-Server-CA-1-2014-10, with expire > > time: Fri Nov 27 10:58:12 CET 2015 > > 13:07:51,782 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > > service thread 1-3) Initialized CA: CA_Test-Email-CA-1-2014-10, with expire > > time: Fri Oct 16 14:12:58 CEST 2015 > > 13:07:51,835 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > > service thread 1-3) Initialized CA: CA_Test-Admin-CA-1-2014-10, with expire > > time: Wed Oct 14 14:27:58 CEST 2015 > > 13:07:51,865 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > > service thread 1-3) Initialized CA: CA_Test-Root-CA-1-2014-10, with expire > > time: Sun Oct 02 17:49:53 CEST 2016 > > 13:07:51,901 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > > thread 1-3) Registered audit device using implementation: > > org.cesecore.audit.impl.log4j.Log4jDevice > > 13:07:51,903 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > > thread 1-3) Configured exporter AuditExporterDummy for device Log4jDevice > > 13:07:51,904 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > > thread 1-3) Registered audit device using implementation: > > org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice > > 13:07:51,905 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > > thread 1-3) Configured exporter AuditExporterXml for device > > IntegrityProtectedDevice 13:07:51,916 INFO > > [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) > > 2014-11-27 > > 13:07:51+01:00;EJBCA_STARTING;SUCCESS;SERVICE;EJBCA;StartServicesServlet.init > > ;;vm-ejbca-ocsp-01.example.com;;msg=Init, EJBCA 6.3.0Alpha (working copy) > > startup. 13:07:52,022 INFO > > [org.ejbca.ui.web.admin.configuration.StartServicesServlet] (MSC service > > thread 1-3) No database integrity protection available in this version of > > EJBCA. 13:07:52,025 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC > > service thread 1-3) 2014-11-27 > > 13:07:52+01:00;LOG_MANAGEMENT_CHANGE;VOID;SECURITY_AUDIT;CORE;StartServicesSe > > rvlet.init;;;;msg=No integrity protected security audit logger devices > > configured. 13:07:52,095 INFO > > [org.ejbca.core.ejb.authorization.ComplexAccessControlSessionBean] (MSC > > service thread 1-3) Roles or CAs exist, not intializing Super Administrator > > Role 13:07:52,228 INFO > > [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (MSC > > service thread 1-3) Custom certificate serial number not allowed since there > > is no unique index on (issuerDN,serialNumber) on the 'CertificateData' table. > > 13:07:52,258 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service > > thread 1-3) 2014-11-27 > > 13:07:52+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;StartServicesServlet > > .init;;;;resource0=/ 13:07:52,272 INFO > > [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) > > 2014-11-27 > > 13:07:52+01:00;SYSTEMCONF_EDIT;SUCCESS;GLOBALCONF;CORE;StartServicesServlet.i > > nit;;;;msg=Saved global configuration with id OCSP. > > 13:07:52,431 INFO [org.cesecore.certificates.ocsp.cache.OcspSigningCache] > > (MSC service thread 1-3) No default responder was defined. OCSP requests for > > certificates issued by unknown CAs will return "unauthorized" as per RFC6960, > > Section 2.3 > > 13:07:52,443 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: > > Registering web context: /ejbca/adminweb > > 13:07:52,449 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015951: Admin > > console listening on http://127.0.0.1:9990 > > 13:07:52,450 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015874: JBoss > > AS 7.1.1.Final "Brontes" started in 16617ms - Started 2454 of 2569 services > > (112 services are passive or on-demand) > > 13:07:52,513 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) > > JBAS018559: Deployed "ejbca.ear" > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop -- Branko Majic Jabber: br...@ma... Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: br...@ma... Молим вас да додатке шаљете искључиво у слободним форматима. |
|
From: Branko M. <br...@ma...> - 2014-11-28 15:01:54
|
On Wed, 26 Nov 2014 15:35:24 +0100 "Michael Ströder" <mi...@st...> wrote: > HI! > > I'm having a hard time finding out why sometimes (not always) ejbca.sh is so > damn slow: > > root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help > [..] > real 0m2.251s > user 0m2.748s > sys 0m0.288s > root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help > [..] > real 0m25.008s > user 0m18.069s > sys 0m0.192s > > I'm looking with strace and tcpdump what's going on. But still nothing obvious. > > Which debug logs should I enable in the JVM? > > BTW: Any reason why using --help requires a running JBOSS? > > Ciao, Michael. > In some cases CLI will try to obtain some values from the CA for display of help, like certificate names, CA names etc. This is the main reason CLI connects to running EJBCA. As for slowness/speed, I've noticed myself that first run of CLI tools after JBoss has been restarted might take a bit more time, while subsequent runs seems to be much faster. One thing to think about would be perhaps reverse DNS (if anything does DNS lookups when using CLI, which I kind of doubt). Best regards -- Branko Majic Jabber: br...@ma... Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: br...@ma... Молим вас да додатке шаљете искључиво у слободним форматима. |
|
From: Branko M. <br...@ma...> - 2014-11-28 14:59:16
|
On Mon, 24 Nov 2014 12:52:47 +0000 Michael Postmann <M.P...@pa...> wrote: > Hi! > > In our setup we have a root CA which singed two intermediate CA's which then sign some client and webserver certificates to be used internally and by our clients. For reasons of security, we want to remove the root CA from the server, as soon as the intermediate CAs are signed. The root CA will be stored in physical safe so we have it available in case we need it again. > > So if I just remove the RootCA from "ejbca" will key verification up the issuer chain and similar stuff be still possible? Could I later just add the key again to EJBCA if I e.g. need to revoke the key or sign another intermediate CA? > > cheers > > nomike > The simplest thing would be to keep root CA on a separate server. This server would be offline, eventually connected to one admin workstation. Otherwise, you could try making the key material for root CA stored on an HSM that you need to plug-in into the machine etc. I.e. make it available only when explicitly needed. Keep in mind, though, that someone could crack your CA server, deploy some payload to wait for the root CA key to be usable, and then sign whatever they need. So, in general, offline root CA is the best practice for most scenarios. If you _remove_ root CA from EJBCA, you would need to import it via CLI later on if you want to use it. This is not the most common thing to do. You can always import the root CA certificate as external CA into the system if you need the chain, btw. Best regards -- Branko Majic Jabber: br...@ma... Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: br...@ma... Молим вас да додатке шаљете искључиво у слободним форматима. |
|
From: Тимур <tim...@gm...> - 2014-11-28 14:58:10
|
Tomas, thank you for your prompt. ca.tokenproperties has been commented and "ant install" has passed successfully ! Regards, Timur 2014-11-28 19:59 GMT+06:00 Tomas Gustavsson <to...@pr...>: > > ca.tokenproperties is incorrectly configured. As you are using soft > keystore, you should not even set this property. > > It's better if you adress questions to the comunity, as I will not be able > to answer questions personally. > > Regards, > Tomas > ********** > PrimeKey Solutions AB > Anderstorpsvägen 16, 171 54 Solna, Sweden > Mob: +46 (0)707421096 > Internet: www.primekey.se > Twitter: twitter.com/primekeyPKI > ********** > > On 2014-11-28 13:55, Тимур wrote: > >> Thank you for answer, Tomas. >> Before opening request to you I have looked through all config files in >> EJBCA conf folder - they are the same like I did for EJBCA 6.1.1 which >> was installed successfully (only difference in configs is that I have to >> double-quoted all string parameters in install.properties after "ant >> install" generated this error). Could you please to check uploaded >> install.properties by fresh look ? >> >> 2014-11-28 18:40 GMT+06:00 Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...>>: >> >> Looks like some misconfiguration, perhaps in install properties. The >> path with /conf looks strange. >> >> Cheers, >> Tomas >> >> "Тимур" <tim...@gm... <mailto:tim...@gm...>> >> skrev: (28 november 2014 13:04:31 CET) >> >Hello, >> > >> >I'm in the process of EJBCA 6.2.0 installation (RHEL 5.7, Oracle >> Java >> >7, >> >JBoss AS 7.1.1.Final); >> >"ant deploy" is fine but and at "ant install" time I get the >> following >> >error: >> > >> > >> >ejbca:initCA: >> > [echo] Initializing CA with '"ManagementCA"' >> '"CN=ManagementCA,O=EJBCA >> >Test,C=BTA"' '"soft"' <ca.tokenpassword hidden> '1024' '"RSA"' >> '3650' >> >'null' '"SHA1WithRSA"' "/u01/ejbca/ejbca_ce_6_2_0/conf" >> -certprofile >> >"ROOTCA" -superadmincn 'SuperAdmin'... >> > [java] SETTING: --caname as ManagementCA >> > [java] SETTING: --dn as CN=ManagementCA,O=EJBCA Test,C=BTA >> > [java] SETTING: --tokenType as soft >> > [java] SETTING: --tokenPass as null >> > [java] SETTING: --keyspec as 1024 >> > [java] SETTING: --keytype as RSA >> > [java] SETTING: -v as 3650 >> > [java] SETTING: --policy as null >> > [java] SETTING: -s as SHA1WithRSA >> > [java] SETTING: -certprofile as ROOTCA >> > [java] SETTING: -superadmincn as SuperAdmin >> > [java] ERROR: Incorrect parameter usage. >> > [java] The following arguments are unknown: >> > [java] /u01/ejbca/ejbca_ce_6_2_0/conf >> > [java] >> > [java] Run command with "--help" to see full manual page. >> > >> >-------- >> > >> >After getting this error I double-quoted all string parameters in >> >install.properties file (as it's advised by >> >http://sourceforge.net/p/ejbca/discussion/123123/thread/e0044089) >> but >> >no >> >result. >> >Also I have tried with single-quotes but the trouble still persists. >> >Could you please to advice how to resolve this trouble. >> > >> >thank you, Timur. >> > >> > >> >2014-09-17 13:05 GMT+06:00 Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...>>: >> > >> >> >> >> You need to uncheck "enforce unique public keys" for the CA. >> >> >> >> Cheers, >> >> Tomas >> >> >> >> On 2014-09-17 08:38, Ebtehal Hassan wrote: >> >> > Hello, >> >> > I want make stress test for CA in EJBCA v. 6.2.0 but it can be >> >issued >> >> > just 1 certificate & after that the JBOSS was get some error >> >> > the command to stress test >> >> > Now the stress test show some result: >> >> > >> >> > >> >> > Server@ca2:/opt/ejbca/dist/clientToolBox$ >> ./ejbcaClientToolBox.sh >> >> > EjbcaWsRaCli stress AdminCA >> >> > Test client started, tail info and error files in this directory >> >for >> >> output. >> >> > Statistic will be written to standard output each 10 second. >> >> > The test was started at Thu Sep 14 20:03:33 CEST 2011.008332292 >> >> > A test key for each thread is generated. This could take some >> time >> >if >> >> > you have specified many threads and long keys. >> >> > Total # of successfully performed tests: 1 >> >> > Total # of failed tests: 30 >> >> > # of tests completed each second: 0.1 >> >> > # of tests completed each second in last period: 0.1 >> >> > Relative average time for different tasks (all should sum up >> to 1): >> >> > Relative time spent registring new users: 0.4267 >> >> > Relative time spent signing certificates: 0.0395 >> >> > Time spent with test client work: 0.5338 >> >> > Absolute extremes: >> >> > Min time for job 'Relative time spent registring new users' >> (ms): >> >114 >> >> > (Thu Sep 14 20:03:42 CEST 2011) >> >> > Max time per job 'Relative time spent registring new users' >> (ms): >> >186 >> >> > (Thu Sep 14 20:03:33 CEST 2011) >> >> > Min time for job 'Relative time spent signing certificates' >> (ms): >> >395 >> >> > (Thu Sep 14 20:03:34 CEST 2011) >> >> > Max time per job 'Relative time spent signing certificates' >> (ms): >> >395 >> >> > (Thu Sep 14 20:03:34 CEST 2011) >> >> > >> >> > >> >> > In th JBOSS log i see this: >> >> > Thu Sep 14 20:04:01 CEST 2011 : Command failure. Class >> >> > >> >> >> >'org.ejbca.core.protocol.ws.client.StressTestCommand. >> Pkcs10RequestCommand' >> >> > with this job data: Username 'WSTESTUSER-5377453774162515311' >> with >> >> > password 'foo123'. >> >> > org.ejbca.core.protocol.ws.client.gen.EjbcaException_Exception: >> >User >> >> > 'WSTESTUSER-5377453774162515311' is not allowed to use same >> key as >> >the >> >> > user(s) 'WSTESTUSER8587251972754523283' is/are using. >> >> > at >> >> > sun.reflect.GeneratedConstructorAccessor42.newInstance(Unknown >> >Source) >> >> > at >> >> > >> >> >> >sun.reflect.DelegatingConstructorAccessorImpl.newInstance( >> DelegatingConstructorAccessorImpl.java:45) >> >> > at >> >> java.lang.reflect.Constructor.newInstance(Constructor.java:532) >> >> > at >> >> > >> >> >> >com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException( >> SOAPFaultBuilder.java:130) >> >> > at >> >> > >> >> >> >com.sun.xml.internal.ws.client.sei.SyncMethodHandler. >> invoke(SyncMethodHandler.java:108) >> >> > at >> >> > >> >> >> >com.sun.xml.internal.ws.client.sei.SyncMethodHandler. >> invoke(SyncMethodHandler.java:78) >> >> > at >> >> > >> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) >> >> > at $Proxy27.pkcs10Request(Unknown Source) >> >> > >> >> > >> >> > >> >> > Please help me to solve the problem >> >> > >> >> > >> >> > Best Regards; >> >> > Ebtehal Hassan >> >> > >> >> > >> >> > >> >> >> >----------------------------------------------------------- >> ------------------- >> >> > Want excitement? >> >> > Manually upgrade your production database. >> >> > When you want reliability, choose Perforce >> >> > Perforce version control. Predictably reliable. >> >> > >> >> >> >http://pubads.g.doubleclick.net/gampad/clk?id=157508191& >> iu=/4140/ostg.clktrk >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Ejbca-develop mailing list >> >> > Ejb...@li... >> <mailto:Ejb...@li...> >> >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> > >> >> >> >> >> >> >> >----------------------------------------------------------- >> ------------------- >> >> Want excitement? >> >> Manually upgrade your production database. >> >> When you want reliability, choose Perforce >> >> Perforce version control. Predictably reliable. >> >> >> >> >> >http://pubads.g.doubleclick.net/gampad/clk?id=157508191& >> iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> Ejbca-develop mailing list >> >> Ejb...@li... >> <mailto:Ejb...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> > >> > >> >----------------------------------------------------------- >> ------------- >> > >> >----------------------------------------------------------- >> ------------------- >> >Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> >from Actuate! Instantly Supercharge Your Business Reports and >> >Dashboards >> >with Interactivity, Sharing, Native Excel Exports, App Integration & >> >more >> >Get technology previously reserved for billion-dollar corporations, >> >FREE >> >http://pubads.g.doubleclick.net/gampad/clk?id=157005751& >> iu=/4140/ostg.clktrk >> > >> >----------------------------------------------------------- >> ------------- >> > >> >_______________________________________________ >> >Ejbca-develop mailing list >> >Ejb...@li... >> <mailto:Ejb...@li...> >> >https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> |
|
From: Michael S. <mi...@st...> - 2014-11-28 13:15:21
|
It turned out that this command has to be used at the *end*: /opt/ejbca/bin/ejbca.sh keybind setstatus --name KB_OCSP_Server_1 -v ACTIVE Ciao, Michael. On Thu, 27 Nov 2014 13:30:10 +0100 "Michael Ströder" <mi...@st...> wrote > Tomas Gustavsson <to...@pr...> wrote: > > > > CA certificates are loaded (by type) at startup. The responder will log > > during startup which CA certificates it finds. The hashes are calculated > > and looked up in this cache (which is refreshed now and then), so no db > > lookup for hashes. > > How can I see which issuer name/key hashes are currently in the cache? > If I hit [Clear All Caches] is there a forced re-load of the OCSP responder's > cache? > > It seems the CAs are loaded (see below) but it does not work. > > I've initialized completely with ejbca.sh (see below). > > But in the adminweb the links from the OCSPKeyBinding to the CA cert and the > OCSP responder cert result in 404. > The Crypto Token does work when hitting [Test]. > > I can easily send the log_statement output of the postgresql DB server if > that would help. > > Ciao, Michael. > > --------------------------- setup commands --------------------------- > > cd /opt/ejbca > ant clientToolBox > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname Interims-CA -f > /opt/ejbca/p12/Interims-CA.crt > /opt/ejbca/bin/ejbca.sh ca importcert --caname Interims-CA -f > /opt/ejbca/p12/superadmin.crt --username superadmin --password null -a ACTIVE > --certprofile ENDUSER --eeprofile EMPTY > /opt/ejbca/bin/ejbca.sh roles addadmin --role "Super Administrator Role" > --caname "Interims-CA" --with WITH_COMMONNAME --type TYPE_EQUALCASE --value > "SuperAdmin" > > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Root-CA-1-2014-10 -f > p12/TestRootCA1201410.cacert.pem > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Admin-CA-1-2014-10 > -f p12/TestAdminCA1201410.pem > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Email-CA-1-2014-10 > -f p12/TestEmailCA1201410.pem > /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Server-CA-1-2014-10 > -f p12/TestServerCA1201410.pem > > /opt/ejbca/bin/ejbca.sh ca editca --caname CA_Test-Server-CA-1-2014-10 > --field externalCdp --value > 'http://vm-ejbca-ca-03.example.com:8080/ejbca/publicweb/webdist/certdist?cmd= > crl&issuer=CN%3dTest+Server-CA+%231+2014-10%2cOU%3dITO%2cC%3dDE' [..] > > /opt/ejbca/bin/ejbca.sh cryptotoken create --token CT_OCSP1 --type > SoftCryptoToken --autoactivate true --pin null > /opt/ejbca/bin/ejbca.sh cryptotoken generatekey --token CT_OCSP1 --alias > privatesignkeyalias --keyspec 2048 > > /opt/ejbca/bin/ejbca.sh keybind create --name KB_OCSP_Server_1 --token > CT_OCSP1 --type OcspKeyBinding --alias privatesignkeyalias --sigalg > SHA1WithRSA --verbose --status ACTIVE --cert null > /opt/ejbca/bin/ejbca.sh keybind setstatus --name KB_OCSP_Server_1 -v ACTIVE > /opt/ejbca/bin/ejbca.sh keybind gencsr --name KB_OCSP_Server_1 -f > /opt/ejbca/p12/KB_OCSP_Server_1.csr --verbose > > /opt/ejbca/dist/clientToolBox/ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req > ocsp-server-ca-vm-ejbca-ocsp-01 secret p12/KB_OCSP_Server_1.csr PEM NONE > /opt/ejbca/p12/ > > /opt/ejbca/bin/ejbca.sh keybind import --name KB_OCSP_Server_1 -f > /opt/ejbca/p12/ocsp-server-ca-vm-ejbca-ocsp-01.pem --verbose > > ------------------------- startup log ------------------------- > > 13:07:51,667 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > service thread 1-3) Initialized CA: Interims-CA, with expire time: Mon Oct 07 > 16:16:51 CEST 2024 > 13:07:51,729 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > service thread 1-3) Initialized CA: CA_Test-Server-CA-1-2014-10, with expire > time: Fri Nov 27 10:58:12 CET 2015 > 13:07:51,782 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > service thread 1-3) Initialized CA: CA_Test-Email-CA-1-2014-10, with expire > time: Fri Oct 16 14:12:58 CEST 2015 > 13:07:51,835 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > service thread 1-3) Initialized CA: CA_Test-Admin-CA-1-2014-10, with expire > time: Wed Oct 14 14:27:58 CEST 2015 > 13:07:51,865 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC > service thread 1-3) Initialized CA: CA_Test-Root-CA-1-2014-10, with expire > time: Sun Oct 02 17:49:53 CEST 2016 > 13:07:51,901 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > thread 1-3) Registered audit device using implementation: > org.cesecore.audit.impl.log4j.Log4jDevice > 13:07:51,903 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > thread 1-3) Configured exporter AuditExporterDummy for device Log4jDevice > 13:07:51,904 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > thread 1-3) Registered audit device using implementation: > org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice > 13:07:51,905 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service > thread 1-3) Configured exporter AuditExporterXml for device > IntegrityProtectedDevice 13:07:51,916 INFO > [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) > 2014-11-27 > 13:07:51+01:00;EJBCA_STARTING;SUCCESS;SERVICE;EJBCA;StartServicesServlet.init > ;;vm-ejbca-ocsp-01.example.com;;msg=Init, EJBCA 6.3.0Alpha (working copy) > startup. 13:07:52,022 INFO > [org.ejbca.ui.web.admin.configuration.StartServicesServlet] (MSC service > thread 1-3) No database integrity protection available in this version of > EJBCA. 13:07:52,025 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC > service thread 1-3) 2014-11-27 > 13:07:52+01:00;LOG_MANAGEMENT_CHANGE;VOID;SECURITY_AUDIT;CORE;StartServicesSe > rvlet.init;;;;msg=No integrity protected security audit logger devices > configured. 13:07:52,095 INFO > [org.ejbca.core.ejb.authorization.ComplexAccessControlSessionBean] (MSC > service thread 1-3) Roles or CAs exist, not intializing Super Administrator > Role 13:07:52,228 INFO > [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (MSC > service thread 1-3) Custom certificate serial number not allowed since there > is no unique index on (issuerDN,serialNumber) on the 'CertificateData' table. > 13:07:52,258 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service > thread 1-3) 2014-11-27 > 13:07:52+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;StartServicesServlet > .init;;;;resource0=/ 13:07:52,272 INFO > [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) > 2014-11-27 > 13:07:52+01:00;SYSTEMCONF_EDIT;SUCCESS;GLOBALCONF;CORE;StartServicesServlet.i > nit;;;;msg=Saved global configuration with id OCSP. > 13:07:52,431 INFO [org.cesecore.certificates.ocsp.cache.OcspSigningCache] > (MSC service thread 1-3) No default responder was defined. OCSP requests for > certificates issued by unknown CAs will return "unauthorized" as per RFC6960, > Section 2.3 > 13:07:52,443 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: > Registering web context: /ejbca/adminweb > 13:07:52,449 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015951: Admin > console listening on http://127.0.0.1:9990 > 13:07:52,450 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015874: JBoss > AS 7.1.1.Final "Brontes" started in 16617ms - Started 2454 of 2569 services > (112 services are passive or on-demand) > 13:07:52,513 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) > JBAS018559: Deployed "ejbca.ear" |
|
From: Tomas G. <to...@pr...> - 2014-11-28 12:40:48
|
Looks like some misconfiguration, perhaps in install properties. The path with /conf looks strange. Cheers, Tomas "Тимур" <tim...@gm...> skrev: (28 november 2014 13:04:31 CET) >Hello, > >I'm in the process of EJBCA 6.2.0 installation (RHEL 5.7, Oracle Java >7, >JBoss AS 7.1.1.Final); >"ant deploy" is fine but and at "ant install" time I get the following >error: > > >ejbca:initCA: > [echo] Initializing CA with '"ManagementCA"' '"CN=ManagementCA,O=EJBCA >Test,C=BTA"' '"soft"' <ca.tokenpassword hidden> '1024' '"RSA"' '3650' >'null' '"SHA1WithRSA"' "/u01/ejbca/ejbca_ce_6_2_0/conf" -certprofile >"ROOTCA" -superadmincn 'SuperAdmin'... > [java] SETTING: --caname as ManagementCA > [java] SETTING: --dn as CN=ManagementCA,O=EJBCA Test,C=BTA > [java] SETTING: --tokenType as soft > [java] SETTING: --tokenPass as null > [java] SETTING: --keyspec as 1024 > [java] SETTING: --keytype as RSA > [java] SETTING: -v as 3650 > [java] SETTING: --policy as null > [java] SETTING: -s as SHA1WithRSA > [java] SETTING: -certprofile as ROOTCA > [java] SETTING: -superadmincn as SuperAdmin > [java] ERROR: Incorrect parameter usage. > [java] The following arguments are unknown: > [java] /u01/ejbca/ejbca_ce_6_2_0/conf > [java] > [java] Run command with "--help" to see full manual page. > >-------- > >After getting this error I double-quoted all string parameters in >install.properties file (as it's advised by >http://sourceforge.net/p/ejbca/discussion/123123/thread/e0044089) but >no >result. >Also I have tried with single-quotes but the trouble still persists. >Could you please to advice how to resolve this trouble. > >thank you, Timur. > > >2014-09-17 13:05 GMT+06:00 Tomas Gustavsson <to...@pr...>: > >> >> You need to uncheck "enforce unique public keys" for the CA. >> >> Cheers, >> Tomas >> >> On 2014-09-17 08:38, Ebtehal Hassan wrote: >> > Hello, >> > I want make stress test for CA in EJBCA v. 6.2.0 but it can be >issued >> > just 1 certificate & after that the JBOSS was get some error >> > the command to stress test >> > Now the stress test show some result: >> > >> > >> > Server@ca2:/opt/ejbca/dist/clientToolBox$ ./ejbcaClientToolBox.sh >> > EjbcaWsRaCli stress AdminCA >> > Test client started, tail info and error files in this directory >for >> output. >> > Statistic will be written to standard output each 10 second. >> > The test was started at Thu Sep 14 20:03:33 CEST 2011.008332292 >> > A test key for each thread is generated. This could take some time >if >> > you have specified many threads and long keys. >> > Total # of successfully performed tests: 1 >> > Total # of failed tests: 30 >> > # of tests completed each second: 0.1 >> > # of tests completed each second in last period: 0.1 >> > Relative average time for different tasks (all should sum up to 1): >> > Relative time spent registring new users: 0.4267 >> > Relative time spent signing certificates: 0.0395 >> > Time spent with test client work: 0.5338 >> > Absolute extremes: >> > Min time for job 'Relative time spent registring new users' (ms): >114 >> > (Thu Sep 14 20:03:42 CEST 2011) >> > Max time per job 'Relative time spent registring new users' (ms): >186 >> > (Thu Sep 14 20:03:33 CEST 2011) >> > Min time for job 'Relative time spent signing certificates' (ms): >395 >> > (Thu Sep 14 20:03:34 CEST 2011) >> > Max time per job 'Relative time spent signing certificates' (ms): >395 >> > (Thu Sep 14 20:03:34 CEST 2011) >> > >> > >> > In th JBOSS log i see this: >> > Thu Sep 14 20:04:01 CEST 2011 : Command failure. Class >> > >> >'org.ejbca.core.protocol.ws.client.StressTestCommand.Pkcs10RequestCommand' >> > with this job data: Username 'WSTESTUSER-5377453774162515311' with >> > password 'foo123'. >> > org.ejbca.core.protocol.ws.client.gen.EjbcaException_Exception: >User >> > 'WSTESTUSER-5377453774162515311' is not allowed to use same key as >the >> > user(s) 'WSTESTUSER8587251972754523283' is/are using. >> > at >> > sun.reflect.GeneratedConstructorAccessor42.newInstance(Unknown >Source) >> > at >> > >> >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> > at >> java.lang.reflect.Constructor.newInstance(Constructor.java:532) >> > at >> > >> >com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) >> > at >> > >> >com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) >> > at >> > >> >com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) >> > at >> > com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) >> > at $Proxy27.pkcs10Request(Unknown Source) >> > >> > >> > >> > Please help me to solve the problem >> > >> > >> > Best Regards; >> > Ebtehal Hassan >> > >> > >> > >> >------------------------------------------------------------------------------ >> > Want excitement? >> > Manually upgrade your production database. >> > When you want reliability, choose Perforce >> > Perforce version control. Predictably reliable. >> > >> >http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> > >> > >> > >> > _______________________________________________ >> > Ejbca-develop mailing list >> > Ejb...@li... >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > >> >> >> >------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> >> >http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >from Actuate! Instantly Supercharge Your Business Reports and >Dashboards >with Interactivity, Sharing, Native Excel Exports, App Integration & >more >Get technology previously reserved for billion-dollar corporations, >FREE >http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > >------------------------------------------------------------------------ > >_______________________________________________ >Ejbca-develop mailing list >Ejb...@li... >https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Тимур <tim...@gm...> - 2014-11-28 12:04:39
|
Hello,
I'm in the process of EJBCA 6.2.0 installation (RHEL 5.7, Oracle Java 7,
JBoss AS 7.1.1.Final);
"ant deploy" is fine but and at "ant install" time I get the following
error:
ejbca:initCA:
[echo] Initializing CA with '"ManagementCA"' '"CN=ManagementCA,O=EJBCA
Test,C=BTA"' '"soft"' <ca.tokenpassword hidden> '1024' '"RSA"' '3650'
'null' '"SHA1WithRSA"' "/u01/ejbca/ejbca_ce_6_2_0/conf" -certprofile
"ROOTCA" -superadmincn 'SuperAdmin'...
[java] SETTING: --caname as ManagementCA
[java] SETTING: --dn as CN=ManagementCA,O=EJBCA Test,C=BTA
[java] SETTING: --tokenType as soft
[java] SETTING: --tokenPass as null
[java] SETTING: --keyspec as 1024
[java] SETTING: --keytype as RSA
[java] SETTING: -v as 3650
[java] SETTING: --policy as null
[java] SETTING: -s as SHA1WithRSA
[java] SETTING: -certprofile as ROOTCA
[java] SETTING: -superadmincn as SuperAdmin
[java] ERROR: Incorrect parameter usage.
[java] The following arguments are unknown:
[java] /u01/ejbca/ejbca_ce_6_2_0/conf
[java]
[java] Run command with "--help" to see full manual page.
--------
After getting this error I double-quoted all string parameters in
install.properties file (as it's advised by
http://sourceforge.net/p/ejbca/discussion/123123/thread/e0044089) but no
result.
Also I have tried with single-quotes but the trouble still persists.
Could you please to advice how to resolve this trouble.
thank you, Timur.
2014-09-17 13:05 GMT+06:00 Tomas Gustavsson <to...@pr...>:
>
> You need to uncheck "enforce unique public keys" for the CA.
>
> Cheers,
> Tomas
>
> On 2014-09-17 08:38, Ebtehal Hassan wrote:
> > Hello,
> > I want make stress test for CA in EJBCA v. 6.2.0 but it can be issued
> > just 1 certificate & after that the JBOSS was get some error
> > the command to stress test
> > Now the stress test show some result:
> >
> >
> > Server@ca2:/opt/ejbca/dist/clientToolBox$ ./ejbcaClientToolBox.sh
> > EjbcaWsRaCli stress AdminCA
> > Test client started, tail info and error files in this directory for
> output.
> > Statistic will be written to standard output each 10 second.
> > The test was started at Thu Sep 14 20:03:33 CEST 2011.008332292
> > A test key for each thread is generated. This could take some time if
> > you have specified many threads and long keys.
> > Total # of successfully performed tests: 1
> > Total # of failed tests: 30
> > # of tests completed each second: 0.1
> > # of tests completed each second in last period: 0.1
> > Relative average time for different tasks (all should sum up to 1):
> > Relative time spent registring new users: 0.4267
> > Relative time spent signing certificates: 0.0395
> > Time spent with test client work: 0.5338
> > Absolute extremes:
> > Min time for job 'Relative time spent registring new users' (ms): 114
> > (Thu Sep 14 20:03:42 CEST 2011)
> > Max time per job 'Relative time spent registring new users' (ms): 186
> > (Thu Sep 14 20:03:33 CEST 2011)
> > Min time for job 'Relative time spent signing certificates' (ms): 395
> > (Thu Sep 14 20:03:34 CEST 2011)
> > Max time per job 'Relative time spent signing certificates' (ms): 395
> > (Thu Sep 14 20:03:34 CEST 2011)
> >
> >
> > In th JBOSS log i see this:
> > Thu Sep 14 20:04:01 CEST 2011 : Command failure. Class
> >
> 'org.ejbca.core.protocol.ws.client.StressTestCommand.Pkcs10RequestCommand'
> > with this job data: Username 'WSTESTUSER-5377453774162515311' with
> > password 'foo123'.
> > org.ejbca.core.protocol.ws.client.gen.EjbcaException_Exception: User
> > 'WSTESTUSER-5377453774162515311' is not allowed to use same key as the
> > user(s) 'WSTESTUSER8587251972754523283' is/are using.
> > at
> > sun.reflect.GeneratedConstructorAccessor42.newInstance(Unknown Source)
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > at
> java.lang.reflect.Constructor.newInstance(Constructor.java:532)
> > at
> >
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130)
> > at
> >
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> > at
> >
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> > at
> > com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> > at $Proxy27.pkcs10Request(Unknown Source)
> >
> >
> >
> > Please help me to solve the problem
> >
> >
> > Best Regards;
> > Ebtehal Hassan
> >
> >
> >
> ------------------------------------------------------------------------------
> > Want excitement?
> > Manually upgrade your production database.
> > When you want reliability, choose Perforce
> > Perforce version control. Predictably reliable.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|
|
From: Tomas G. <to...@pr...> - 2014-11-27 19:03:31
|
Absolutely, would be a cool feature. Patches would be ideal :-) Cheers, Tomas On 2014-11-27 18:53, Michael Ströder wrote: > HI! > > It would be nice if besides input field "External CRL Distribution Point" there > would be a [Test] button for downloading and validating the CRL against the > external CA cert. > > IMHO this would reduce misconfiguration. > > What do you think? > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Michael S. <mi...@st...> - 2014-11-27 17:54:02
|
HI! It would be nice if besides input field "External CRL Distribution Point" there would be a [Test] button for downloading and validating the CRL against the external CA cert. IMHO this would reduce misconfiguration. What do you think? Ciao, Michael. |
|
From: Michael S. <mi...@st...> - 2014-11-27 12:30:35
|
Tomas Gustavsson <to...@pr...> wrote: > > CA certificates are loaded (by type) at startup. The responder will log > during startup which CA certificates it finds. The hashes are calculated > and looked up in this cache (which is refreshed now and then), so no db > lookup for hashes. How can I see which issuer name/key hashes are currently in the cache? If I hit [Clear All Caches] is there a forced re-load of the OCSP responder's cache? It seems the CAs are loaded (see below) but it does not work. I've initialized completely with ejbca.sh (see below). But in the adminweb the links from the OCSPKeyBinding to the CA cert and the OCSP responder cert result in 404. The Crypto Token does work when hitting [Test]. I can easily send the log_statement output of the postgresql DB server if that would help. Ciao, Michael. --------------------------- setup commands --------------------------- cd /opt/ejbca ant clientToolBox /opt/ejbca/bin/ejbca.sh ca importcacert --caname Interims-CA -f /opt/ejbca/p12/Interims-CA.crt /opt/ejbca/bin/ejbca.sh ca importcert --caname Interims-CA -f /opt/ejbca/p12/superadmin.crt --username superadmin --password null -a ACTIVE --certprofile ENDUSER --eeprofile EMPTY /opt/ejbca/bin/ejbca.sh roles addadmin --role "Super Administrator Role" --caname "Interims-CA" --with WITH_COMMONNAME --type TYPE_EQUALCASE --value "SuperAdmin" /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Root-CA-1-2014-10 -f p12/TestRootCA1201410.cacert.pem /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Admin-CA-1-2014-10 -f p12/TestAdminCA1201410.pem /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Email-CA-1-2014-10 -f p12/TestEmailCA1201410.pem /opt/ejbca/bin/ejbca.sh ca importcacert --caname CA_Test-Server-CA-1-2014-10 -f p12/TestServerCA1201410.pem /opt/ejbca/bin/ejbca.sh ca editca --caname CA_Test-Server-CA-1-2014-10 --field externalCdp --value 'http://vm-ejbca-ca-03.example.com:8080/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=CN%3dTest+Server-CA+%231+2014-10%2cOU%3dITO%2cC%3dDE' [..] /opt/ejbca/bin/ejbca.sh cryptotoken create --token CT_OCSP1 --type SoftCryptoToken --autoactivate true --pin null /opt/ejbca/bin/ejbca.sh cryptotoken generatekey --token CT_OCSP1 --alias privatesignkeyalias --keyspec 2048 /opt/ejbca/bin/ejbca.sh keybind create --name KB_OCSP_Server_1 --token CT_OCSP1 --type OcspKeyBinding --alias privatesignkeyalias --sigalg SHA1WithRSA --verbose --status ACTIVE --cert null /opt/ejbca/bin/ejbca.sh keybind setstatus --name KB_OCSP_Server_1 -v ACTIVE /opt/ejbca/bin/ejbca.sh keybind gencsr --name KB_OCSP_Server_1 -f /opt/ejbca/p12/KB_OCSP_Server_1.csr --verbose /opt/ejbca/dist/clientToolBox/ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req ocsp-server-ca-vm-ejbca-ocsp-01 secret p12/KB_OCSP_Server_1.csr PEM NONE /opt/ejbca/p12/ /opt/ejbca/bin/ejbca.sh keybind import --name KB_OCSP_Server_1 -f /opt/ejbca/p12/ocsp-server-ca-vm-ejbca-ocsp-01.pem --verbose ------------------------- startup log ------------------------- 13:07:51,667 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC service thread 1-3) Initialized CA: Interims-CA, with expire time: Mon Oct 07 16:16:51 CEST 2024 13:07:51,729 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC service thread 1-3) Initialized CA: CA_Test-Server-CA-1-2014-10, with expire time: Fri Nov 27 10:58:12 CET 2015 13:07:51,782 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC service thread 1-3) Initialized CA: CA_Test-Email-CA-1-2014-10, with expire time: Fri Oct 16 14:12:58 CEST 2015 13:07:51,835 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC service thread 1-3) Initialized CA: CA_Test-Admin-CA-1-2014-10, with expire time: Wed Oct 14 14:27:58 CEST 2015 13:07:51,865 INFO [org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean] (MSC service thread 1-3) Initialized CA: CA_Test-Root-CA-1-2014-10, with expire time: Sun Oct 02 17:49:53 CEST 2016 13:07:51,901 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service thread 1-3) Registered audit device using implementation: org.cesecore.audit.impl.log4j.Log4jDevice 13:07:51,903 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service thread 1-3) Configured exporter AuditExporterDummy for device Log4jDevice 13:07:51,904 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service thread 1-3) Registered audit device using implementation: org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice 13:07:51,905 INFO [org.cesecore.audit.AuditDevicesConfig] (MSC service thread 1-3) Configured exporter AuditExporterXml for device IntegrityProtectedDevice 13:07:51,916 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) 2014-11-27 13:07:51+01:00;EJBCA_STARTING;SUCCESS;SERVICE;EJBCA;StartServicesServlet.init;;vm-ejbca-ocsp-01.example.com;;msg=Init, EJBCA 6.3.0Alpha (working copy) startup. 13:07:52,022 INFO [org.ejbca.ui.web.admin.configuration.StartServicesServlet] (MSC service thread 1-3) No database integrity protection available in this version of EJBCA. 13:07:52,025 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) 2014-11-27 13:07:52+01:00;LOG_MANAGEMENT_CHANGE;VOID;SECURITY_AUDIT;CORE;StartServicesServlet.init;;;;msg=No integrity protected security audit logger devices configured. 13:07:52,095 INFO [org.ejbca.core.ejb.authorization.ComplexAccessControlSessionBean] (MSC service thread 1-3) Roles or CAs exist, not intializing Super Administrator Role 13:07:52,228 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (MSC service thread 1-3) Custom certificate serial number not allowed since there is no unique index on (issuerDN,serialNumber) on the 'CertificateData' table. 13:07:52,258 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) 2014-11-27 13:07:52+01:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;StartServicesServlet.init;;;;resource0=/ 13:07:52,272 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (MSC service thread 1-3) 2014-11-27 13:07:52+01:00;SYSTEMCONF_EDIT;SUCCESS;GLOBALCONF;CORE;StartServicesServlet.init;;;;msg=Saved global configuration with id OCSP. 13:07:52,431 INFO [org.cesecore.certificates.ocsp.cache.OcspSigningCache] (MSC service thread 1-3) No default responder was defined. OCSP requests for certificates issued by unknown CAs will return "unauthorized" as per RFC6960, Section 2.3 13:07:52,443 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: Registering web context: /ejbca/adminweb 13:07:52,449 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015951: Admin console listening on http://127.0.0.1:9990 13:07:52,450 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 16617ms - Started 2454 of 2569 services (112 services are passive or on-demand) 13:07:52,513 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "ejbca.ear" -- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: mi...@st... http://www.stroeder.com |
|
From: Eilaf E. <eil...@ho...> - 2014-11-27 12:22:13
|
Hi,
I am trying to generate keys on utimaco HSM using ejbca clientToolBox,
I
am using ejbca 6.2.0 with jboss7 and java 1.7 , I used the same
configuration on ejbca 6.0.4 with jboss7 and java 1.6 and everything
worked perfectly, but now with ejbca 6.2.0 I am getting this error:
ERROR
[org.ejbca.ui.cli.HSMKeyTool] Command 'PKCS11HSMKeyTool generate
/root/Utimaco/libcs_pkcs11_R2.so null pkcs11 1024 key 0' could not be
executed.
java.security.ProviderException: Initialization failed
at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:311)
at sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java:392)
at java.security.Signature$Delegate.engineInitSign(Signature.java:1127)
at java.security.Signature.initSign(Signature.java:511)
at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source)
at org.ejbca.util.keystore.KeyStoreContainerBase.getSelfCertificate(KeyStoreContainerBase.java:136)
at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:308)
at org.ejbca.util.keystore.KeyStoreContainerBase.generateRSA(KeyStoreContainerBase.java:201)
at org.ejbca.util.keystore.KeyStoreContainerBase.generate(KeyStoreContainerBase.java:236)
at org.ejbca.ui.cli.HSMKeyTool.doIt(HSMKeyTool.java:213)
at org.ejbca.ui.cli.HSMKeyTool.execute(HSMKeyTool.java:453)
at org.ejbca.ui.cli.PKCS11HSMKeyTool.execute(PKCS11HSMKeyTool.java:47)
at org.ejbca.ui.cli.ClientToolBox.executeIfSelected(ClientToolBox.java:40)
at org.ejbca.ui.cli.ClientToolBox.main(ClientToolBox.java:66)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OBJECT_HANDLE_INVALID
at sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
at sun.security.pkcs11.P11Signature.initialize(P11Signature.java:303)
... 13 more
I
am not sure this problem is related to ejbca or openjdk, could u please
tell me how what could be causing the problem and how i can solve it
Thanks for your time.
Eilaf Essam |
|
From: Michael S. <mi...@st...> - 2014-11-27 07:18:04
|
eilaf sorkatti wrote: > What are the well tested publishers that works fine with EJBCA? Hmm, you should probably first tell us to which systems you want to publish certs and CRLs. I'm testing EJBCA 6.2 (and latest SVN) and the shell publisher seems to be the most flexible one because you can program whatever you like yourself. ;-) I've also played with the LDAP publishers using EJBCA 4.0.11, and they worked. But it depends on your LDAP schema whether that suits your needs. Ciao, Michael. |
|
From: eilaf s. <eil...@gm...> - 2014-11-27 06:44:31
|
Hi, What are the well tested publishers that works fine with EJBCA? -- Eilaf Hamad Elnil Mugbil University Of Khartoum School Of Mathematical science |
|
From: Tomas G. <to...@pr...> - 2014-11-26 17:04:58
|
CA certificates are loaded (by type) at startup. The responder will log during startup which CA certificates it finds. The hashes are calculated and looked up in this cache (which is refreshed now and then), so no db lookup for hashes. Cheers, TOmas On 2014-11-26 17:53, Michael Ströder wrote: > HI! > > Hmm, I've setup an stand-alone OCSP responder and imported CA cert, initialized > OCSPKeyBinding etc. all with latest SVN revision. > > Table certificatedata is populated by the publisher with CA and EE certs. > > The adminweb shows the CA and I've added external CDPs. > > Table base64certdata is empty but column certificatedata.base64cert is > populated. > > But still something's missing in the DB. > > The server.log says (tweaked names and IP address): > > 17:23:55,603 INFO > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (http--0.0.0.0-8080-1) Received OCSP request for certificate with serNo: > 11542cac9598dd7a, and issuerNameHash: 8be9abc6e3e5996ae51628169d52f9fcac10a272. > Client ip 42.23.42.23. > > 17:23:55,626 ERROR > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (http--0.0.0.0-8080-1) Unable to find CA certificate by issuer name hash: > 8be9abc6e3e5996ae51628169d52f9fcac10a272, or even the default responder: > CN=ocsp-server-ca-vm-ejbca-ocsp-01,OU=PKI Operation,O=ACME Corp.,C=DE. > > 17:27:01,105 INFO > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (http--0.0.0.0-8080-1) Received OCSP request for certificate with serNo: > 11542cac9598dd7a, and issuerNameHash: 8be9abc6e3e5996ae51628169d52f9fcac10a272. > Client ip 42.23.42.23. > > 17:27:01,121 ERROR > [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] > (http--0.0.0.0-8080-1) Unable to find CA certificate by issuer name hash: > 8be9abc6e3e5996ae51628169d52f9fcac10a272, or even the default responder: > CN=ocsp-server-ca-vm-ejbca-ocsp-01,OU=PKI Operation,O=ACME Corp.,C=DE. > > Where to look in the DB what's missing? > How's the DB lookup done for issuer name/key hash? > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Michael S. <mi...@st...> - 2014-11-26 16:53:27
|
HI! Hmm, I've setup an stand-alone OCSP responder and imported CA cert, initialized OCSPKeyBinding etc. all with latest SVN revision. Table certificatedata is populated by the publisher with CA and EE certs. The adminweb shows the CA and I've added external CDPs. Table base64certdata is empty but column certificatedata.base64cert is populated. But still something's missing in the DB. The server.log says (tweaked names and IP address): 17:23:55,603 INFO [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (http--0.0.0.0-8080-1) Received OCSP request for certificate with serNo: 11542cac9598dd7a, and issuerNameHash: 8be9abc6e3e5996ae51628169d52f9fcac10a272. Client ip 42.23.42.23. 17:23:55,626 ERROR [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (http--0.0.0.0-8080-1) Unable to find CA certificate by issuer name hash: 8be9abc6e3e5996ae51628169d52f9fcac10a272, or even the default responder: CN=ocsp-server-ca-vm-ejbca-ocsp-01,OU=PKI Operation,O=ACME Corp.,C=DE. 17:27:01,105 INFO [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (http--0.0.0.0-8080-1) Received OCSP request for certificate with serNo: 11542cac9598dd7a, and issuerNameHash: 8be9abc6e3e5996ae51628169d52f9fcac10a272. Client ip 42.23.42.23. 17:27:01,121 ERROR [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (http--0.0.0.0-8080-1) Unable to find CA certificate by issuer name hash: 8be9abc6e3e5996ae51628169d52f9fcac10a272, or even the default responder: CN=ocsp-server-ca-vm-ejbca-ocsp-01,OU=PKI Operation,O=ACME Corp.,C=DE. Where to look in the DB what's missing? How's the DB lookup done for issuer name/key hash? Ciao, Michael. |
|
From: Michael S. <mi...@st...> - 2014-11-26 14:35:41
|
HI! I'm having a hard time finding out why sometimes (not always) ejbca.sh is so damn slow: root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help [..] real 0m2.251s user 0m2.748s sys 0m0.288s root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help [..] real 0m25.008s user 0m18.069s sys 0m0.192s I'm looking with strace and tcpdump what's going on. But still nothing obvious. Which debug logs should I enable in the JVM? BTW: Any reason why using --help requires a running JBOSS? Ciao, Michael. |
|
From: Andreas K. <ku...@tr...> - 2014-11-25 11:36:23
|
Hi Michael, > Sorry for the delay in my answer which is due to the time shift. greetings to America! > The intention was to make the system more secure. > > So if the system gets compromised, the attacker would only have access to the intermediate CA's which have a way shorter lifespan (5 years) compared to the root CA (20 years). > > I don't have much experience in running a PKI, so please bear with me if I mix up some terms. No problem, you are heading in the right direction! But you have to distinct between the 'Root CA' as an artefact within the ejbca and its private key. If you are thinking about validities of 20 years it makes perfect sense to use some kind of hardware device (token or HSM) to keep the root key in a safe place with option to separate it from system. But this separation does not require a 'deletion' of the 'Root CA'. It's no problem to have the administrative information and the root's certificate in place. The crucial point is to disable the use of the private key! This could be done easily with hardware (as mentioned above) or using an encrypted key file, decrypted only for CA signing purposes. Both approaches have their pros and cons: Hardware may fail over time, replacement hardware maybe unavailable, hardware hacked ... The decrypted file uncovers the most precious key material to be copied by a trojan, a disgruntled employee ... or someone simply forgets to delete is safely. > But if you say I'd run into troubles with that, I'm happy to leave the root CA on the server. Leave the 'Root CA' on the server, but do care about the key material! I outlined some options ... any option has their specific downside ... it's up to you ... Greetings, Andreas > regards > nomike > > -----Ursprüngliche Nachricht----- > Von: Michael Ströder [mailto:mi...@st...] > Gesendet: Montag, 24. November 2014 20:47 > An: ejb...@li... > Betreff: Re: [Ejbca-develop] Deleting the root CA > > Andreas Kuehne wrote: >> Hi again, Michael! >>> Michael Postmann wrote: >>>> In our setup we have a root CA which singed two intermediate CA's >>>> which then sign some client and webserver certificates to be used >>>> internally and by our clients. For reasons of security, we want to >>>> remove the root CA from the server, as soon as the intermediate CAs >>>> are signed. The root CA will be stored in physical safe so we have it available in case we need it again. >>> An off-line root CA key. >> He doesn't talk about deleting keys, he talks about deleting CAs! >> Iirc this isn't possible anyway ... > Probably the original poster should clarify what he really wants. > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > -- Andreas Kühne phone: +49 177 293 24 97 mailto: ku...@tr... Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne, Heiko Veit Company UK Company No: 5218868 Registered in England and Wales |
|
From: Michael P. <M.P...@pa...> - 2014-11-25 10:43:48
|
Sorry for the delay in my answer which is due to the time shift. The intention was to make the system more secure. So if the system gets compromised, the attacker would only have access to the intermediate CA's which have a way shorter lifespan (5 years) compared to the root CA (20 years). I don't have much experience in running a PKI, so please bear with me if I mix up some terms. But if you say I'd run into troubles with that, I'm happy to leave the root CA on the server. regards nomike -----Ursprüngliche Nachricht----- Von: Michael Ströder [mailto:mi...@st...] Gesendet: Montag, 24. November 2014 20:47 An: ejb...@li... Betreff: Re: [Ejbca-develop] Deleting the root CA Andreas Kuehne wrote: > Hi again, Michael! >> Michael Postmann wrote: >>> In our setup we have a root CA which singed two intermediate CA's >>> which then sign some client and webserver certificates to be used >>> internally and by our clients. For reasons of security, we want to >>> remove the root CA from the server, as soon as the intermediate CAs >>> are signed. The root CA will be stored in physical safe so we have it available in case we need it again. >> An off-line root CA key. > He doesn't talk about deleting keys, he talks about deleting CAs! > Iirc this isn't possible anyway ... Probably the original poster should clarify what he really wants. Ciao, Michael. |
|
From: Michael S. <mi...@st...> - 2014-11-24 19:47:22
|
Andreas Kuehne wrote: > Hi again, Michael! >> Michael Postmann wrote: >>> In our setup we have a root CA which singed two intermediate CA's which >>> then sign some client and webserver certificates to be used internally and >>> by our clients. For reasons of security, we want to remove the root CA from >>> the server, as soon as the intermediate CAs are signed. The root CA will be >>> stored in physical safe so we have it available in case we need it again. >> An off-line root CA key. > He doesn't talk about deleting keys, he talks about deleting CAs! > Iirc this isn't possible anyway ... Probably the original poster should clarify what he really wants. Ciao, Michael. |
|
From: Andreas K. <ku...@tr...> - 2014-11-24 19:40:57
|
Hi again, Michael! > Michael Postmann wrote: >> In our setup we have a root CA which singed two intermediate CA's which >> then sign some client and webserver certificates to be used internally and >> by our clients. For reasons of security, we want to remove the root CA from >> the server, as soon as the intermediate CAs are signed. The root CA will be >> stored in physical safe so we have it available in case we need it again. > An off-line root CA key. He doesn't talk about deleting keys, he talks about deleting CAs! Iirc this isn't possible anyway ... Greetings, Andreas |
|
From: Andreas K. <ku...@tr...> - 2014-11-24 19:33:40
|
Hi Michael, got me ;-) Anyway, you can delegate the signing of the OCSP response. But the request uses of the _issuer's_ certificate, doesn't it? Greetings, Andeas > Andreas Kuehne wrote: >> your idea to delete the root CA is a bit suprising to me! I would agree >> that's a good idea to lock away the private key of the root, preferably >> on a smart card or in an encrypted file with different holders of >> credential parts. >> >> Without the root certificate all your chain validations will fail. >> Making OCSP requests for the intermediate CA is 'difficult' without >> having the issuing certificate at hand ... > Andreas, this reveals that you're very much into SigG signature checking. ;-) > > "Normal" implementations (e.g. Firefox) usually only send OCSP requests for > end entities. > > But you could even remove the root CA key if the root CA issued a OCSP > responder cert with separate key pair (OCSP delegation). > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop -- Andreas Kühne phone: +49 177 293 24 97 mailto: ku...@tr... Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne, Heiko Veit Company UK Company No: 5218868 Registered in England and Wales |
106 messages has been excluded from this view by a project administrator.
