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: Tomas G. <to...@pr...> - 2019-06-26 13:19:15
|
This has actually already been fixed in later releases of EJBCA. https://jira.primekey.se/browse/ECA-7796 But the easiest fix is to make your CRLs RFC5280 compliant. Regards, Tomas On 2019-06-26 15:16, Tomas Gustavsson wrote: > Hi, > > Your CRL does not have a nextUpdate field. It's a bug in EJBCA that it > is not handled. But according to RFC5280 CRLs must include nextUpdate. > https://tools.ietf.org/html/rfc5280#section-5.1.2.5 > > I.e. your CRLs are not complient with RFC5280. You should fix this. > The field is optional in the ASN.1 encoding, but RFC5280 states that is > MUST be included. > > Regards, > Tomas > > > On 2019-06-26 15:04, ohaya--- via Ejbca-develop wrote: >> Hi, >> >> This is a followup to an earlier thread, "Trouble creating Internal Key Binding for OCSP Responder"... >> >> I am encountering a NullPointerException when trying to import a CRL using EJBCA Adminweb on the "CA Structure & CRLs" webpage. >> >> So here is how I cause the error: >> >> In Adminweb, import the CA cert for an external CA >> That causes the new CA to appear in the "CA Structure & CRLs" webpage then >> At the top of the "CA Structure & CRLs" page, browse to the CRL file for that new CA and in the dropdown, select that new CA then >> Click "Import" >> >> At that point, apparently nothing occurs on the Adminweb webpage (it just re-appears) and doesn't show/say that the CRL was imported. >> >> And in the server.log file, a stacktrace with a NullPointerException appears. >> >> NOTE THAT I just tested this same situation on a different EJBCA intance that I made from the EJBCA OVA, and this error also seems to occur on that other EJBCA (from OVA) instance. Here is the stacktrace from testing on the OVA-built EJBCA: >> >> 019-06-26 14:43:15,411 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error retrieving CRL for issuer 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0. >> 2019-06-26 14:43:15,411 DEBUG [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Downloaded CRL contains 1 entries. >> 2019-06-26 14:43:15,411 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Found 1 new entires in full CRL number 3 issued by 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to previous. >> 2019-06-26 14:43:15,416 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 >> 2019-06-26 14:43:15,417 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 >> 2019-06-26 14:43:15,418 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Adding limited CertificateData entry with fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0f, serialNumber=16B902B1B87, issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' >> 2019-06-26 14:43:15,419 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-10) 2019-06-26 14:43:15+02:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401 >> 2019-06-26 14:43:15,419 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: Log4jDevice Proc: 0 >> 2019-06-26 14:43:15,435 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: IntegrityProtectedDevice Proc: 16 >> 2019-06-26 14:43:15,440 DEBUG [org.cesecore.certificates.crl.CRLData] (default task-10) Creating crldata, fp=e49043c4b259c000bae8b6bd965141a48e9265a2, issuer=CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US, crlNumber=3, deltaCRLIndicator=-1 >> 2019-06-26 14:43:15,442 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error storing CRL with CRLNumber=3, issuerDN 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.NullPointerException >> at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244) >> at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86) >> at org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) >> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) >> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) >> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) >> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >> at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view45.storeCRL(Unknown Source) >> at org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) >> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) >> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) >> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) >> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) >> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) >> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >> at org.ejbca.core.ejb.crl.ImportCrlSessionLocal$$$view36.importCrl(Unknown Source) >> at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.importCRL(CAInterfaceBean.java:1401) >> at org.apache.jsp.ca.cafunctions_jsp._jspService(cafunctions_jsp.java:233) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) >> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) >> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) >> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) >> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) >> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) >> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) >> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) >> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) >> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) >> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) >> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >> at java.lang.Thread.run(Thread.java:748) >> >> >> >> _______________________________________________ >> 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-06-26 13:16:30
|
Hi, Your CRL does not have a nextUpdate field. It's a bug in EJBCA that it is not handled. But according to RFC5280 CRLs must include nextUpdate. https://tools.ietf.org/html/rfc5280#section-5.1.2.5 I.e. your CRLs are not complient with RFC5280. You should fix this. The field is optional in the ASN.1 encoding, but RFC5280 states that is MUST be included. Regards, Tomas On 2019-06-26 15:04, ohaya--- via Ejbca-develop wrote: > Hi, > > This is a followup to an earlier thread, "Trouble creating Internal Key Binding for OCSP Responder"... > > I am encountering a NullPointerException when trying to import a CRL using EJBCA Adminweb on the "CA Structure & CRLs" webpage. > > So here is how I cause the error: > > In Adminweb, import the CA cert for an external CA > That causes the new CA to appear in the "CA Structure & CRLs" webpage then > At the top of the "CA Structure & CRLs" page, browse to the CRL file for that new CA and in the dropdown, select that new CA then > Click "Import" > > At that point, apparently nothing occurs on the Adminweb webpage (it just re-appears) and doesn't show/say that the CRL was imported. > > And in the server.log file, a stacktrace with a NullPointerException appears. > > NOTE THAT I just tested this same situation on a different EJBCA intance that I made from the EJBCA OVA, and this error also seems to occur on that other EJBCA (from OVA) instance. Here is the stacktrace from testing on the OVA-built EJBCA: > > 019-06-26 14:43:15,411 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error retrieving CRL for issuer 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0. > 2019-06-26 14:43:15,411 DEBUG [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Downloaded CRL contains 1 entries. > 2019-06-26 14:43:15,411 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Found 1 new entires in full CRL number 3 issued by 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to previous. > 2019-06-26 14:43:15,416 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 > 2019-06-26 14:43:15,417 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 > 2019-06-26 14:43:15,418 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Adding limited CertificateData entry with fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0f, serialNumber=16B902B1B87, issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' > 2019-06-26 14:43:15,419 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-10) 2019-06-26 14:43:15+02:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401 > 2019-06-26 14:43:15,419 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: Log4jDevice Proc: 0 > 2019-06-26 14:43:15,435 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: IntegrityProtectedDevice Proc: 16 > 2019-06-26 14:43:15,440 DEBUG [org.cesecore.certificates.crl.CRLData] (default task-10) Creating crldata, fp=e49043c4b259c000bae8b6bd965141a48e9265a2, issuer=CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US, crlNumber=3, deltaCRLIndicator=-1 > 2019-06-26 14:43:15,442 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error storing CRL with CRLNumber=3, issuerDN 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.NullPointerException > at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244) > at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86) > at org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view45.storeCRL(Unknown Source) > at org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.ejbca.core.ejb.crl.ImportCrlSessionLocal$$$view36.importCrl(Unknown Source) > at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.importCRL(CAInterfaceBean.java:1401) > at org.apache.jsp.ca.cafunctions_jsp._jspService(cafunctions_jsp.java:233) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: <oh...@ya...> - 2019-06-26 13:14:48
|
Hi,
Sorry, one more thing that I just noticed: When the error happens, the words "Error: java.lang.NullPointerException" appear in RED at the top of the Adminweb webpage.
My apologies... I just didn't notice/see that earlier :)!!
Jim
On Wednesday, June 26, 2019, 9:04:50 AM EDT, <oh...@ya...> wrote:
Hi,
This is a followup to an earlier thread, "Trouble creating Internal Key Binding for OCSP Responder"...
I am encountering a NullPointerException when trying to import a CRL using EJBCA Adminweb on the "CA Structure & CRLs" webpage.
So here is how I cause the error:
In Adminweb, import the CA cert for an external CA
That causes the new CA to appear in the "CA Structure & CRLs" webpage then
At the top of the "CA Structure & CRLs" page, browse to the CRL file for that new CA and in the dropdown, select that new CA then
Click "Import"
At that point, apparently nothing occurs on the Adminweb webpage (it just re-appears) and doesn't show/say that the CRL was imported.
And in the server.log file, a stacktrace with a NullPointerException appears.
NOTE THAT I just tested this same situation on a different EJBCA intance that I made from the EJBCA OVA, and this error also seems to occur on that other EJBCA (from OVA) instance. Here is the stacktrace from testing on the OVA-built EJBCA:
019-06-26 14:43:15,411 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error retrieving CRL for issuer 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0.
2019-06-26 14:43:15,411 DEBUG [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Downloaded CRL contains 1 entries.
2019-06-26 14:43:15,411 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Found 1 new entires in full CRL number 3 issued by 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to previous.
2019-06-26 14:43:15,416 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647
2019-06-26 14:43:15,417 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647
2019-06-26 14:43:15,418 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Adding limited CertificateData entry with fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0f, serialNumber=16B902B1B87, issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'
2019-06-26 14:43:15,419 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-10) 2019-06-26 14:43:15+02:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401
2019-06-26 14:43:15,419 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: Log4jDevice Proc: 0
2019-06-26 14:43:15,435 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: IntegrityProtectedDevice Proc: 16
2019-06-26 14:43:15,440 DEBUG [org.cesecore.certificates.crl.CRLData] (default task-10) Creating crldata, fp=e49043c4b259c000bae8b6bd965141a48e9265a2, issuer=CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US, crlNumber=3, deltaCRLIndicator=-1
2019-06-26 14:43:15,442 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error storing CRL with CRLNumber=3, issuerDN 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.NullPointerException
at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244)
at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86)
at org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view45.storeCRL(Unknown Source)
at org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at org.ejbca.core.ejb.crl.ImportCrlSessionLocal$$$view36.importCrl(Unknown Source)
at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.importCRL(CAInterfaceBean.java:1401)
at org.apache.jsp.ca.cafunctions_jsp._jspService(cafunctions_jsp.java:233)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
|
|
From: <oh...@ya...> - 2019-06-26 13:04:51
|
Hi, This is a followup to an earlier thread, "Trouble creating Internal Key Binding for OCSP Responder"... I am encountering a NullPointerException when trying to import a CRL using EJBCA Adminweb on the "CA Structure & CRLs" webpage. So here is how I cause the error: In Adminweb, import the CA cert for an external CA That causes the new CA to appear in the "CA Structure & CRLs" webpage then At the top of the "CA Structure & CRLs" page, browse to the CRL file for that new CA and in the dropdown, select that new CA then Click "Import" At that point, apparently nothing occurs on the Adminweb webpage (it just re-appears) and doesn't show/say that the CRL was imported. And in the server.log file, a stacktrace with a NullPointerException appears. NOTE THAT I just tested this same situation on a different EJBCA intance that I made from the EJBCA OVA, and this error also seems to occur on that other EJBCA (from OVA) instance. Here is the stacktrace from testing on the OVA-built EJBCA: 019-06-26 14:43:15,411 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error retrieving CRL for issuer 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0. 2019-06-26 14:43:15,411 DEBUG [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Downloaded CRL contains 1 entries. 2019-06-26 14:43:15,411 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-10) Found 1 new entires in full CRL number 3 issued by 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to previous. 2019-06-26 14:43:15,416 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 2019-06-26 14:43:15,417 DEBUG [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Found 0 cert(s) with (transformed) DN: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US serialNumber: 1561491872647 2019-06-26 14:43:15,418 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-10) Adding limited CertificateData entry with fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0f, serialNumber=16B902B1B87, issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' 2019-06-26 14:43:15,419 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-10) 2019-06-26 14:43:15+02:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401 2019-06-26 14:43:15,419 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: Log4jDevice Proc: 0 2019-06-26 14:43:15,435 DEBUG [org.cesecore.audit.log.InternalSecurityEventsLoggerSessionBean] (default task-10) LogDevice: IntegrityProtectedDevice Proc: 16 2019-06-26 14:43:15,440 DEBUG [org.cesecore.certificates.crl.CRLData] (default task-10) Creating crldata, fp=e49043c4b259c000bae8b6bd965141a48e9265a2, issuer=CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US, crlNumber=3, deltaCRLIndicator=-1 2019-06-26 14:43:15,442 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-10) Error storing CRL with CRLNumber=3, issuerDN 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.NullPointerException at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244) at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86) at org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view45.storeCRL(Unknown Source) at org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.ejbca.core.ejb.crl.ImportCrlSessionLocal$$$view36.importCrl(Unknown Source) at org.ejbca.ui.web.admin.cainterface.CAInterfaceBean.importCRL(CAInterfaceBean.java:1401) at org.apache.jsp.ca.cafunctions_jsp._jspService(cafunctions_jsp.java:233) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:204) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.filters.ClickjackFilter.doFilter(ClickjackFilter.java:36) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ejbca.util.owaspcsrfguard.EncodingFilter.doFilter(EncodingFilter.java:51) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) |
|
From: Tomas G. <to...@pr...> - 2019-06-26 12:35:34
|
On 2019-06-26 13:40, ohaya--- via Ejbca-develop wrote: > Hi, > > Ok, so now, if we want to use only one signing key for all the CRL/CAs > we want to respond for, how do we accomplish that? > > Do we (as I described earlier) just have to import the CA cert for each > external CA into Adminweb and then import the CRL for that CA into Adminweb? > > > And, if the answer to that question is "yes, that is all you have to > do", then THAT (when I import the CRL into Adminweb) is where I was > getting the stacktrace with the NullPointerException that I posted > earlier, and I guess that is why I posted it into THIS thread... Yes, that should be all you have to do. The NullPointerException is likely related to some other CRL related detail. Post that stacktrace in a new thread "NullPointerException trying to import CRL". > > > Aside: Now that I think about this discussion, maybe THIS is why you > might not have seen this NullPointerException, i.e., in your case, you > are creating a new binding for each CA/CRL, so you don't get the > NullPointerException, but in my case, I am not creating a new binding > for each CA/CRL but trying to import the CRL using the same binding for > multiple CA/CRLs??? > > > If you still think that should be in a separate thread, please let me > know? I think that if I put it into a new thread, I will have to also > also include a whole bunch of background discussion which we have > already covered in THIS thread by now? > > Please advise, and thanks for your help! > > Jim > > > On Wednesday, June 26, 2019, 7:22:10 AM EDT, Tomas Gustavsson > <to...@pr...> wrote: > > > > Ok, if you look at OCSP Key bindings page there is something called > "Default responder". This is used for unknown issuers/missing key > bindings. There is a [?] link that you can click that takes you directly > to the documentation. > > We're working with hundreds of CAs, and most use a separate signing key > for each CA. The trust model is quite weak if you have a single > responder for all. There are no technical issues having hundreds of key, > and signing certificate chains up to the CA so the chain of trust is > simple. > That's why I say you should create a new key binding, that remains my > recommendation, even if you can do it differently :-) > > Cheers, > Tomas > > On 2019-06-26 13:11, ohaya--- via Ejbca-develop wrote: >> Hi, >> >> I was kind of afraid that you would say that (need a new OCSP binding >> for OCSP responder for each new CA/CRL). >> >> >> BUT, what if we DON'T want to use a different signing key/cert for the >> different CAs/CRLs that our OCSP Responder is supporting? >> >> >> For instance, today, the OCSP Responder we are using supports OCSP >> responding for almost 100 CAs (we download CRL files for about 100 >> different CAs' CRLs into our OCSP Responder) and all the OCSP responses >> are signed by our ONE signing cert/key. >> >> >> If we have to create a new OCSP binding for each of those CAs, we'd have >> to have 100 keys, I think, and I don't think that they (our customer) >> would want that. >> >> >> I am really hoping that we are just mis-communicating somehow, but FYI, >> we have worked with a number of OCSP Responder products and none of them >> requires that we create a unique signing key for each new CA/CRL that we >> want our OCSP responder to be able support. >> >> >> >> Jim >> >> >> On Wednesday, June 26, 2019, 7:02:17 AM EDT, Tomas Gustavsson >> <to...@pr... <mailto:to...@pr...>> wrote: >> >> >> >> On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote: >>> -- Re. the question about CSR: So right now, it looks like to issue the >>> signing cert, the process is you click the CSR button in the Adminweb to >>> create the CSR, then we use that CSR to get a signing certificate >>> issued, and then we import that signing cert. >>> >>> That means if we are standing up EJBCA for production in a new >>> environment, we have to do the above (use Adminweb to create a new CSR, >>> etc.), but here, when we build a new production environment, we >>> generally want to have all the artifacts that are needed to build the >>> new production environment. Specifically, relative to EJBCA, we have our >>> own process for issuing certs, where our process ends up with the >>> private key and cert and maybe a P12, and that we would want to be able >>> to use those to construct the new production environment, rather than >>> have the installer click a button to create a CSR in the production >>> environment and then somehow get the CSR over to our CA and then get the >>> CA to issue a cert, and then somehow get the new cert transferred back >>> over to the production environment. >>> >>> So, what I was looking for is if there is a way to just use our own >>> issued key and cert (or a P12) instead of using Adminweb to create the >>> CSR, etc.? >> >> You can do everything using the CLI, so you can automate that. The keys >> are in a crypto token, you can export and import crypto tokens. >> >> >>> -- Re. the question about "incrementally to add more CRLs from different >>> CAs", I think I wasn't clear about what I meant. >>> >>> I didn't mean updating a CRL for a CA that we had already setup >>> previously in the EJBCA OCSP Responder . >>> >>> >>> Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our >>> EJBCA OCSP Responder to be able to be able to provide OCSP responses >>> for, what do we need to do with EJBCA to do that? >>> >>> So, for example, we now want our EJBCA OCSP Responder to do OCSP >>> responding for 2 more CAs, and we have: >>> >>> CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl) >>> CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl) >>> >>> >>> I think (guess) that the process is something like: >>> >>> Add the new CA cert for CA1 to EJBCA using the Adminweb, then >>> In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the >>> CA1 CA >>> >>> Then: >>> >>> Add the new CA cert for CA2 to EJBCA using the Adminweb, then >>> In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the >>> CA1 CA >>> >>> >>> >>> My question is: Is the above 2 steps (Add the CA cert for the new CA and >>> then import the CRL file for the new CA) the only steps we need to do in >>> this case, in order to get EJBCA OCSP Responder to be able to respond to >>> OCSP requests for that new CA/CRL? >> >> OCSP is done by OCSP Key Bindings. You have to create a new OCSP key >> binding for every new CA you want the OCSP responder to answer for (the >> OCSP signing key must be signed by the CA). The CRL import is just to >> update the revocation database so the OCSP responder knows which >> certificates are revoked. >> >> >>> >>> >>> >>> >>> Thans, >>> Jim >>> >>> P.S. I am having problems with responding format in Yahoo email, so if >>> response looks weird my apologies. >>> >>> >>> >>> >>> On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson >>> <to...@pr... <mailto:to...@pr...> > <mailto:to...@pr... <mailto:to...@pr...>>> wrote: >>> >>> >>> >>> On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote: >>>> Hi, >>>> >>>> FYI, I was able to use Adminweb to create a new CSR and then I issued a >>>> new signing cert with the OCSPSign purpose and I was then able to import >>>> into Adminweb, and I was able to test some good and bad requests (see >>>> below). >>>> >>>> I think that we will still need to be able use a cert/key pair that we >>>> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), >>>> so is there a way to do that? >>> >>> I do not understand what you mean by this. >>> If you want the OCSP Key Binding in EJBCA to generate the key, why would >>> the CSR come from outside of EJBCA? >>> You can always issue certificates to CSRs with EJCBA...if you have a >> CSR... >>> >>>> BTW, also, I am still not clear what we need to do incrementally to add >>>> more CRLs from different CAs? I mean for example, if there are 10 more >>>> CAs with CRLs and we want our EJBCA to do the OCSP responding for those, >>>> what are the steps we need to do to configure EJBCA to do that? >>> >>> There is a service called "CRL Downloader" under Sevrices that can be >>> used to automate import/update of CRLs. It is documented among the >>> "Services". >>> >>> >>>> >>>> >>>> Here's the test: >>>> >>>> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile >>>> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text >>>> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp >>>> OCSP Request Data: >>>> Version: 1 (0x0) >>>> Requestor List: >>>> Certificate ID: >>>> Hash Algorithm: sha1 >>>> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55 >>>> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E >>>> Serial Number: 8486394C03E1F5D9 >>>> Request Extensions: >>>> OCSP Nonce: >>>> 041061AAC22F8FD77F35FEEA879361B29CD9 >>>> Response verify OK >>>> 0x8486394C03E1F5D9: WARNING: Status times invalid. >>>> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet >>>> valid:crypto\ocsp\ocsp_cl.c:320: >>>> revoked >>>> This Update: Jun 25 17:56:47 2019 GMT >>>> Reason: unspecified >>>> Revocation Time: May 26 12:30:44 2019 GMT >>>> >>>> >>>> >>>> >>>> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya... > <mailto:oh...@ya...> >> <mailto:oh...@ya... <mailto:oh...@ya...>> >>> <mailto:oh...@ya... <mailto:oh...@ya...> > <mailto:oh...@ya... <mailto:oh...@ya...>>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> I am trying to create the Internal Key Binding for the OCSP Responder on >>>> the EJBCA that I just built. >>>> >>>> In the Adminweb, I have created the Internal Key Binding, but now I am >>>> trying to do the "Import externally issued certificate". >>>> >>>> I have the Internal Key Binding that I created in the OVA based system >>>> previously, and I was hoping that I wouldn't need to issue a new cert >>>> for this new system, so I was wondering if there is any way to get the >>>> private key from that OVA based system so that I can do the import into >>>> the new EJBCA configuration? >>>> >>>> Or, is the only way to create a new CSR on the new EJBCA, and then issue >>>> a new cert? >>>> >>>> Thanks, >>>> Jim >>> >>>> >>>> >>>> _______________________________________________ >>>> Ejbca-develop mailing list >>>> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> >>> <mailto:Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>>> >>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >>>> >>> >>> >>> _______________________________________________ >>> Ejbca-develop mailing list >>> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> >>> <mailto:Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>>> >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> >>> >>> >>> >>> _______________________________________________ >>> Ejbca-develop mailing list >>> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >>> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto: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... > <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: <oh...@ya...> - 2019-06-26 11:40:26
|
Hi,
Ok, so now, if we want to use only one signing key for all the CRL/CAs we want to respond for, how do we accomplish that?
Do we (as I described earlier) just have to import the CA cert for each external CA into Adminweb and then import the CRL for that CA into Adminweb?
And, if the answer to that question is "yes, that is all you have to do", then THAT (when I import the CRL into Adminweb) is where I was getting the stacktrace with the NullPointerException that I posted earlier, and I guess that is why I posted it into THIS thread...
Aside: Now that I think about this discussion, maybe THIS is why you might not have seen this NullPointerException, i.e., in your case, you are creating a new binding for each CA/CRL, so you don't get the NullPointerException, but in my case, I am not creating a new binding for each CA/CRL but trying to import the CRL using the same binding for multiple CA/CRLs???
If you still think that should be in a separate thread, please let me know? I think that if I put it into a new thread, I will have to also also include a whole bunch of background discussion which we have already covered in THIS thread by now?
Please advise, and thanks for your help!
Jim
On Wednesday, June 26, 2019, 7:22:10 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Ok, if you look at OCSP Key bindings page there is something called
"Default responder". This is used for unknown issuers/missing key
bindings. There is a [?] link that you can click that takes you directly
to the documentation.
We're working with hundreds of CAs, and most use a separate signing key
for each CA. The trust model is quite weak if you have a single
responder for all. There are no technical issues having hundreds of key,
and signing certificate chains up to the CA so the chain of trust is
simple.
That's why I say you should create a new key binding, that remains my
recommendation, even if you can do it differently :-)
Cheers,
Tomas
On 2019-06-26 13:11, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I was kind of afraid that you would say that (need a new OCSP binding
> for OCSP responder for each new CA/CRL).
>
>
> BUT, what if we DON'T want to use a different signing key/cert for the
> different CAs/CRLs that our OCSP Responder is supporting?
>
>
> For instance, today, the OCSP Responder we are using supports OCSP
> responding for almost 100 CAs (we download CRL files for about 100
> different CAs' CRLs into our OCSP Responder) and all the OCSP responses
> are signed by our ONE signing cert/key.
>
>
> If we have to create a new OCSP binding for each of those CAs, we'd have
> to have 100 keys, I think, and I don't think that they (our customer)
> would want that.
>
>
> I am really hoping that we are just mis-communicating somehow, but FYI,
> we have worked with a number of OCSP Responder products and none of them
> requires that we create a unique signing key for each new CA/CRL that we
> want our OCSP responder to be able support.
>
>
>
> Jim
>
>
> On Wednesday, June 26, 2019, 7:02:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote:
>> -- Re. the question about CSR: So right now, it looks like to issue the
>> signing cert, the process is you click the CSR button in the Adminweb to
>> create the CSR, then we use that CSR to get a signing certificate
>> issued, and then we import that signing cert.
>>
>> That means if we are standing up EJBCA for production in a new
>> environment, we have to do the above (use Adminweb to create a new CSR,
>> etc.), but here, when we build a new production environment, we
>> generally want to have all the artifacts that are needed to build the
>> new production environment. Specifically, relative to EJBCA, we have our
>> own process for issuing certs, where our process ends up with the
>> private key and cert and maybe a P12, and that we would want to be able
>> to use those to construct the new production environment, rather than
>> have the installer click a button to create a CSR in the production
>> environment and then somehow get the CSR over to our CA and then get the
>> CA to issue a cert, and then somehow get the new cert transferred back
>> over to the production environment.
>>
>> So, what I was looking for is if there is a way to just use our own
>> issued key and cert (or a P12) instead of using Adminweb to create the
>> CSR, etc.?
>
> You can do everything using the CLI, so you can automate that. The keys
> are in a crypto token, you can export and import crypto tokens.
>
>
>> -- Re. the question about "incrementally to add more CRLs from different
>> CAs", I think I wasn't clear about what I meant.
>>
>> I didn't mean updating a CRL for a CA that we had already setup
>> previously in the EJBCA OCSP Responder .
>>
>>
>> Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our
>> EJBCA OCSP Responder to be able to be able to provide OCSP responses
>> for, what do we need to do with EJBCA to do that?
>>
>> So, for example, we now want our EJBCA OCSP Responder to do OCSP
>> responding for 2 more CAs, and we have:
>>
>> CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl)
>> CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl)
>>
>>
>> I think (guess) that the process is something like:
>>
>> Add the new CA cert for CA1 to EJBCA using the Adminweb, then
>> In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the
>> CA1 CA
>>
>> Then:
>>
>> Add the new CA cert for CA2 to EJBCA using the Adminweb, then
>> In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the
>> CA1 CA
>>
>>
>>
>> My question is: Is the above 2 steps (Add the CA cert for the new CA and
>> then import the CRL file for the new CA) the only steps we need to do in
>> this case, in order to get EJBCA OCSP Responder to be able to respond to
>> OCSP requests for that new CA/CRL?
>
> OCSP is done by OCSP Key Bindings. You have to create a new OCSP key
> binding for every new CA you want the OCSP responder to answer for (the
> OCSP signing key must be signed by the CA). The CRL import is just to
> update the revocation database so the OCSP responder knows which
> certificates are revoked.
>
>
>>
>>
>>
>>
>> Thans,
>> Jim
>>
>> P.S. I am having problems with responding format in Yahoo email, so if
>> response looks weird my apologies.
>>
>>
>>
>>
>> On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson
>> <to...@pr... <mailto:to...@pr...>> wrote:
>>
>>
>>
>> On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote:
>>> Hi,
>>>
>>> FYI, I was able to use Adminweb to create a new CSR and then I issued a
>>> new signing cert with the OCSPSign purpose and I was then able to import
>>> into Adminweb, and I was able to test some good and bad requests (see
>>> below).
>>>
>>> I think that we will still need to be able use a cert/key pair that we
>>> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.),
>>> so is there a way to do that?
>>
>> I do not understand what you mean by this.
>> If you want the OCSP Key Binding in EJBCA to generate the key, why would
>> the CSR come from outside of EJBCA?
>> You can always issue certificates to CSRs with EJCBA...if you have a
> CSR...
>>
>>> BTW, also, I am still not clear what we need to do incrementally to add
>>> more CRLs from different CAs? I mean for example, if there are 10 more
>>> CAs with CRLs and we want our EJBCA to do the OCSP responding for those,
>>> what are the steps we need to do to configure EJBCA to do that?
>>
>> There is a service called "CRL Downloader" under Sevrices that can be
>> used to automate import/update of CRLs. It is documented among the
>> "Services".
>>
>>
>>>
>>>
>>> Here's the test:
>>>
>>> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile
>>> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text
>>> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
>>> OCSP Request Data:
>>> Version: 1 (0x0)
>>> Requestor List:
>>> Certificate ID:
>>> Hash Algorithm: sha1
>>> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
>>> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
>>> Serial Number: 8486394C03E1F5D9
>>> Request Extensions:
>>> OCSP Nonce:
>>> 041061AAC22F8FD77F35FEEA879361B29CD9
>>> Response verify OK
>>> 0x8486394C03E1F5D9: WARNING: Status times invalid.
>>> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet
>>> valid:crypto\ocsp\ocsp_cl.c:320:
>>> revoked
>>> This Update: Jun 25 17:56:47 2019 GMT
>>> Reason: unspecified
>>> Revocation Time: May 26 12:30:44 2019 GMT
>>>
>>>
>>>
>>>
>>> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>
>> <mailto:oh...@ya... <mailto:oh...@ya...>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I am trying to create the Internal Key Binding for the OCSP Responder on
>>> the EJBCA that I just built.
>>>
>>> In the Adminweb, I have created the Internal Key Binding, but now I am
>>> trying to do the "Import externally issued certificate".
>>>
>>> I have the Internal Key Binding that I created in the OVA based system
>>> previously, and I was hoping that I wouldn't need to issue a new cert
>>> for this new system, so I was wondering if there is any way to get the
>>> private key from that OVA based system so that I can do the import into
>>> the new EJBCA configuration?
>>>
>>> Or, is the only way to create a new CSR on the new EJBCA, and then issue
>>> a new cert?
>>>
>>> Thanks,
>>> Jim
>>
>>>
>>>
>>> _______________________________________________
>>> Ejbca-develop mailing list
>>> Ejb...@li...
> <mailto:Ejb...@li...>
>> <mailto:Ejb...@li...
> <mailto:Ejb...@li...>>
>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
> <mailto:Ejb...@li...>
>> <mailto: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...
> <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
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Tomas G. <to...@pr...> - 2019-06-26 11:21:36
|
Ok, if you look at OCSP Key bindings page there is something called "Default responder". This is used for unknown issuers/missing key bindings. There is a [?] link that you can click that takes you directly to the documentation. We're working with hundreds of CAs, and most use a separate signing key for each CA. The trust model is quite weak if you have a single responder for all. There are no technical issues having hundreds of key, and signing certificate chains up to the CA so the chain of trust is simple. That's why I say you should create a new key binding, that remains my recommendation, even if you can do it differently :-) Cheers, Tomas On 2019-06-26 13:11, ohaya--- via Ejbca-develop wrote: > Hi, > > I was kind of afraid that you would say that (need a new OCSP binding > for OCSP responder for each new CA/CRL). > > > BUT, what if we DON'T want to use a different signing key/cert for the > different CAs/CRLs that our OCSP Responder is supporting? > > > For instance, today, the OCSP Responder we are using supports OCSP > responding for almost 100 CAs (we download CRL files for about 100 > different CAs' CRLs into our OCSP Responder) and all the OCSP responses > are signed by our ONE signing cert/key. > > > If we have to create a new OCSP binding for each of those CAs, we'd have > to have 100 keys, I think, and I don't think that they (our customer) > would want that. > > > I am really hoping that we are just mis-communicating somehow, but FYI, > we have worked with a number of OCSP Responder products and none of them > requires that we create a unique signing key for each new CA/CRL that we > want our OCSP responder to be able support. > > > > Jim > > > On Wednesday, June 26, 2019, 7:02:17 AM EDT, Tomas Gustavsson > <to...@pr...> wrote: > > > > On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote: >> -- Re. the question about CSR: So right now, it looks like to issue the >> signing cert, the process is you click the CSR button in the Adminweb to >> create the CSR, then we use that CSR to get a signing certificate >> issued, and then we import that signing cert. >> >> That means if we are standing up EJBCA for production in a new >> environment, we have to do the above (use Adminweb to create a new CSR, >> etc.), but here, when we build a new production environment, we >> generally want to have all the artifacts that are needed to build the >> new production environment. Specifically, relative to EJBCA, we have our >> own process for issuing certs, where our process ends up with the >> private key and cert and maybe a P12, and that we would want to be able >> to use those to construct the new production environment, rather than >> have the installer click a button to create a CSR in the production >> environment and then somehow get the CSR over to our CA and then get the >> CA to issue a cert, and then somehow get the new cert transferred back >> over to the production environment. >> >> So, what I was looking for is if there is a way to just use our own >> issued key and cert (or a P12) instead of using Adminweb to create the >> CSR, etc.? > > You can do everything using the CLI, so you can automate that. The keys > are in a crypto token, you can export and import crypto tokens. > > >> -- Re. the question about "incrementally to add more CRLs from different >> CAs", I think I wasn't clear about what I meant. >> >> I didn't mean updating a CRL for a CA that we had already setup >> previously in the EJBCA OCSP Responder . >> >> >> Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our >> EJBCA OCSP Responder to be able to be able to provide OCSP responses >> for, what do we need to do with EJBCA to do that? >> >> So, for example, we now want our EJBCA OCSP Responder to do OCSP >> responding for 2 more CAs, and we have: >> >> CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl) >> CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl) >> >> >> I think (guess) that the process is something like: >> >> Add the new CA cert for CA1 to EJBCA using the Adminweb, then >> In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the >> CA1 CA >> >> Then: >> >> Add the new CA cert for CA2 to EJBCA using the Adminweb, then >> In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the >> CA1 CA >> >> >> >> My question is: Is the above 2 steps (Add the CA cert for the new CA and >> then import the CRL file for the new CA) the only steps we need to do in >> this case, in order to get EJBCA OCSP Responder to be able to respond to >> OCSP requests for that new CA/CRL? > > OCSP is done by OCSP Key Bindings. You have to create a new OCSP key > binding for every new CA you want the OCSP responder to answer for (the > OCSP signing key must be signed by the CA). The CRL import is just to > update the revocation database so the OCSP responder knows which > certificates are revoked. > > >> >> >> >> >> Thans, >> Jim >> >> P.S. I am having problems with responding format in Yahoo email, so if >> response looks weird my apologies. >> >> >> >> >> On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson >> <to...@pr... <mailto:to...@pr...>> wrote: >> >> >> >> On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote: >>> Hi, >>> >>> FYI, I was able to use Adminweb to create a new CSR and then I issued a >>> new signing cert with the OCSPSign purpose and I was then able to import >>> into Adminweb, and I was able to test some good and bad requests (see >>> below). >>> >>> I think that we will still need to be able use a cert/key pair that we >>> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), >>> so is there a way to do that? >> >> I do not understand what you mean by this. >> If you want the OCSP Key Binding in EJBCA to generate the key, why would >> the CSR come from outside of EJBCA? >> You can always issue certificates to CSRs with EJCBA...if you have a > CSR... >> >>> BTW, also, I am still not clear what we need to do incrementally to add >>> more CRLs from different CAs? I mean for example, if there are 10 more >>> CAs with CRLs and we want our EJBCA to do the OCSP responding for those, >>> what are the steps we need to do to configure EJBCA to do that? >> >> There is a service called "CRL Downloader" under Sevrices that can be >> used to automate import/update of CRLs. It is documented among the >> "Services". >> >> >>> >>> >>> Here's the test: >>> >>> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile >>> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text >>> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp >>> OCSP Request Data: >>> Version: 1 (0x0) >>> Requestor List: >>> Certificate ID: >>> Hash Algorithm: sha1 >>> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55 >>> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E >>> Serial Number: 8486394C03E1F5D9 >>> Request Extensions: >>> OCSP Nonce: >>> 041061AAC22F8FD77F35FEEA879361B29CD9 >>> Response verify OK >>> 0x8486394C03E1F5D9: WARNING: Status times invalid. >>> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet >>> valid:crypto\ocsp\ocsp_cl.c:320: >>> revoked >>> This Update: Jun 25 17:56:47 2019 GMT >>> Reason: unspecified >>> Revocation Time: May 26 12:30:44 2019 GMT >>> >>> >>> >>> >>> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya... > <mailto:oh...@ya...> >> <mailto:oh...@ya... <mailto:oh...@ya...>>> wrote: >>> >>> >>> Hi, >>> >>> I am trying to create the Internal Key Binding for the OCSP Responder on >>> the EJBCA that I just built. >>> >>> In the Adminweb, I have created the Internal Key Binding, but now I am >>> trying to do the "Import externally issued certificate". >>> >>> I have the Internal Key Binding that I created in the OVA based system >>> previously, and I was hoping that I wouldn't need to issue a new cert >>> for this new system, so I was wondering if there is any way to get the >>> private key from that OVA based system so that I can do the import into >>> the new EJBCA configuration? >>> >>> Or, is the only way to create a new CSR on the new EJBCA, and then issue >>> a new cert? >>> >>> Thanks, >>> Jim >> >>> >>> >>> _______________________________________________ >>> Ejbca-develop mailing list >>> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >>> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... > <mailto:Ejb...@li...> >> <mailto: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... > <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: <oh...@ya...> - 2019-06-26 11:11:20
|
Hi,
I was kind of afraid that you would say that (need a new OCSP binding for OCSP responder for each new CA/CRL).
BUT, what if we DON'T want to use a different signing key/cert for the different CAs/CRLs that our OCSP Responder is supporting?
For instance, today, the OCSP Responder we are using supports OCSP responding for almost 100 CAs (we download CRL files for about 100 different CAs' CRLs into our OCSP Responder) and all the OCSP responses are signed by our ONE signing cert/key.
If we have to create a new OCSP binding for each of those CAs, we'd have to have 100 keys, I think, and I don't think that they (our customer) would want that.
I am really hoping that we are just mis-communicating somehow, but FYI, we have worked with a number of OCSP Responder products and none of them requires that we create a unique signing key for each new CA/CRL that we want our OCSP responder to be able support.
Jim
On Wednesday, June 26, 2019, 7:02:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote:
> -- Re. the question about CSR: So right now, it looks like to issue the
> signing cert, the process is you click the CSR button in the Adminweb to
> create the CSR, then we use that CSR to get a signing certificate
> issued, and then we import that signing cert.
>
> That means if we are standing up EJBCA for production in a new
> environment, we have to do the above (use Adminweb to create a new CSR,
> etc.), but here, when we build a new production environment, we
> generally want to have all the artifacts that are needed to build the
> new production environment. Specifically, relative to EJBCA, we have our
> own process for issuing certs, where our process ends up with the
> private key and cert and maybe a P12, and that we would want to be able
> to use those to construct the new production environment, rather than
> have the installer click a button to create a CSR in the production
> environment and then somehow get the CSR over to our CA and then get the
> CA to issue a cert, and then somehow get the new cert transferred back
> over to the production environment.
>
> So, what I was looking for is if there is a way to just use our own
> issued key and cert (or a P12) instead of using Adminweb to create the
> CSR, etc.?
You can do everything using the CLI, so you can automate that. The keys
are in a crypto token, you can export and import crypto tokens.
> -- Re. the question about "incrementally to add more CRLs from different
> CAs", I think I wasn't clear about what I meant.
>
> I didn't mean updating a CRL for a CA that we had already setup
> previously in the EJBCA OCSP Responder .
>
>
> Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our
> EJBCA OCSP Responder to be able to be able to provide OCSP responses
> for, what do we need to do with EJBCA to do that?
>
> So, for example, we now want our EJBCA OCSP Responder to do OCSP
> responding for 2 more CAs, and we have:
>
> CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl)
> CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl)
>
>
> I think (guess) that the process is something like:
>
> Add the new CA cert for CA1 to EJBCA using the Adminweb, then
> In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the
> CA1 CA
>
> Then:
>
> Add the new CA cert for CA2 to EJBCA using the Adminweb, then
> In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the
> CA1 CA
>
>
>
> My question is: Is the above 2 steps (Add the CA cert for the new CA and
> then import the CRL file for the new CA) the only steps we need to do in
> this case, in order to get EJBCA OCSP Responder to be able to respond to
> OCSP requests for that new CA/CRL?
OCSP is done by OCSP Key Bindings. You have to create a new OCSP key
binding for every new CA you want the OCSP responder to answer for (the
OCSP signing key must be signed by the CA). The CRL import is just to
update the revocation database so the OCSP responder knows which
certificates are revoked.
>
>
>
>
> Thans,
> Jim
>
> P.S. I am having problems with responding format in Yahoo email, so if
> response looks weird my apologies.
>
>
>
>
> On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote:
>> Hi,
>>
>> FYI, I was able to use Adminweb to create a new CSR and then I issued a
>> new signing cert with the OCSPSign purpose and I was then able to import
>> into Adminweb, and I was able to test some good and bad requests (see
>> below).
>>
>> I think that we will still need to be able use a cert/key pair that we
>> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.),
>> so is there a way to do that?
>
> I do not understand what you mean by this.
> If you want the OCSP Key Binding in EJBCA to generate the key, why would
> the CSR come from outside of EJBCA?
> You can always issue certificates to CSRs with EJCBA...if you have a CSR...
>
>> BTW, also, I am still not clear what we need to do incrementally to add
>> more CRLs from different CAs? I mean for example, if there are 10 more
>> CAs with CRLs and we want our EJBCA to do the OCSP responding for those,
>> what are the steps we need to do to configure EJBCA to do that?
>
> There is a service called "CRL Downloader" under Sevrices that can be
> used to automate import/update of CRLs. It is documented among the
> "Services".
>
>
>>
>>
>> Here's the test:
>>
>> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile
>> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text
>> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
>> OCSP Request Data:
>> Version: 1 (0x0)
>> Requestor List:
>> Certificate ID:
>> Hash Algorithm: sha1
>> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
>> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
>> Serial Number: 8486394C03E1F5D9
>> Request Extensions:
>> OCSP Nonce:
>> 041061AAC22F8FD77F35FEEA879361B29CD9
>> Response verify OK
>> 0x8486394C03E1F5D9: WARNING: Status times invalid.
>> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet
>> valid:crypto\ocsp\ocsp_cl.c:320:
>> revoked
>> This Update: Jun 25 17:56:47 2019 GMT
>> Reason: unspecified
>> Revocation Time: May 26 12:30:44 2019 GMT
>>
>>
>>
>>
>> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to create the Internal Key Binding for the OCSP Responder on
>> the EJBCA that I just built.
>>
>> In the Adminweb, I have created the Internal Key Binding, but now I am
>> trying to do the "Import externally issued certificate".
>>
>> I have the Internal Key Binding that I created in the OVA based system
>> previously, and I was hoping that I wouldn't need to issue a new cert
>> for this new system, so I was wondering if there is any way to get the
>> private key from that OVA based system so that I can do the import into
>> the new EJBCA configuration?
>>
>> Or, is the only way to create a new CSR on the new EJBCA, and then issue
>> a new cert?
>>
>> 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
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: <oh...@ya...> - 2019-06-26 11:02:41
|
Hi,
I ran into this problem AFTER I went through the process of configuring EJBCA to include a new CA's CRLs, so that is why I posted the msg below in this thread, but you are probably right that I should make a new thread for this, which I will do after this.
Thanks,
Jim
On Wednesday, June 26, 2019, 4:12:45 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Hi,
I think this is not related to the subject of this email right? In that
case could you start a new thread, otherwise it is likely that some
questions wrapped into the same thread (i.e. wrong subject) will get
lost in the mist :-)
Cheers,
TOmas
On 2019-06-25 22:16, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I tried adding a new CA/CRL:
>
> - I added the CA cert to EJBCA
> - I tried to import the CRL and didn't give any errors, but the CRL was
> not imported.
>
> I checked the logs and see this below. Why isn't it importing the CRL?
>
> 16:08:00,166 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default
> task-9) 2019-06-25
> 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401
> 16:08:00,178 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default
> task-9) CA: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US
> 16:08:00,181 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean]
> (default task-9) Error retrieving CRL for issuer
> 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0.
> 16:08:00,181 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default
> task-9) Found 1 new entires in full CRL number 3 issued by
> 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to pr
> 16:08:00,183 INFO
> [org.cesecore.certificates.certificate.CertificateStoreSessionBean]
> (default task-9) Adding limited CertificateData entry with
> fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0r=16B902B1B87,
> issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'
> 16:08:00,183 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default
> task-9) 2019-06-25
> 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401
> 16:08:00,190 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean]
> (default task-9) Error storing CRL with CRLNumber=3, issuerDN
> 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.eption
> at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244)
> at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86)
> at
> org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at
> org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at
> org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:185)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:364)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at
> org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72)
> at
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> at
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at
> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> at
> org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view110.storeCRL(Unknown
> Source)
> at
> org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at
> org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at
> org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.pro
>
> W
> On Tuesday, June 25, 2019, 2:07:08 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> FYI, I was able to use Adminweb to create a new CSR and then I issued a
> new signing cert with the OCSPSign purpose and I was then able to import
> into Adminweb, and I was able to test some good and bad requests (see
> below).
>
> I think that we will still need to be able use a cert/key pair that we
> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.),
> so is there a way to do that?
>
>
> BTW, also, I am still not clear what we need to do incrementally to add
> more CRLs from different CAs? I mean for example, if there are 10 more
> CAs with CRLs and we want our EJBCA to do the OCSP responding for those,
> what are the steps we need to do to configure EJBCA to do that?
>
>
> Here's the test:
>
> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile
> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text
> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
> OCSP Request Data:
> Version: 1 (0x0)
> Requestor List:
> Certificate ID:
> Hash Algorithm: sha1
> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
> Serial Number: 8486394C03E1F5D9
> Request Extensions:
> OCSP Nonce:
> 041061AAC22F8FD77F35FEEA879361B29CD9
> Response verify OK
> 0x8486394C03E1F5D9: WARNING: Status times invalid.
> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet
> valid:crypto\ocsp\ocsp_cl.c:320:
> revoked
> This Update: Jun 25 17:56:47 2019 GMT
> Reason: unspecified
> Revocation Time: May 26 12:30:44 2019 GMT
>
>
>
>
> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to create the Internal Key Binding for the OCSP Responder on
> the EJBCA that I just built.
>
> In the Adminweb, I have created the Internal Key Binding, but now I am
> trying to do the "Import externally issued certificate".
>
> I have the Internal Key Binding that I created in the OVA based system
> previously, and I was hoping that I wouldn't need to issue a new cert
> for this new system, so I was wondering if there is any way to get the
> private key from that OVA based system so that I can do the import into
> the new EJBCA configuration?
>
> Or, is the only way to create a new CSR on the new EJBCA, and then issue
> a new cert?
>
> 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-06-26 11:01:50
|
On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote: > -- Re. the question about CSR: So right now, it looks like to issue the > signing cert, the process is you click the CSR button in the Adminweb to > create the CSR, then we use that CSR to get a signing certificate > issued, and then we import that signing cert. > > That means if we are standing up EJBCA for production in a new > environment, we have to do the above (use Adminweb to create a new CSR, > etc.), but here, when we build a new production environment, we > generally want to have all the artifacts that are needed to build the > new production environment. Specifically, relative to EJBCA, we have our > own process for issuing certs, where our process ends up with the > private key and cert and maybe a P12, and that we would want to be able > to use those to construct the new production environment, rather than > have the installer click a button to create a CSR in the production > environment and then somehow get the CSR over to our CA and then get the > CA to issue a cert, and then somehow get the new cert transferred back > over to the production environment. > > So, what I was looking for is if there is a way to just use our own > issued key and cert (or a P12) instead of using Adminweb to create the > CSR, etc.? You can do everything using the CLI, so you can automate that. The keys are in a crypto token, you can export and import crypto tokens. > -- Re. the question about "incrementally to add more CRLs from different > CAs", I think I wasn't clear about what I meant. > > I didn't mean updating a CRL for a CA that we had already setup > previously in the EJBCA OCSP Responder . > > > Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our > EJBCA OCSP Responder to be able to be able to provide OCSP responses > for, what do we need to do with EJBCA to do that? > > So, for example, we now want our EJBCA OCSP Responder to do OCSP > responding for 2 more CAs, and we have: > > CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl) > CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl) > > > I think (guess) that the process is something like: > > Add the new CA cert for CA1 to EJBCA using the Adminweb, then > In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the > CA1 CA > > Then: > > Add the new CA cert for CA2 to EJBCA using the Adminweb, then > In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the > CA1 CA > > > > My question is: Is the above 2 steps (Add the CA cert for the new CA and > then import the CRL file for the new CA) the only steps we need to do in > this case, in order to get EJBCA OCSP Responder to be able to respond to > OCSP requests for that new CA/CRL? OCSP is done by OCSP Key Bindings. You have to create a new OCSP key binding for every new CA you want the OCSP responder to answer for (the OCSP signing key must be signed by the CA). The CRL import is just to update the revocation database so the OCSP responder knows which certificates are revoked. > > > > > Thans, > Jim > > P.S. I am having problems with responding format in Yahoo email, so if > response looks weird my apologies. > > > > > On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson > <to...@pr...> wrote: > > > > On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote: >> Hi, >> >> FYI, I was able to use Adminweb to create a new CSR and then I issued a >> new signing cert with the OCSPSign purpose and I was then able to import >> into Adminweb, and I was able to test some good and bad requests (see >> below). >> >> I think that we will still need to be able use a cert/key pair that we >> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), >> so is there a way to do that? > > I do not understand what you mean by this. > If you want the OCSP Key Binding in EJBCA to generate the key, why would > the CSR come from outside of EJBCA? > You can always issue certificates to CSRs with EJCBA...if you have a CSR... > >> BTW, also, I am still not clear what we need to do incrementally to add >> more CRLs from different CAs? I mean for example, if there are 10 more >> CAs with CRLs and we want our EJBCA to do the OCSP responding for those, >> what are the steps we need to do to configure EJBCA to do that? > > There is a service called "CRL Downloader" under Sevrices that can be > used to automate import/update of CRLs. It is documented among the > "Services". > > >> >> >> Here's the test: >> >> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile >> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text >> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp >> OCSP Request Data: >> Version: 1 (0x0) >> Requestor List: >> Certificate ID: >> Hash Algorithm: sha1 >> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55 >> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E >> Serial Number: 8486394C03E1F5D9 >> Request Extensions: >> OCSP Nonce: >> 041061AAC22F8FD77F35FEEA879361B29CD9 >> Response verify OK >> 0x8486394C03E1F5D9: WARNING: Status times invalid. >> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet >> valid:crypto\ocsp\ocsp_cl.c:320: >> revoked >> This Update: Jun 25 17:56:47 2019 GMT >> Reason: unspecified >> Revocation Time: May 26 12:30:44 2019 GMT >> >> >> >> >> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya... > <mailto:oh...@ya...>> wrote: >> >> >> Hi, >> >> I am trying to create the Internal Key Binding for the OCSP Responder on >> the EJBCA that I just built. >> >> In the Adminweb, I have created the Internal Key Binding, but now I am >> trying to do the "Import externally issued certificate". >> >> I have the Internal Key Binding that I created in the OVA based system >> previously, and I was hoping that I wouldn't need to issue a new cert >> for this new system, so I was wondering if there is any way to get the >> private key from that OVA based system so that I can do the import into >> the new EJBCA configuration? >> >> Or, is the only way to create a new CSR on the new EJBCA, and then issue >> a new cert? >> >> 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: <oh...@ya...> - 2019-06-26 10:41:16
|
-- Re. the question about CSR: So right now, it looks like to issue the signing cert, the process is you click the CSR button in the Adminweb to create the CSR, then we use that CSR to get a signing certificate issued, and then we import that signing cert.
That means if we are standing up EJBCA for production in a new environment, we have to do the above (use Adminweb to create a new CSR, etc.), but here, when we build a new production environment, we generally want to have all the artifacts that are needed to build the new production environment. Specifically, relative to EJBCA, we have our own process for issuing certs, where our process ends up with the private key and cert and maybe a P12, and that we would want to be able to use those to construct the new production environment, rather than have the installer click a button to create a CSR in the production environment and then somehow get the CSR over to our CA and then get the CA to issue a cert, and then somehow get the new cert transferred back over to the production environment.
So, what I was looking for is if there is a way to just use our own issued key and cert (or a P12) instead of using Adminweb to create the CSR, etc.?
-- Re. the question about "incrementally to add more CRLs from different CAs", I think I wasn't clear about what I meant.
I didn't mean updating a CRL for a CA that we had already setup previously in the EJBCA OCSP Responder .
Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our EJBCA OCSP Responder to be able to be able to provide OCSP responses for, what do we need to do with EJBCA to do that?
So, for example, we now want our EJBCA OCSP Responder to do OCSP responding for 2 more CAs, and we have:
CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl)
CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl)
I think (guess) that the process is something like:
Add the new CA cert for CA1 to EJBCA using the Adminweb, then
In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the CA1 CA
Then:
Add the new CA cert for CA2 to EJBCA using the Adminweb, then
In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the CA1 CA
My question is: Is the above 2 steps (Add the CA cert for the new CA and then import the CRL file for the new CA) the only steps we need to do in this case, in order to get EJBCA OCSP Responder to be able to respond to OCSP requests for that new CA/CRL?
Thans,
Jim
P.S. I am having problems with responding format in Yahoo email, so if response looks weird my apologies.
On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> FYI, I was able to use Adminweb to create a new CSR and then I issued a
> new signing cert with the OCSPSign purpose and I was then able to import
> into Adminweb, and I was able to test some good and bad requests (see
> below).
>
> I think that we will still need to be able use a cert/key pair that we
> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.),
> so is there a way to do that?
I do not understand what you mean by this.
If you want the OCSP Key Binding in EJBCA to generate the key, why would
the CSR come from outside of EJBCA?
You can always issue certificates to CSRs with EJCBA...if you have a CSR...
> BTW, also, I am still not clear what we need to do incrementally to add
> more CRLs from different CAs? I mean for example, if there are 10 more
> CAs with CRLs and we want our EJBCA to do the OCSP responding for those,
> what are the steps we need to do to configure EJBCA to do that?
There is a service called "CRL Downloader" under Sevrices that can be
used to automate import/update of CRLs. It is documented among the
"Services".
>
>
> Here's the test:
>
> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile
> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text
> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
> OCSP Request Data:
> Version: 1 (0x0)
> Requestor List:
> Certificate ID:
> Hash Algorithm: sha1
> Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
> Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
> Serial Number: 8486394C03E1F5D9
> Request Extensions:
> OCSP Nonce:
> 041061AAC22F8FD77F35FEEA879361B29CD9
> Response verify OK
> 0x8486394C03E1F5D9: WARNING: Status times invalid.
> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet
> valid:crypto\ocsp\ocsp_cl.c:320:
> revoked
> This Update: Jun 25 17:56:47 2019 GMT
> Reason: unspecified
> Revocation Time: May 26 12:30:44 2019 GMT
>
>
>
>
> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to create the Internal Key Binding for the OCSP Responder on
> the EJBCA that I just built.
>
> In the Adminweb, I have created the Internal Key Binding, but now I am
> trying to do the "Import externally issued certificate".
>
> I have the Internal Key Binding that I created in the OVA based system
> previously, and I was hoping that I wouldn't need to issue a new cert
> for this new system, so I was wondering if there is any way to get the
> private key from that OVA based system so that I can do the import into
> the new EJBCA configuration?
>
> Or, is the only way to create a new CSR on the new EJBCA, and then issue
> a new cert?
>
> 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-06-26 09:10:01
|
On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote: > Hi, > > FYI, I was able to use Adminweb to create a new CSR and then I issued a > new signing cert with the OCSPSign purpose and I was then able to import > into Adminweb, and I was able to test some good and bad requests (see > below). > > I think that we will still need to be able use a cert/key pair that we > generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), > so is there a way to do that? I do not understand what you mean by this. If you want the OCSP Key Binding in EJBCA to generate the key, why would the CSR come from outside of EJBCA? You can always issue certificates to CSRs with EJCBA...if you have a CSR... > BTW, also, I am still not clear what we need to do incrementally to add > more CRLs from different CAs? I mean for example, if there are 10 more > CAs with CRLs and we want our EJBCA to do the OCSP responding for those, > what are the steps we need to do to configure EJBCA to do that? There is a service called "CRL Downloader" under Sevrices that can be used to automate import/update of CRLs. It is documented among the "Services". > > > Here's the test: > > E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile > ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text > -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55 > Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E > Serial Number: 8486394C03E1F5D9 > Request Extensions: > OCSP Nonce: > 041061AAC22F8FD77F35FEEA879361B29CD9 > Response verify OK > 0x8486394C03E1F5D9: WARNING: Status times invalid. > 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet > valid:crypto\ocsp\ocsp_cl.c:320: > revoked > This Update: Jun 25 17:56:47 2019 GMT > Reason: unspecified > Revocation Time: May 26 12:30:44 2019 GMT > > > > > On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote: > > > Hi, > > I am trying to create the Internal Key Binding for the OCSP Responder on > the EJBCA that I just built. > > In the Adminweb, I have created the Internal Key Binding, but now I am > trying to do the "Import externally issued certificate". > > I have the Internal Key Binding that I created in the OVA based system > previously, and I was hoping that I wouldn't need to issue a new cert > for this new system, so I was wondering if there is any way to get the > private key from that OVA based system so that I can do the import into > the new EJBCA configuration? > > Or, is the only way to create a new CSR on the new EJBCA, and then issue > a new cert? > > Thanks, > Jim > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-06-26 08:12:13
|
Hi, I think this is not related to the subject of this email right? In that case could you start a new thread, otherwise it is likely that some questions wrapped into the same thread (i.e. wrong subject) will get lost in the mist :-) Cheers, TOmas On 2019-06-25 22:16, ohaya--- via Ejbca-develop wrote: > Hi, > > I tried adding a new CA/CRL: > > - I added the CA cert to EJBCA > - I tried to import the CRL and didn't give any errors, but the CRL was > not imported. > > I checked the logs and see this below. Why isn't it importing the CRL? > > 16:08:00,166 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default > task-9) 2019-06-25 > 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401 > 16:08:00,178 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default > task-9) CA: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US > 16:08:00,181 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] > (default task-9) Error retrieving CRL for issuer > 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0. > 16:08:00,181 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default > task-9) Found 1 new entires in full CRL number 3 issued by > 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to pr > 16:08:00,183 INFO > [org.cesecore.certificates.certificate.CertificateStoreSessionBean] > (default task-9) Adding limited CertificateData entry with > fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0r=16B902B1B87, > issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' > 16:08:00,183 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default > task-9) 2019-06-25 > 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401 > 16:08:00,190 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] > (default task-9) Error storing CRL with CRLNumber=3, issuerDN > 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.eption > at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244) > at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86) > at > org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at > org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90) > at > org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) > at > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at > org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:185) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:364) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at > org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72) > at > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) > at > org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) > at > org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at > org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at > org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) > at > org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view110.storeCRL(Unknown > Source) > at > org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at > org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90) > at > org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) > at > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.pro > > W > On Tuesday, June 25, 2019, 2:07:08 PM EDT, <oh...@ya...> wrote: > > > Hi, > > FYI, I was able to use Adminweb to create a new CSR and then I issued a > new signing cert with the OCSPSign purpose and I was then able to import > into Adminweb, and I was able to test some good and bad requests (see > below). > > I think that we will still need to be able use a cert/key pair that we > generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), > so is there a way to do that? > > > BTW, also, I am still not clear what we need to do incrementally to add > more CRLs from different CAs? I mean for example, if there are 10 more > CAs with CRLs and we want our EJBCA to do the OCSP responding for those, > what are the steps we need to do to configure EJBCA to do that? > > > Here's the test: > > E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile > ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text > -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55 > Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E > Serial Number: 8486394C03E1F5D9 > Request Extensions: > OCSP Nonce: > 041061AAC22F8FD77F35FEEA879361B29CD9 > Response verify OK > 0x8486394C03E1F5D9: WARNING: Status times invalid. > 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet > valid:crypto\ocsp\ocsp_cl.c:320: > revoked > This Update: Jun 25 17:56:47 2019 GMT > Reason: unspecified > Revocation Time: May 26 12:30:44 2019 GMT > > > > > On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote: > > > Hi, > > I am trying to create the Internal Key Binding for the OCSP Responder on > the EJBCA that I just built. > > In the Adminweb, I have created the Internal Key Binding, but now I am > trying to do the "Import externally issued certificate". > > I have the Internal Key Binding that I created in the OVA based system > previously, and I was hoping that I wouldn't need to issue a new cert > for this new system, so I was wondering if there is any way to get the > private key from that OVA based system so that I can do the import into > the new EJBCA configuration? > > Or, is the only way to create a new CSR on the new EJBCA, and then issue > a new cert? > > Thanks, > Jim > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: <oh...@ya...> - 2019-06-25 20:16:20
|
Hi,
I tried adding a new CA/CRL:
- I added the CA cert to EJBCA
- I tried to import the CRL and didn't give any errors, but the CRL was not imported.
I checked the logs and see this below. Why isn't it importing the CRL?
16:08:00,166 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-9) 2019-06-25 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401
16:08:00,178 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-9) CA: CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US
16:08:00,181 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-9) Error retrieving CRL for issuer 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' with CRL number 0.
16:08:00,181 INFO [org.ejbca.core.ejb.crl.ImportCrlSessionBean] (default task-9) Found 1 new entires in full CRL number 3 issued by 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US' compared to pr
16:08:00,183 INFO [org.cesecore.certificates.certificate.CertificateStoreSessionBean] (default task-9) Adding limited CertificateData entry with fingerprint=e0a287931576859f315d32ba0fc629e21ead7c0r=16B902B1B87, issuerDn='CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'
16:08:00,183 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-9) 2019-06-25 16:08:00-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/ca/598150401
16:08:00,190 ERROR [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-9) Error storing CRL with CRLNumber=3, issuerDN 'CN=SimpleAuthorityCA,OU=simpleou,O=simpleo,C=US'. : java.lang.eption
at org.cesecore.certificates.crl.CRLData.setNextUpdate(CRLData.java:244)
at org.cesecore.certificates.crl.CRLData.<init>(CRLData.java:86)
at org.cesecore.certificates.crl.CrlStoreSessionBean.storeCRL(CrlStoreSessionBean.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:185)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:364)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
at org.cesecore.certificates.crl.CrlStoreSessionLocal$$$view110.storeCRL(Unknown Source)
at org.ejbca.core.ejb.crl.ImportCrlSessionBean.importCrl(ImportCrlSessionBean.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.pro
W
On Tuesday, June 25, 2019, 2:07:08 PM EDT, <oh...@ya...> wrote:
Hi,
FYI, I was able to use Adminweb to create a new CSR and then I issued a new signing cert with the OCSPSign purpose and I was then able to import into Adminweb, and I was able to test some good and bad requests (see below).
I think that we will still need to be able use a cert/key pair that we generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), so is there a way to do that?
BTW, also, I am still not clear what we need to do incrementally to add more CRLs from different CAs? I mean for example, if there are 10 more CAs with CRLs and we want our EJBCA to do the OCSP responding for those, what are the steps we need to do to configure EJBCA to do that?
Here's the test:
E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
Serial Number: 8486394C03E1F5D9
Request Extensions:
OCSP Nonce:
041061AAC22F8FD77F35FEEA879361B29CD9
Response verify OK
0x8486394C03E1F5D9: WARNING: Status times invalid.
388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet valid:crypto\ocsp\ocsp_cl.c:320:
revoked
This Update: Jun 25 17:56:47 2019 GMT
Reason: unspecified
Revocation Time: May 26 12:30:44 2019 GMT
On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote:
Hi,
I am trying to create the Internal Key Binding for the OCSP Responder on the EJBCA that I just built.
In the Adminweb, I have created the Internal Key Binding, but now I am trying to do the "Import externally issued certificate".
I have the Internal Key Binding that I created in the OVA based system previously, and I was hoping that I wouldn't need to issue a new cert for this new system, so I was wondering if there is any way to get the private key from that OVA based system so that I can do the import into the new EJBCA configuration?
Or, is the only way to create a new CSR on the new EJBCA, and then issue a new cert?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-25 18:07:04
|
Hi,
FYI, I was able to use Adminweb to create a new CSR and then I issued a new signing cert with the OCSPSign purpose and I was then able to import into Adminweb, and I was able to test some good and bad requests (see below).
I think that we will still need to be able use a cert/key pair that we generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.), so is there a way to do that?
BTW, also, I am still not clear what we need to do incrementally to add more CRLs from different CAs? I mean for example, if there are 10 more CAs with CRLs and we want our EJBCA to do the OCSP responding for those, what are the steps we need to do to configure EJBCA to do that?
Here's the test:
E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55
Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E
Serial Number: 8486394C03E1F5D9
Request Extensions:
OCSP Nonce:
041061AAC22F8FD77F35FEEA879361B29CD9
Response verify OK
0x8486394C03E1F5D9: WARNING: Status times invalid.
388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet valid:crypto\ocsp\ocsp_cl.c:320:
revoked
This Update: Jun 25 17:56:47 2019 GMT
Reason: unspecified
Revocation Time: May 26 12:30:44 2019 GMT
On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...> wrote:
Hi,
I am trying to create the Internal Key Binding for the OCSP Responder on the EJBCA that I just built.
In the Adminweb, I have created the Internal Key Binding, but now I am trying to do the "Import externally issued certificate".
I have the Internal Key Binding that I created in the OVA based system previously, and I was hoping that I wouldn't need to issue a new cert for this new system, so I was wondering if there is any way to get the private key from that OVA based system so that I can do the import into the new EJBCA configuration?
Or, is the only way to create a new CSR on the new EJBCA, and then issue a new cert?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-25 17:37:28
|
Hi, I am trying to create the Internal Key Binding for the OCSP Responder on the EJBCA that I just built. In the Adminweb, I have created the Internal Key Binding, but now I am trying to do the "Import externally issued certificate". I have the Internal Key Binding that I created in the OVA based system previously, and I was hoping that I wouldn't need to issue a new cert for this new system, so I was wondering if there is any way to get the private key from that OVA based system so that I can do the import into the new EJBCA configuration? Or, is the only way to create a new CSR on the new EJBCA, and then issue a new cert? Thanks, Jim |
|
From: o h. <oh...@ya...> - 2019-06-25 15:27:03
|
Hi,
In the Adminweb, under the "Manage Crypto Tokens" I see a line for the ManagementCA, but there is a red X in 'Active'.
I think that I need to Activate it, but it looks like I need an authentication code or something to do that.
How can I activate the crypto token?
Thanks,Jim
On Tuesday, June 25, 2019, 9:33:47 AM UTC, Tomas Gustavsson <to...@pr...> wrote:
An EJBCA installed as a CA can work as a VA as well. You can create OCSP
key binding for other CAs. There is documentation for OCSP on database
structures and such if you want to manually sync databases (you can work
with your VA in many different ways)
One feature related to VAs, making it automated, is Peer Systems. This
automation is an Enterprise feature however.
https://www.ejbca.org/docs/Peer_Systems.html
Regards,
Tomas
---
PrimeKey Tech Days 2019
Stockholm, Sweden
17-18 September
www.primekey.com/tech-days
On 2019-06-25 11:14, o haya via Ejbca-develop wrote:
> Hi,
>
> It took me the whole weekend plus most of today/tonight, but I was now
> able to build EJBCA under JBOSS 7.2.
>
> Unfortunately, I didn't see your response, so I took the "Install EJBCA
> as CA with a Management CA" branch on this page:
>
> https://www.ejbca.org/docs/Installing_EJBCA.html
>
> instead of the "Install EJBCA as an RA or VA" branch, so I am going to
> have to try again with the VA installation.
>
> So, to be clear, you think that if I install the EJBCA as VA, that will
> allow us to have an OCSP Responder that can support multiple CRLs from
> different CAs?
>
> Is that correct?
>
> Thanks,
> Jim
>
>
>
> On Tuesday, June 25, 2019, 8:32:25 AM UTC, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
> Hi,
>
> Yes, a VA is what you a looking for, at least that's what it sounds like.
>
> Regards,
> Tomas
> ---
> PrimeKey Tech Days 2019
> Stockholm, Sweden
> 17-18 September
> www.primekey.com/tech-days
>
>
> On 2019-06-21 14:35, o haya via Ejbca-develop wrote:
>> [Re-sending to the mailing list because I think I was sending to the
>> wrong place... plus I wasn't seeing my post on the archives.]
>>
>>
>> Hi,
>>
>> Previously, we had worked with the EJBCA OCSP responder by using the
>> EJBCA OVA and then configuring an OCSP Responder.
>>
>> Now, we want to try to stand up a new, standalone EJBCA OCSP Responder.
>>
>> By "standalone", I mean an OCSP Responder, only without the EJBCA CA
>> functionality, where the OCSP Responder can host/support the OCSP
>> Responder functionality for CRLs from multiple ("external") CAs.
>>
>> I've been looking through the EJBCA documentation, but I am not sure how
>> to accomplish that?
>>
>> I have found this page:
>>
>> https://www.ejbca.org/docs/Installing_EJBCA.html
>>
>> And I was wondering if the 3rd bullet, "Install EJBCA as an RA or VA",
>> is what I need to follow, and setup EJBCA as a VA (Validation Authority?)?
>>
>> If not, can someone point me to the procedure for standing up such "a
>> standalone EJBCA OCSP Responder"?
>>
>> 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
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Tomas G. <to...@pr...> - 2019-06-25 09:33:33
|
An EJBCA installed as a CA can work as a VA as well. You can create OCSP key binding for other CAs. There is documentation for OCSP on database structures and such if you want to manually sync databases (you can work with your VA in many different ways) One feature related to VAs, making it automated, is Peer Systems. This automation is an Enterprise feature however. https://www.ejbca.org/docs/Peer_Systems.html Regards, Tomas --- PrimeKey Tech Days 2019 Stockholm, Sweden 17-18 September www.primekey.com/tech-days On 2019-06-25 11:14, o haya via Ejbca-develop wrote: > Hi, > > It took me the whole weekend plus most of today/tonight, but I was now > able to build EJBCA under JBOSS 7.2. > > Unfortunately, I didn't see your response, so I took the "Install EJBCA > as CA with a Management CA" branch on this page: > > https://www.ejbca.org/docs/Installing_EJBCA.html > > instead of the "Install EJBCA as an RA or VA" branch, so I am going to > have to try again with the VA installation. > > So, to be clear, you think that if I install the EJBCA as VA, that will > allow us to have an OCSP Responder that can support multiple CRLs from > different CAs? > > Is that correct? > > Thanks, > Jim > > > > On Tuesday, June 25, 2019, 8:32:25 AM UTC, Tomas Gustavsson > <to...@pr...> wrote: > > > Hi, > > Yes, a VA is what you a looking for, at least that's what it sounds like. > > Regards, > Tomas > --- > PrimeKey Tech Days 2019 > Stockholm, Sweden > 17-18 September > www.primekey.com/tech-days > > > On 2019-06-21 14:35, o haya via Ejbca-develop wrote: >> [Re-sending to the mailing list because I think I was sending to the >> wrong place... plus I wasn't seeing my post on the archives.] >> >> >> Hi, >> >> Previously, we had worked with the EJBCA OCSP responder by using the >> EJBCA OVA and then configuring an OCSP Responder. >> >> Now, we want to try to stand up a new, standalone EJBCA OCSP Responder. >> >> By "standalone", I mean an OCSP Responder, only without the EJBCA CA >> functionality, where the OCSP Responder can host/support the OCSP >> Responder functionality for CRLs from multiple ("external") CAs. >> >> I've been looking through the EJBCA documentation, but I am not sure how >> to accomplish that? >> >> I have found this page: >> >> https://www.ejbca.org/docs/Installing_EJBCA.html >> >> And I was wondering if the 3rd bullet, "Install EJBCA as an RA or VA", >> is what I need to follow, and setup EJBCA as a VA (Validation Authority?)? >> >> If not, can someone point me to the procedure for standing up such "a >> standalone EJBCA OCSP Responder"? >> >> 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: o h. <oh...@ya...> - 2019-06-25 09:14:57
|
Hi, It took me the whole weekend plus most of today/tonight, but I was now able to build EJBCA under JBOSS 7.2. Unfortunately, I didn't see your response, so I took the "Install EJBCA as CA with a Management CA" branch on this page: https://www.ejbca.org/docs/Installing_EJBCA.html instead of the "Install EJBCA as an RA or VA" branch, so I am going to have to try again with the VA installation. So, to be clear, you think that if I install the EJBCA as VA, that will allow us to have an OCSP Responder that can support multiple CRLs from different CAs? Is that correct? Thanks,Jim On Tuesday, June 25, 2019, 8:32:25 AM UTC, Tomas Gustavsson <to...@pr...> wrote: Hi, Yes, a VA is what you a looking for, at least that's what it sounds like. Regards, Tomas --- PrimeKey Tech Days 2019 Stockholm, Sweden 17-18 September www.primekey.com/tech-days On 2019-06-21 14:35, o haya via Ejbca-develop wrote: > [Re-sending to the mailing list because I think I was sending to the > wrong place... plus I wasn't seeing my post on the archives.] > > > Hi, > > Previously, we had worked with the EJBCA OCSP responder by using the > EJBCA OVA and then configuring an OCSP Responder. > > Now, we want to try to stand up a new, standalone EJBCA OCSP Responder. > > By "standalone", I mean an OCSP Responder, only without the EJBCA CA > functionality, where the OCSP Responder can host/support the OCSP > Responder functionality for CRLs from multiple ("external") CAs. > > I've been looking through the EJBCA documentation, but I am not sure how > to accomplish that? > > I have found this page: > > https://www.ejbca.org/docs/Installing_EJBCA.html > > And I was wondering if the 3rd bullet, "Install EJBCA as an RA or VA", > is what I need to follow, and setup EJBCA as a VA (Validation Authority?)? > > If not, can someone point me to the procedure for standing up such "a > standalone EJBCA OCSP Responder"? > > 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-06-25 08:33:50
|
Hi, My guess is that some previous command failed and was not performed, leading to the "unmet dependency" you see here. Regards, Tomas -- PrimeKey Tech Days 2019 Stockholm, Sweden 17-18 September www.primekey.com/tech-days On 2019-06-21 21:54, o haya via Ejbca-develop wrote: > I am trying to configure the JBoss remoting: > https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.0.html > > > When I try to run this in the CLI when I am setting up the remoting: > > |/subsystem=remoting/http-connector=http-remoting-connector:remove| > > I am getting the following: > > [sta...@19...:9990 /] > /subsystem=remoting/http-connector=http-remoting-connector:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0441: Operation has resulted in > failed or missing services > WFLYCTL0184: New missing/unsatisfied dependencies: > service > jboss.remoting.remotingConnectorInfoService.http-remoting-connector > (missing) dependents: [service > org.wildfly.clustering.cache.registry-entry.ejb.client-mappings] > WFLYCTL0448: 4 additional services are down due to their dependencies > being missing or failed", > "rolled-back" => true > } > > > > > Also, when I run the following to setup TLS: > > /subsystem=undertow/server=default-server/http-listener=http:write-attribute(name=redirect-socket, > value="httpspriv") > > I am getting the following: > > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0369: Required capabilities are not > available: > org.wildfly.network.socket-binding.httpspriv; Possible registration > points for this capability: > /socket-binding-group=*/socket-binding=*", > "rolled-back" => true > } > > > > How can I correct those errors? > > Thanks, > Jim > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-06-25 08:32:00
|
Hi, Yes, a VA is what you a looking for, at least that's what it sounds like. Regards, Tomas --- PrimeKey Tech Days 2019 Stockholm, Sweden 17-18 September www.primekey.com/tech-days On 2019-06-21 14:35, o haya via Ejbca-develop wrote: > [Re-sending to the mailing list because I think I was sending to the > wrong place... plus I wasn't seeing my post on the archives.] > > > Hi, > > Previously, we had worked with the EJBCA OCSP responder by using the > EJBCA OVA and then configuring an OCSP Responder. > > Now, we want to try to stand up a new, standalone EJBCA OCSP Responder. > > By "standalone", I mean an OCSP Responder, only without the EJBCA CA > functionality, where the OCSP Responder can host/support the OCSP > Responder functionality for CRLs from multiple ("external") CAs. > > I've been looking through the EJBCA documentation, but I am not sure how > to accomplish that? > > I have found this page: > > https://www.ejbca.org/docs/Installing_EJBCA.html > > And I was wondering if the 3rd bullet, "Install EJBCA as an RA or VA", > is what I need to follow, and setup EJBCA as a VA (Validation Authority?)? > > If not, can someone point me to the procedure for standing up such "a > standalone EJBCA OCSP Responder"? > > Thanks, > Jim > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: o h. <oh...@ya...> - 2019-06-23 11:30:37
|
Hi, I was finally able to get EJBCA installed on JBOSS 7.2 but when I try to access the admin website at https://localhost:8443/ejbca/adminweb using Firefox, I am getting an SSL_ERROR_NO_CYPHER_OVERLAP and cannot connect. FYI, I have imported the P12 into Firefox, and I can see the cert in Firefox. How can I get this working? Thanks,Jim |
|
From: o h. <oh...@ya...> - 2019-06-21 19:54:55
|
I am trying to configure the JBoss remoting: https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.0.html When I try to run this in the CLI when I am setting up the remoting: /subsystem=remoting/http-connector=http-remoting-connector:remove I am getting the following: [sta...@19...:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services WFLYCTL0184: New missing/unsatisfied dependencies: service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings] WFLYCTL0448: 4 additional services are down due to their dependencies being missing or failed", "rolled-back" => true } Also, when I run the following to setup TLS: /subsystem=undertow/server=default-server/http-listener=http:write-attribute(name=redirect-socket, value="httpspriv") I am getting the following: { "outcome" => "failed", "failure-description" => "WFLYCTL0369: Required capabilities are not available: org.wildfly.network.socket-binding.httpspriv; Possible registration points for this capability: /socket-binding-group=*/socket-binding=*", "rolled-back" => true } How can I correct those errors? Thanks,Jim |
|
From: o h. <oh...@ya...> - 2019-06-21 12:35:48
|
[Re-sending to the mailing list because I think I was sending to the wrong place... plus I wasn't seeing my post on the archives.]
Hi,
Previously, we had worked with the EJBCA OCSP responder by using the EJBCA OVA and then configuring an OCSP Responder.
Now, we want to try to stand up a new, standalone EJBCA OCSP Responder.
By "standalone", I mean an OCSP Responder, only without the EJBCA CA functionality, where the OCSP Responder can host/support the OCSP Responder functionality for CRLs from multiple ("external") CAs.
I've been looking through the EJBCA documentation, but I am not sure how to accomplish that?
I have found this page:
https://www.ejbca.org/docs/Installing_EJBCA.html
And I was wondering if the 3rd bullet, "Install EJBCA as an RA or VA", is what I need to follow, and setup EJBCA as a VA (Validation Authority?)?
If not, can someone point me to the procedure for standing up such "a standalone EJBCA OCSP Responder"?
Thanks,
Jim
|
|
From: Tomas G. <to...@pr...> - 2019-06-09 17:04:14
|
Hi Jaime, The change makes sense to me. It must be optional however. Any behavior change that changes behavior like this need to be optional. We are in fact in the pipe-line of adding configuration of archive cutoff to GUI configuration for the OCPS Key Binding. Value can be different for differn4t key bindings, and needs to be more easily configurable than in the properties file. I see then three options: - never use archive cutoff - always use archive cutoff - use archive cutoff for expired certificates As such, the patch, good it may be, does not make sens at this moment as it needs to change soon. Any possibility that you would work on your patch with this in mind? Regards, Tomas On 2019-06-09 17:42, Jaime Hablutzel wrote: > Hi, I think that always including the Archive Cutoff OCSP extension (if > enabled) in responses would be really helpful. Now, some illustrative > examples: > > Status for a given certificate might not be available anymore (e.g. > CertificateStatus.NOT_AVAILABLE), but it could have been good or revoked > in the past, for example, for an expired certificate deleted after the > retention interval got surpassed, so including the archive cutoff date > warns clients of this possibility, which is specially important when > "Non existing is good" is enabled, because the server could be > responding good now for a deleted certificate previously revoked. > > If certificate status is still available > (CertificateStatus.REVOKED or CertificateStatus.OK), to provide the > archive cutoff would help clients to learn the server retention > interval, so they can realize until when the OCSP server guarantees to > keep certificate status after expiration, e.g. a client might be > planning to demonstrate in a trial (in a given date in the future) that > a signature generated in the past was generated with a valid certificate > and knowing the archive cutoff would be helpful for him to know until > when that information will be available. > > Now, quoting from RFC 6960, "4.4.4. Archive Cutoff": > > OCSP servers that provide support for such a historical reference > *SHOULD include an archive cutoff date extension in responses*. > > > It doesn't say that the extension should be included only for > certificates under a given criteria (e.g. only expired ones), it just > say that if a server support historical reference (e.g. a regular EJBCA > setup), the archive cutoff should be included in responses, where > "responses" could be interpreted as "all responses" for the sake of > always providing clients with this helpful information. > > Finally, I’m attaching a proposed patch over r32508. Just note that > introducing this patch would require changes in > https://www.ejbca.org/docs/Archive_Cutoff.html, for example, the > following wouldn't be true anymore: > > Archive Cutoff is only returned in the OCSP responses for expired > certificates. > > > Jaime Hablutzel - +51 994690880 > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
106 messages has been excluded from this view by a project administrator.
