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: <oh...@ya...> - 2019-06-28 13:37:28
|
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: <oh...@ya...> - 2019-06-28 13:28:11
|
Are you talking about this:
[root@ejbca bin]# ./ejbca.sh --help
--------------------------------
The following categories are available:
[ ca | config | cryptotoken | hardtoken | keybind | ocsp | ra | roles | service | svgtemplate ]
--------------------------------
And the following commands are available:
asn1dump Dumps PEM or DER encoded certificate as readable ASN.1
batch Batch generate keys and certificates.
clearcache Clears caches used internally by EJBCA.
createcert Issue a certificate for a user based on a CSR
encryptpwd Encrypts a password
upgrade Upgrade command. Use 'ant upgrade' instead of running this directly.
Type a command and "--help" for more information.
I don't see where it has a command for import a CRL so far?
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: <oh...@ya...> - 2019-06-28 13:01:12
|
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Tomas G. <to...@pr...> - 2019-06-28 12:29:46
|
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in size limit for uploads. As you are using the Web UI for this, you may try the CLI instead as that does not go via the web interface. Cheers, Tomas PS: I will be away on vacation after today and will not be active in this list for a couple of weeks now. On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote: > Does anyone have any solution to this problem? > > Thanks, > Jim > > > On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote: > > > Hi, > > I tried changing the <http-listener> in the standalone.xml to: > > <https-listener name="httpspub" socket-binding="httpspub" > max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/> > <https-listener name="httpspriv" socket-binding="httpspriv" > max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/> > > and now when I try to import the CRL, I get: > > 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023: > Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp: > java.lang.IllegalArgumentException: byte limit exceeded: -58 > at > org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339) > at > org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305) > at > org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145) > > > On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote: > > > Hi, > > I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when > I try that it is throwing an exception and outputting the following > stacktrace: > > 14:17:41,407 ERROR [stderr] (default task-1) > io.undertow.server.RequestTooBigException: UT000020: Connection > terminated as request was larger than 10485760 > 14:17:41,408 ERROR [stderr] (default task-1) at > io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168) > 14:17:41,408 ERROR > > How can I import this CRL into EJBCA? > > Thanks, > Jim > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: <oh...@ya...> - 2019-06-28 12:24:13
|
Does anyone have any solution to this problem?
Thanks,
Jim
On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
Hi,
I tried changing the <http-listener> in the standalone.xml to:
<https-listener name="httpspub" socket-binding="httpspub" max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
<https-listener name="httpspriv" socket-binding="httpspriv" max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
and now when I try to import the CRL, I get:
14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp: java.lang.IllegalArgumentException: byte limit exceeded: -58
at org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
at org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
at org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
Hi,
I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when I try that it is throwing an exception and outputting the following stacktrace:
14:17:41,407 ERROR [stderr] (default task-1) io.undertow.server.RequestTooBigException: UT000020: Connection terminated as request was larger than 10485760
14:17:41,408 ERROR [stderr] (default task-1) at io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
14:17:41,408 ERROR
How can I import this CRL into EJBCA?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-27 19:12:45
|
Hi,
I tried changing the <http-listener> in the standalone.xml to:
<https-listener name="httpspub" socket-binding="httpspub" max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
<https-listener name="httpspriv" socket-binding="httpspriv" max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
and now when I try to import the CRL, I get:
14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp: java.lang.IllegalArgumentException: byte limit exceeded: -58
at org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
at org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
at org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
Hi,
I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when I try that it is throwing an exception and outputting the following stacktrace:
14:17:41,407 ERROR [stderr] (default task-1) io.undertow.server.RequestTooBigException: UT000020: Connection terminated as request was larger than 10485760
14:17:41,408 ERROR [stderr] (default task-1) at io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
14:17:41,408 ERROR
How can I import this CRL into EJBCA?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-27 18:25:31
|
Hi, I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when I try that it is throwing an exception and outputting the following stacktrace: 14:17:41,407 ERROR [stderr] (default task-1) io.undertow.server.RequestTooBigException: UT000020: Connection terminated as request was larger than 10485760 14:17:41,408 ERROR [stderr] (default task-1) at io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168) 14:17:41,408 ERROR How can I import this CRL into EJBCA? Thanks, Jim |
|
From: <oh...@ya...> - 2019-06-27 13:45:03
|
Hi,
Can EJBCA handle an "ldap:" CRL URL for the external CRL URL?
Thanks,
Jim
On Thursday, June 27, 2019, 9:27:15 AM EDT, <oh...@ya...> wrote:
Hi,
I just noticed that and tried it and waiting for it to see if it tries the download.
Thanks,
Jim
On Thursday, June 27, 2019, 9:05:14 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
In "Edit CA" you have a field to fill in, "External CRL Distribution Point"
Regards,
Tomas
On 2019-06-27 14:23, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just found some messages that say "No external CDP configured for CA
> 'XXXXXXXXXXXXXX'. Ignoring CA".
>
> I also checked the CA cert that was imported into EJBCA and, in the
> Adminweb, it has AIA populated with:
>
> CA issuer URI:
> http://xxxx/yyyyy.p7c
> ldap://xxxxxx/zzzzz?crossCertificatePair;binary
>
> BUT the Adminweb does not show CDP.
>
> However, when I look at the actual CA cert that I imported, that has
> both AIA and CDP populated.
>
> Is it possible that EJBCA "doesn't like" the CDP that is in the CA cert
> that I imported, and that is why EJBCA is skipping/ignoring the CA when
> it is trying to do the CRL Downloader service?
>
> Thanks,
> Jim
>
> On Thursday, June 27, 2019, 7:12:29 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> BTW, I've had one CA/CRL that I imported into EJBCA last night and I had
> the CRL Downloader service enabled and active for that since last night
> and, at least from the server.log, I don't see any attempts to download
> the CRL from the CA endpoint.
>
> Is there something else that I need to do to activate the service?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 6:10:41 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> Ahh. I think that the CRL Downloader service will only download the CRL
> for a CA if the CA certificate has the CDP correctly populated with the
> URL to download the CRL?
>
> Is that correct?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I will look at ejbca.sh, but re. the CRL Downloader service, how does
> that actually work? I mean when you use that for a CRL, how does it know
> where to download the CRLs from? The configuration only includes
> choosing which CA. Does the CRL Downloader somehow automatically figure
> out the URL for the CRL download by just know which CA?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
> Hi,
>
> You can find basic documentation for services, including the CRL
> downloader service here:
> https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
>
> The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
> help functions for documentation on that.
>
> Best regards,
> Tomas
>
> On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
>> Hi,
>>
>> I just ran across the EJBCA eval guide
> (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf)
> and saw that it mentions the CRL Downloader service. How does that
> service work? Do you provide it with a URL and then it will
> automatically periodically download the CRL for a CA?
>>
>> Also, it was mentioned previously that there was a way (an API or a
> script) to import a CRL into EJBCA? Can you provide
> information/reference about that?
>>
>> 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-27 13:27:12
|
Hi,
I just noticed that and tried it and waiting for it to see if it tries the download.
Thanks,
Jim
On Thursday, June 27, 2019, 9:05:14 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
In "Edit CA" you have a field to fill in, "External CRL Distribution Point"
Regards,
Tomas
On 2019-06-27 14:23, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just found some messages that say "No external CDP configured for CA
> 'XXXXXXXXXXXXXX'. Ignoring CA".
>
> I also checked the CA cert that was imported into EJBCA and, in the
> Adminweb, it has AIA populated with:
>
> CA issuer URI:
> http://xxxx/yyyyy.p7c
> ldap://xxxxxx/zzzzz?crossCertificatePair;binary
>
> BUT the Adminweb does not show CDP.
>
> However, when I look at the actual CA cert that I imported, that has
> both AIA and CDP populated.
>
> Is it possible that EJBCA "doesn't like" the CDP that is in the CA cert
> that I imported, and that is why EJBCA is skipping/ignoring the CA when
> it is trying to do the CRL Downloader service?
>
> Thanks,
> Jim
>
> On Thursday, June 27, 2019, 7:12:29 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> BTW, I've had one CA/CRL that I imported into EJBCA last night and I had
> the CRL Downloader service enabled and active for that since last night
> and, at least from the server.log, I don't see any attempts to download
> the CRL from the CA endpoint.
>
> Is there something else that I need to do to activate the service?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 6:10:41 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> Ahh. I think that the CRL Downloader service will only download the CRL
> for a CA if the CA certificate has the CDP correctly populated with the
> URL to download the CRL?
>
> Is that correct?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I will look at ejbca.sh, but re. the CRL Downloader service, how does
> that actually work? I mean when you use that for a CRL, how does it know
> where to download the CRLs from? The configuration only includes
> choosing which CA. Does the CRL Downloader somehow automatically figure
> out the URL for the CRL download by just know which CA?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
> Hi,
>
> You can find basic documentation for services, including the CRL
> downloader service here:
> https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
>
> The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
> help functions for documentation on that.
>
> Best regards,
> Tomas
>
> On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
>> Hi,
>>
>> I just ran across the EJBCA eval guide
> (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf)
> and saw that it mentions the CRL Downloader service. How does that
> service work? Do you provide it with a URL and then it will
> automatically periodically download the CRL for a CA?
>>
>> Also, it was mentioned previously that there was a way (an API or a
> script) to import a CRL into EJBCA? Can you provide
> information/reference about that?
>>
>> 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-27 13:04:41
|
In "Edit CA" you have a field to fill in, "External CRL Distribution Point" Regards, Tomas On 2019-06-27 14:23, ohaya--- via Ejbca-develop wrote: > Hi, > > I just found some messages that say "No external CDP configured for CA > 'XXXXXXXXXXXXXX'. Ignoring CA". > > I also checked the CA cert that was imported into EJBCA and, in the > Adminweb, it has AIA populated with: > > CA issuer URI: > http://xxxx/yyyyy.p7c > ldap://xxxxxx/zzzzz?crossCertificatePair;binary > > BUT the Adminweb does not show CDP. > > However, when I look at the actual CA cert that I imported, that has > both AIA and CDP populated. > > Is it possible that EJBCA "doesn't like" the CDP that is in the CA cert > that I imported, and that is why EJBCA is skipping/ignoring the CA when > it is trying to do the CRL Downloader service? > > Thanks, > Jim > > On Thursday, June 27, 2019, 7:12:29 AM EDT, <oh...@ya...> wrote: > > > Hi, > > BTW, I've had one CA/CRL that I imported into EJBCA last night and I had > the CRL Downloader service enabled and active for that since last night > and, at least from the server.log, I don't see any attempts to download > the CRL from the CA endpoint. > > Is there something else that I need to do to activate the service? > > Thanks, > Jim > > > On Thursday, June 27, 2019, 6:10:41 AM EDT, <oh...@ya...> wrote: > > > Hi, > > Ahh. I think that the CRL Downloader service will only download the CRL > for a CA if the CA certificate has the CDP correctly populated with the > URL to download the CRL? > > Is that correct? > > Thanks, > Jim > > > On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote: > > > Hi, > > I will look at ejbca.sh, but re. the CRL Downloader service, how does > that actually work? I mean when you use that for a CRL, how does it know > where to download the CRLs from? The configuration only includes > choosing which CA. Does the CRL Downloader somehow automatically figure > out the URL for the CRL download by just know which CA? > > Thanks, > Jim > > > On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson > <to...@pr...> wrote: > > > Hi, > > You can find basic documentation for services, including the CRL > downloader service here: > https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html > > The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line > help functions for documentation on that. > > Best regards, > Tomas > > On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote: >> Hi, >> >> I just ran across the EJBCA eval guide > (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) > and saw that it mentions the CRL Downloader service. How does that > service work? Do you provide it with a URL and then it will > automatically periodically download the CRL for a CA? >> >> Also, it was mentioned previously that there was a way (an API or a > script) to import a CRL into EJBCA? Can you provide > information/reference about that? >> >> 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-27 12:23:34
|
Hi,
I just found some messages that say "No external CDP configured for CA 'XXXXXXXXXXXXXX'. Ignoring CA".
I also checked the CA cert that was imported into EJBCA and, in the Adminweb, it has AIA populated with:
CA issuer URI:
http://xxxx/yyyyy.p7c
ldap://xxxxxx/zzzzz?crossCertificatePair;binary
BUT the Adminweb does not show CDP.
However, when I look at the actual CA cert that I imported, that has both AIA and CDP populated.
Is it possible that EJBCA "doesn't like" the CDP that is in the CA cert that I imported, and that is why EJBCA is skipping/ignoring the CA when it is trying to do the CRL Downloader service?
Thanks,
Jim
On Thursday, June 27, 2019, 7:12:29 AM EDT, <oh...@ya...> wrote:
Hi,
BTW, I've had one CA/CRL that I imported into EJBCA last night and I had the CRL Downloader service enabled and active for that since last night and, at least from the server.log, I don't see any attempts to download the CRL from the CA endpoint.
Is there something else that I need to do to activate the service?
Thanks,
Jim
On Thursday, June 27, 2019, 6:10:41 AM EDT, <oh...@ya...> wrote:
Hi,
Ahh. I think that the CRL Downloader service will only download the CRL for a CA if the CA certificate has the CDP correctly populated with the URL to download the CRL?
Is that correct?
Thanks,
Jim
On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote:
Hi,
I will look at ejbca.sh, but re. the CRL Downloader service, how does that actually work? I mean when you use that for a CRL, how does it know where to download the CRLs from? The configuration only includes choosing which CA. Does the CRL Downloader somehow automatically figure out the URL for the CRL download by just know which CA?
Thanks,
Jim
On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Hi,
You can find basic documentation for services, including the CRL
downloader service here:
https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
help functions for documentation on that.
Best regards,
Tomas
On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA?
>
> Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that?
>
> 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: <oh...@ya...> - 2019-06-27 11:12:26
|
Hi,
BTW, I've had one CA/CRL that I imported into EJBCA last night and I had the CRL Downloader service enabled and active for that since last night and, at least from the server.log, I don't see any attempts to download the CRL from the CA endpoint.
Is there something else that I need to do to activate the service?
Thanks,
Jim
On Thursday, June 27, 2019, 6:10:41 AM EDT, <oh...@ya...> wrote:
Hi,
Ahh. I think that the CRL Downloader service will only download the CRL for a CA if the CA certificate has the CDP correctly populated with the URL to download the CRL?
Is that correct?
Thanks,
Jim
On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote:
Hi,
I will look at ejbca.sh, but re. the CRL Downloader service, how does that actually work? I mean when you use that for a CRL, how does it know where to download the CRLs from? The configuration only includes choosing which CA. Does the CRL Downloader somehow automatically figure out the URL for the CRL download by just know which CA?
Thanks,
Jim
On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Hi,
You can find basic documentation for services, including the CRL
downloader service here:
https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
help functions for documentation on that.
Best regards,
Tomas
On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA?
>
> Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that?
>
> 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: <oh...@ya...> - 2019-06-27 10:10:41
|
Hi,
Ahh. I think that the CRL Downloader service will only download the CRL for a CA if the CA certificate has the CDP correctly populated with the URL to download the CRL?
Is that correct?
Thanks,
Jim
On Thursday, June 27, 2019, 6:03:37 AM EDT, <oh...@ya...> wrote:
Hi,
I will look at ejbca.sh, but re. the CRL Downloader service, how does that actually work? I mean when you use that for a CRL, how does it know where to download the CRLs from? The configuration only includes choosing which CA. Does the CRL Downloader somehow automatically figure out the URL for the CRL download by just know which CA?
Thanks,
Jim
On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Hi,
You can find basic documentation for services, including the CRL
downloader service here:
https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
help functions for documentation on that.
Best regards,
Tomas
On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA?
>
> Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that?
>
> 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: <oh...@ya...> - 2019-06-27 10:03:31
|
Hi,
I will look at ejbca.sh, but re. the CRL Downloader service, how does that actually work? I mean when you use that for a CRL, how does it know where to download the CRLs from? The configuration only includes choosing which CA. Does the CRL Downloader somehow automatically figure out the URL for the CRL download by just know which CA?
Thanks,
Jim
On Thursday, June 27, 2019, 4:02:33 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
Hi,
You can find basic documentation for services, including the CRL
downloader service here:
https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html
The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line
help functions for documentation on that.
Best regards,
Tomas
On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote:
> Hi,
>
> I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA?
>
> Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that?
>
> 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-27 08:01:54
|
Hi, You can find basic documentation for services, including the CRL downloader service here: https://download.primekey.se/docs/EJBCA-Enterprise/latest/Services.html The CLI have importcrl possibilities. Check the "bin/ejbca.sh" on-line help functions for documentation on that. Best regards, Tomas On 2019-06-27 03:06, ohaya--- via Ejbca-develop wrote: > Hi, > > I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA? > > Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that? > > Thanks, > Jim > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: <oh...@ya...> - 2019-06-27 01:08:53
|
Hi,
FYI, I just was able to test what I suggested, i.e., just using a simple <VirtualHost> with the proxypass/proxypassreverse and it does seem to work!
Jim
On Wednesday, June 26, 2019, 6:33:37 PM EDT, <oh...@ya...> wrote:
Hi,
I want to setup an Apache 2.2 instance as proxy for EJBCA OCSP Responder so that I can expose the responder endpoint path as "/". As suggested in an earlier thread, I was reviewing:
https://www.ejbca.org/docs/Setting_up_an_Apache_Web_Server_as_a_Proxy.html
I have built an Apache 2.2.34 from source and it is working all right.
Looking at the above page, I was wondering: If all I want to is to change the endpoint path so that it is "/", can I just implement the "URL Configuration" section at the end of that page, i.e. add a VirtualHost like:
<VirtualHost ocsp.company.com:80>
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://127.0.0.1:8080/ejbca/publicweb/status/ocsp
ProxyPassReverse / http://127.0.0.1:8080/ejbca/publicweb/status/ocsp
</VirtualHost>
Please advise.
Thanks,
Jim
P.S. BTW, the reason I am wanting to do the above, and skip the other parts, is that I tried the "bin/ejbca.sh ra" command that was described and that doesn't seem to be working anyway.
|
|
From: <oh...@ya...> - 2019-06-27 01:06:53
|
Hi, I just ran across the EJBCA eval guide (https://download.primekey.com/docs/EJBCA-Enterprise-Cloud/1_11/ejbca-evaluation-guide.pdf) and saw that it mentions the CRL Downloader service. How does that service work? Do you provide it with a URL and then it will automatically periodically download the CRL for a CA? Also, it was mentioned previously that there was a way (an API or a script) to import a CRL into EJBCA? Can you provide information/reference about that? Thanks, Jim |
|
From: <oh...@ya...> - 2019-06-26 22:33:38
|
Hi, I want to setup an Apache 2.2 instance as proxy for EJBCA OCSP Responder so that I can expose the responder endpoint path as "/". As suggested in an earlier thread, I was reviewing: https://www.ejbca.org/docs/Setting_up_an_Apache_Web_Server_as_a_Proxy.html I have built an Apache 2.2.34 from source and it is working all right. Looking at the above page, I was wondering: If all I want to is to change the endpoint path so that it is "/", can I just implement the "URL Configuration" section at the end of that page, i.e. add a VirtualHost like: <VirtualHost ocsp.company.com:80> <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://127.0.0.1:8080/ejbca/publicweb/status/ocsp ProxyPassReverse / http://127.0.0.1:8080/ejbca/publicweb/status/ocsp </VirtualHost> Please advise. Thanks, Jim P.S. BTW, the reason I am wanting to do the above, and skip the other parts, is that I tried the "bin/ejbca.sh ra" command that was described and that doesn't seem to be working anyway. |
|
From: <oh...@ya...> - 2019-06-26 16:58:10
|
Hi Jaime (et al),
Ok, I figured it out. I was mistaken about the command line that we've been using with our normal OCSPD, and found that we are using the "openssl ocsp" with only "-issuer" and "-VAfile".
So I think we are ok now.
Thanks,
Jim
On Wednesday, June 26, 2019, 11:41:54 AM EDT, Jaime Hablutzel <hab...@gm...> wrote:
On Wed, Jun 26, 2019 at 10:28 AM ohaya--- via Ejbca-develop <ejb...@li...> wrote:
Hi,
Ok, I found that adding "-VAfile" and pointing that to the SIGNING CERTIFICATE, seems to make the error go away. I am not 100% why that needs to be added when sending an OCSP request for a cert issued by one CA (the SimpleAuthorityCA), but the "-VAfile" is not needed for OCSP request for a cert in the simpleca CA??
It is because the expected signer for OCSP responses depends on the certificate you are requesting status for. Quoting from RFC 6960, "2.2. Response":
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requestor
- a CA Designated Responder (Authorized Responder, defined in
Section 4.2.2.2) who holds a specially marked certificate issued
directly by the CA, indicating that the responder may issue OCSP
responses for that CA
So, when you request status for a certificate issued by "SimpleAuthorityCA" you are against a response that is not signed by the "the CA who issued the certificate in question" nor a "a CA Designated Responder who holds a specially marked certificate issueddirectly by the CA" so you are left only with the "Trusted Responder whose public key is trusted by the requestor" and there is where the openssl ocsp "-VAfile" option applies. From "man ocsp":
-VAfile file
File containing explicitly trusted responder certificates.
|
|
From: Jaime H. <hab...@gm...> - 2019-06-26 15:41:48
|
On Wed, Jun 26, 2019 at 10:28 AM ohaya--- via Ejbca-develop < ejb...@li...> wrote: > Hi, > > Ok, I found that adding "-VAfile" and pointing that to the SIGNING > CERTIFICATE, seems to make the error go away. I am not 100% why that needs > to be added when sending an OCSP request for a cert issued by one CA (the > SimpleAuthorityCA), but the "-VAfile" is not needed for OCSP request for a > cert in the simpleca CA?? > > It is because the expected signer for OCSP responses depends on the certificate you are requesting status for. Quoting from RFC 6960, "2.2. Response": All definitive response messages SHALL be digitally signed. The key > used to sign the response MUST belong to one of the following: > - the CA who issued the certificate in question > - a Trusted Responder whose public key is trusted by the requestor > - a CA Designated Responder (Authorized Responder, defined in > Section 4.2.2.2) who holds a specially marked certificate issued > directly by the CA, indicating that the responder may issue OCSP > responses for that CA So, when you request status for a certificate issued by "SimpleAuthorityCA" you are against a response that is not signed by the "the CA who issued the certificate in question" nor a "a CA Designated Responder who holds a specially marked certificate issued directly by the CA" so you are left only with the "Trusted Responder whose public key is trusted by the requestor" and there is where the openssl ocsp "-VAfile" option applies. From "man ocsp": -VAfile file > File containing explicitly trusted responder certificates. |
|
From: <oh...@ya...> - 2019-06-26 15:27:41
|
Hi,
Ok, I found that adding "-VAfile" and pointing that to the SIGNING CERTIFICATE, seems to make the error go away. I am not 100% why that needs to be added when sending an OCSP request for a cert issued by one CA (the SimpleAuthorityCA), but the "-VAfile" is not needed for OCSP request for a cert in the simpleca CA??
[root@ejbca SimpleAuthority-newdomain]# openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -VAfile simplecabinding2.crt -serial 0x016b902b1b87 -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: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410D2ABB7F5767F7245CE95111D209DE1BA
Response verify OK
0x016b902b1b87: revoked
This Update: Jun 26 15:27:15 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
On Wednesday, June 26, 2019, 11:15:10 AM EDT, <oh...@ya...> wrote:
Hi,
I don't know if this helps pinpoint the problem, but FYI, if I included the "-no_cert_verify" in the command line, then that error didn't appear:
[root@ejbca SimpleAuthority-newdomain]# openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -no_cert_verify -serial 0x016b902b1b87 -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: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410AF8386B8F3AFA34F33F95FD0B735F88B
Response verify OK
0x016b902b1b87: revoked
This Update: Jun 26 15:12:23 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
On Wednesday, June 26, 2019, 10:46:11 AM EDT, <oh...@ya...> wrote:
Hi,
Per discussion in earlier thread, I have a single OCSP binding, and have CRLs from several external CAs imported into EJBCA OCSP Responder.
I test using "openssl ocsp" command, e.g.:
openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
So I have two CAs/CRLs in the OCSP Responder, call them "simpleca" and "SimpleAuthorityCA"
The signing key in the OCSP binding is a cert issued by the "simpleca" CA.
So if I test sending an OCSP request to the EJBCA OCSP Responder, using the root CA cert from the "simpleca" CA, it works fine.
openssl ocsp -CAfile ./simpleca-rootCA.crt -issuer ./simpleca-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
If I test using the CA cert for the "SimpleAuthorityCA":
openssl ocsp -CAfile ./SimpleAuthorityCA-rootCA.crt -issuer ./SimpleAuthorityCA-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
I do get a CORRECT response, but that response also includes an error message "Verify error:unable to get local issuer certificate". For example:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410B030A87AB1C53A4906FED9F70F9D090F
Response Verify Failure
140511704516496:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
0x016b902b1b87: revoked
This Update: Jun 26 14:30:55 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
I have tried all combinations of combining the simpleca-rootCA.crt and the SimpleAuthorityCA-rootCA.crt for the -issuer and -CAfile, but I still keep getting that error.
I am actually not sure if that error is coming from the server side? Or is it coming from the client/openssl side?
And, either way, how can I fix it so I don't get the error?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-26 15:15:13
|
Hi,
I don't know if this helps pinpoint the problem, but FYI, if I included the "-no_cert_verify" in the command line, then that error didn't appear:
[root@ejbca SimpleAuthority-newdomain]# openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -no_cert_verify -serial 0x016b902b1b87 -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: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410AF8386B8F3AFA34F33F95FD0B735F88B
Response verify OK
0x016b902b1b87: revoked
This Update: Jun 26 15:12:23 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
On Wednesday, June 26, 2019, 10:46:11 AM EDT, <oh...@ya...> wrote:
Hi,
Per discussion in earlier thread, I have a single OCSP binding, and have CRLs from several external CAs imported into EJBCA OCSP Responder.
I test using "openssl ocsp" command, e.g.:
openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
So I have two CAs/CRLs in the OCSP Responder, call them "simpleca" and "SimpleAuthorityCA"
The signing key in the OCSP binding is a cert issued by the "simpleca" CA.
So if I test sending an OCSP request to the EJBCA OCSP Responder, using the root CA cert from the "simpleca" CA, it works fine.
openssl ocsp -CAfile ./simpleca-rootCA.crt -issuer ./simpleca-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
If I test using the CA cert for the "SimpleAuthorityCA":
openssl ocsp -CAfile ./SimpleAuthorityCA-rootCA.crt -issuer ./SimpleAuthorityCA-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
I do get a CORRECT response, but that response also includes an error message "Verify error:unable to get local issuer certificate". For example:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410B030A87AB1C53A4906FED9F70F9D090F
Response Verify Failure
140511704516496:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
0x016b902b1b87: revoked
This Update: Jun 26 14:30:55 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
I have tried all combinations of combining the simpleca-rootCA.crt and the SimpleAuthorityCA-rootCA.crt for the -issuer and -CAfile, but I still keep getting that error.
I am actually not sure if that error is coming from the server side? Or is it coming from the client/openssl side?
And, either way, how can I fix it so I don't get the error?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-26 14:46:06
|
Hi,
Per discussion in earlier thread, I have a single OCSP binding, and have CRLs from several external CAs imported into EJBCA OCSP Responder.
I test using "openssl ocsp" command, e.g.:
openssl ocsp -CAfile ./rootCA.crt -issuer ./rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
So I have two CAs/CRLs in the OCSP Responder, call them "simpleca" and "SimpleAuthorityCA"
The signing key in the OCSP binding is a cert issued by the "simpleca" CA.
So if I test sending an OCSP request to the EJBCA OCSP Responder, using the root CA cert from the "simpleca" CA, it works fine.
openssl ocsp -CAfile ./simpleca-rootCA.crt -issuer ./simpleca-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
If I test using the CA cert for the "SimpleAuthorityCA":
openssl ocsp -CAfile ./SimpleAuthorityCA-rootCA.crt -issuer ./SimpleAuthorityCA-rootCA.crt -serial 0x016b902b1b87 -req_text -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
I do get a CORRECT response, but that response also includes an error message "Verify error:unable to get local issuer certificate". For example:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12238A5A4DCC9C6515D94132E4800DEBA1CE7004
Issuer Key Hash: D9839F806222BC7BC0BC888DAC7C299E38D7BE8C
Serial Number: 016B902B1B87
Request Extensions:
OCSP Nonce:
0410B030A87AB1C53A4906FED9F70F9D090F
Response Verify Failure
140511704516496:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
0x016b902b1b87: revoked
This Update: Jun 26 14:30:55 2019 GMT
Reason: keyCompromise
Revocation Time: Jun 25 19:55:51 2019 GMT
I have tried all combinations of combining the simpleca-rootCA.crt and the SimpleAuthorityCA-rootCA.crt for the -issuer and -CAfile, but I still keep getting that error.
I am actually not sure if that error is coming from the server side? Or is it coming from the client/openssl side?
And, either way, how can I fix it so I don't get the error?
Thanks,
Jim
|
|
From: <oh...@ya...> - 2019-06-26 13:40:54
|
Hi,
AHHAAA!!
It turns out that there is a newer version of SimpleAuthorit, and that includes an option for including NextUpdate, so I enabled that, and generated a new CRL and then tried to import it into EJBCA and it worked without error, and also Adminweb is now showing the CRL was imported.
COOL :)!!
Now I have to test some OCSP requests.
Thanks!
Jim
On Wednesday, June 26, 2019, 9:29:34 AM EDT, ohaya--- via Ejbca-develop <ejb...@li...> wrote:
Hi,
Ok, thanks. I will see if that is something I can try/fix, as that particular CRL was generated by an app that I sometimes use for testing, SimpleAuthority.
I will post back after I do more testing.
Jim
On Wednesday, June 26, 2019, 9:19:40 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
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
>
_______________________________________________
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 13:29:22
|
Hi,
Ok, thanks. I will see if that is something I can try/fix, as that particular CRL was generated by an app that I sometimes use for testing, SimpleAuthority.
I will post back after I do more testing.
Jim
On Wednesday, June 26, 2019, 9:19:40 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
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
>
_______________________________________________
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.
