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: Jaime H. <hab...@gm...> - 2018-10-25 17:31:14
|
Just a quick idea right now, but, what do you think of protecting EJBCA records with blockchain transactions?. This way, records in EJBCA would be verifiable with a distributed ledger and this could help to prove the authenticity of certain data even to third parties (e.g. government), for example, the exact time when a certificate got revoked in the past. I think that this could be implemented just as a new protection version for Database Integrity Protection ( https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecurityv6.15.0-DatabaseIntegrityProtection ). What do you think?. -- Jaime Hablutzel - RPC 994690880 |
|
From: Николай Д. <dol...@gm...> - 2018-10-23 00:24:32
|
Hello to all. Can anyone share a working docker image (Dockerfile) as a temporary solution until PrimeKey publishes the official image? Thanks. -- Nikolay |
|
From: John R <joh...@gm...> - 2018-10-15 18:32:50
|
We have 2 publishers. One of them is an LDAP publisher which I'm assuming is unrelated. The other is an OCSP publisher. I can see that on EJBCA 6.2 it's publisher type is "Validation Authority Publisher". After the upgrade to 6.10 it has transformed to LegacyValidationAuthorityPublisher. I'm attaching a sceenshot of its configuration. On Mon, Oct 15, 2018 at 6:08 PM Tomas Gustavsson <to...@pr...> wrote: > > What does your publisher configuration look like? Can you give a > screenshot? > > /Tomas > > On 2018-10-15 17:06, Tomas Gustavsson wrote: > > > > Hm, yeah I think I can see why this doesn't work. Strange, as people are > > using this publisher still. > > > > Well have to look later... > > > > /Tomas > > > > On 2018-10-15 17:04, John R wrote: > >> We must have missed each other with the last messages. Like I mentioned > >> there I already tried that but then I end up with an endless recursion > >> due to the storeCertificate method in CustomPublisherContainer. > >> On Mon, Oct 15, 2018 at 6:02 PM Tomas Gustavsson <to...@pr... > >> <mailto:to...@pr...>> wrote: > >> > >> > >> > Did you try hardcoding willPublishCertificate returning true in > >> > LegacyValidationAuthorityPublisher? > >> > >> You can do the same with isFullEntityPublishingSupported, returning > >> false. > >> > >> Cheers, > >> Tomas > >> > >> On 2018-10-15 16:35, Tomas Gustavsson wrote: > >> > > >> > It seems to be: > >> > > >> this.custompublisher.init(getProperties()); > >> > >> > in CustomPublisherContainer.getCustomPublisher() > >> > > >> > getProperties calls getCustomPublisher...causing a recursion I > guess. > >> > > >> > Did you try hardcoding willPublishCertificate returning true in > >> > LegacyValidationAuthorityPublisher? > >> > > >> > /Tomas > >> > > >> > > >> > On 2018-10-15 15:06, John R wrote: > >> >> I made a small mistake. The second error in the log doesn't > >> happen when > >> >> the value of willPublishCertificate is hardcoded to false. When > it's > >> >> hardcoded to false the enrollment passes. When it's hardcoded to > >> true > >> >> the error occurs. > >> >> > >> >> On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... > >> <mailto:joh...@gm...> > >> >> <mailto:joh...@gm... <mailto:joh...@gm...>>> > wrote: > >> >> > >> >> Hi Thomas, thanks for the quick response. > >> >> > >> >> I'm attaching a file with 3 exceptions in it. They all > basically > >> >> come down to the same thing - the use of getCustomPublisher > >> >> in CustomPublisherContainer . The version of ejbca as seen > in the > >> >> log is 6.10.1.2 r27920. > >> >> Also I'm not sure if this is any help but while doing really > >> light > >> >> debugging I saw that the ICustomPublisher that > getCustomPublisher > >> >> returns in our case is LegacyValidationAuthorityPublisher > which I > >> >> think is the reason for the recursion in the first place > since it > >> >> doesn't have it's own implementation of those methods. > >> >> > >> >> On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson > >> <to...@pr... <mailto:to...@pr...> > >> >> <mailto:to...@pr... <mailto:to...@pr...>>> > wrote: > >> >> > >> >> > >> >> This is nothing we have heard before. Can you post the > stack > >> >> trace you > >> >> get in server.log. As well as state the exact version you > >> use. > >> >> > >> >> Regards, > >> >> Tomas > >> >> > >> >> On 2018-10-15 12:48, John R wrote: > >> >> > Hello, > >> >> > > >> >> > We tried upgrading from 6.2.0 to 6.10.0 following the > >> guide on > >> >> the site. > >> >> > Everything seemed to work but now we can't enroll the > >> >> certificate. I did > >> >> > some light digging and the problem seems to be the > method > >> >> > willPublishCertificate in CustomPublisherContainer > which is > >> >> inherited > >> >> > by LegacyValidationAuthorityPublisher which is the > actual > >> >> class returned > >> >> > by getCustomPublisher. It basically always creates a > new > >> >> instance of > >> >> > itself and then calls the willPublishCertificate > method on > >> >> itself and so > >> >> > on forever. > >> >> > > >> >> > I hardcoded it false and the enrollment started > >> working. Then > >> >> I checked > >> >> > how it was in the original 6.2.0 source and saw that > the > >> >> BasePublisher > >> >> > class had the method back then and it was hardcoded to > >> true. > >> >> So I tried > >> >> > that on out 6.10.0 source and then got a > >> >> StackoverflowException from the > >> >> > method isFullEntityPublishingSupported again > >> >> > in CustomPublisherContainer. There it again ask for > >> >> getCustomPublisher, > >> >> > gets a new instance of itself and calls the method on > >> the new > >> >> instance > >> >> > again resulting in an endless recursion. > >> >> > > >> >> > The whole process of ending with these issues is -> > >> create new end > >> >> > entity using our previously existing CAs --> go to > >> public web > >> >> and try to > >> >> > enroll. > >> >> > > >> >> > What are we doing wrong? > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Ejbca-develop mailing list > >> >> > Ejb...@li... > >> <mailto:Ejb...@li...> > >> >> <mailto:Ejb...@li... > >> <mailto:Ejb...@li...>> > >> >> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> >> > > >> >> > >> >> > >> >> _______________________________________________ > >> >> Ejbca-develop mailing list > >> >> Ejb...@li... > >> <mailto:Ejb...@li...> > >> >> <mailto:Ejb...@li... > >> <mailto:Ejb...@li...>> > >> >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Ejbca-develop mailing list > >> >> Ejb...@li... > >> <mailto:Ejb...@li...> > >> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> >> > >> > >> > >> _______________________________________________ > >> Ejbca-develop mailing list > >> Ejb...@li... > >> <mailto:Ejb...@li...> > >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Ejbca-develop mailing list > >> Ejb...@li... > >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2018-10-15 15:08:34
|
What does your publisher configuration look like? Can you give a screenshot? /Tomas On 2018-10-15 17:06, Tomas Gustavsson wrote: > > Hm, yeah I think I can see why this doesn't work. Strange, as people are > using this publisher still. > > Well have to look later... > > /Tomas > > On 2018-10-15 17:04, John R wrote: >> We must have missed each other with the last messages. Like I mentioned >> there I already tried that but then I end up with an endless recursion >> due to the storeCertificate method in CustomPublisherContainer. >> On Mon, Oct 15, 2018 at 6:02 PM Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...>> wrote: >> >> >> > Did you try hardcoding willPublishCertificate returning true in >> > LegacyValidationAuthorityPublisher? >> >> You can do the same with isFullEntityPublishingSupported, returning >> false. >> >> Cheers, >> Tomas >> >> On 2018-10-15 16:35, Tomas Gustavsson wrote: >> > >> > It seems to be: >> > >> this.custompublisher.init(getProperties()); >> >> > in CustomPublisherContainer.getCustomPublisher() >> > >> > getProperties calls getCustomPublisher...causing a recursion I guess. >> > >> > Did you try hardcoding willPublishCertificate returning true in >> > LegacyValidationAuthorityPublisher? >> > >> > /Tomas >> > >> > >> > On 2018-10-15 15:06, John R wrote: >> >> I made a small mistake. The second error in the log doesn't >> happen when >> >> the value of willPublishCertificate is hardcoded to false. When it's >> >> hardcoded to false the enrollment passes. When it's hardcoded to >> true >> >> the error occurs. >> >> >> >> On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... >> <mailto:joh...@gm...> >> >> <mailto:joh...@gm... <mailto:joh...@gm...>>> wrote: >> >> >> >> Hi Thomas, thanks for the quick response. >> >> >> >> I'm attaching a file with 3 exceptions in it. They all basically >> >> come down to the same thing - the use of getCustomPublisher >> >> in CustomPublisherContainer . The version of ejbca as seen in the >> >> log is 6.10.1.2 r27920. >> >> Also I'm not sure if this is any help but while doing really >> light >> >> debugging I saw that the ICustomPublisher that getCustomPublisher >> >> returns in our case is LegacyValidationAuthorityPublisher which I >> >> think is the reason for the recursion in the first place since it >> >> doesn't have it's own implementation of those methods. >> >> >> >> On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson >> <to...@pr... <mailto:to...@pr...> >> >> <mailto:to...@pr... <mailto:to...@pr...>>> wrote: >> >> >> >> >> >> This is nothing we have heard before. Can you post the stack >> >> trace you >> >> get in server.log. As well as state the exact version you >> use. >> >> >> >> Regards, >> >> Tomas >> >> >> >> On 2018-10-15 12:48, John R wrote: >> >> > Hello, >> >> > >> >> > We tried upgrading from 6.2.0 to 6.10.0 following the >> guide on >> >> the site. >> >> > Everything seemed to work but now we can't enroll the >> >> certificate. I did >> >> > some light digging and the problem seems to be the method >> >> > willPublishCertificate in CustomPublisherContainer which is >> >> inherited >> >> > by LegacyValidationAuthorityPublisher which is the actual >> >> class returned >> >> > by getCustomPublisher. It basically always creates a new >> >> instance of >> >> > itself and then calls the willPublishCertificate method on >> >> itself and so >> >> > on forever. >> >> > >> >> > I hardcoded it false and the enrollment started >> working. Then >> >> I checked >> >> > how it was in the original 6.2.0 source and saw that the >> >> BasePublisher >> >> > class had the method back then and it was hardcoded to >> true. >> >> So I tried >> >> > that on out 6.10.0 source and then got a >> >> StackoverflowException from the >> >> > method isFullEntityPublishingSupported again >> >> > in CustomPublisherContainer. There it again ask for >> >> getCustomPublisher, >> >> > gets a new instance of itself and calls the method on >> the new >> >> instance >> >> > again resulting in an endless recursion. >> >> > >> >> > The whole process of ending with these issues is -> >> create new end >> >> > entity using our previously existing CAs --> go to >> public web >> >> and try to >> >> > enroll. >> >> > >> >> > What are we doing wrong? >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Ejbca-develop mailing list >> >> > Ejb...@li... >> <mailto:Ejb...@li...> >> >> <mailto:Ejb...@li... >> <mailto:Ejb...@li...>> >> >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> > >> >> >> >> >> >> _______________________________________________ >> >> Ejbca-develop mailing list >> >> Ejb...@li... >> <mailto:Ejb...@li...> >> >> <mailto:Ejb...@li... >> <mailto:Ejb...@li...>> >> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Ejbca-develop mailing list >> >> Ejb...@li... >> <mailto:Ejb...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> <mailto:Ejb...@li...> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2018-10-15 15:06:48
|
Hm, yeah I think I can see why this doesn't work. Strange, as people are using this publisher still. Well have to look later... /Tomas On 2018-10-15 17:04, John R wrote: > We must have missed each other with the last messages. Like I mentioned > there I already tried that but then I end up with an endless recursion > due to the storeCertificate method in CustomPublisherContainer. > On Mon, Oct 15, 2018 at 6:02 PM Tomas Gustavsson <to...@pr... > <mailto:to...@pr...>> wrote: > > > > Did you try hardcoding willPublishCertificate returning true in > > LegacyValidationAuthorityPublisher? > > You can do the same with isFullEntityPublishingSupported, returning > false. > > Cheers, > Tomas > > On 2018-10-15 16:35, Tomas Gustavsson wrote: > > > > It seems to be: > > > this.custompublisher.init(getProperties()); > > > in CustomPublisherContainer.getCustomPublisher() > > > > getProperties calls getCustomPublisher...causing a recursion I guess. > > > > Did you try hardcoding willPublishCertificate returning true in > > LegacyValidationAuthorityPublisher? > > > > /Tomas > > > > > > On 2018-10-15 15:06, John R wrote: > >> I made a small mistake. The second error in the log doesn't > happen when > >> the value of willPublishCertificate is hardcoded to false. When it's > >> hardcoded to false the enrollment passes. When it's hardcoded to > true > >> the error occurs. > >> > >> On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... > <mailto:joh...@gm...> > >> <mailto:joh...@gm... <mailto:joh...@gm...>>> wrote: > >> > >> Hi Thomas, thanks for the quick response. > >> > >> I'm attaching a file with 3 exceptions in it. They all basically > >> come down to the same thing - the use of getCustomPublisher > >> in CustomPublisherContainer . The version of ejbca as seen in the > >> log is 6.10.1.2 r27920. > >> Also I'm not sure if this is any help but while doing really > light > >> debugging I saw that the ICustomPublisher that getCustomPublisher > >> returns in our case is LegacyValidationAuthorityPublisher which I > >> think is the reason for the recursion in the first place since it > >> doesn't have it's own implementation of those methods. > >> > >> On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson > <to...@pr... <mailto:to...@pr...> > >> <mailto:to...@pr... <mailto:to...@pr...>>> wrote: > >> > >> > >> This is nothing we have heard before. Can you post the stack > >> trace you > >> get in server.log. As well as state the exact version you > use. > >> > >> Regards, > >> Tomas > >> > >> On 2018-10-15 12:48, John R wrote: > >> > Hello, > >> > > >> > We tried upgrading from 6.2.0 to 6.10.0 following the > guide on > >> the site. > >> > Everything seemed to work but now we can't enroll the > >> certificate. I did > >> > some light digging and the problem seems to be the method > >> > willPublishCertificate in CustomPublisherContainer which is > >> inherited > >> > by LegacyValidationAuthorityPublisher which is the actual > >> class returned > >> > by getCustomPublisher. It basically always creates a new > >> instance of > >> > itself and then calls the willPublishCertificate method on > >> itself and so > >> > on forever. > >> > > >> > I hardcoded it false and the enrollment started > working. Then > >> I checked > >> > how it was in the original 6.2.0 source and saw that the > >> BasePublisher > >> > class had the method back then and it was hardcoded to > true. > >> So I tried > >> > that on out 6.10.0 source and then got a > >> StackoverflowException from the > >> > method isFullEntityPublishingSupported again > >> > in CustomPublisherContainer. There it again ask for > >> getCustomPublisher, > >> > gets a new instance of itself and calls the method on > the new > >> instance > >> > again resulting in an endless recursion. > >> > > >> > The whole process of ending with these issues is -> > create new end > >> > entity using our previously existing CAs --> go to > public web > >> and try to > >> > enroll. > >> > > >> > What are we doing wrong? > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Ejbca-develop mailing list > >> > Ejb...@li... > <mailto:Ejb...@li...> > >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> > >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > > >> > >> > >> _______________________________________________ > >> Ejbca-develop mailing list > >> Ejb...@li... > <mailto:Ejb...@li...> > >> <mailto:Ejb...@li... > <mailto:Ejb...@li...>> > >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Ejbca-develop mailing list > >> Ejb...@li... > <mailto:Ejb...@li...> > >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > <mailto:Ejb...@li...> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: John R <joh...@gm...> - 2018-10-15 15:05:09
|
We must have missed each other with the last messages. Like I mentioned there I already tried that but then I end up with an endless recursion due to the storeCertificate method in CustomPublisherContainer. On Mon, Oct 15, 2018 at 6:02 PM Tomas Gustavsson <to...@pr...> wrote: > > > Did you try hardcoding willPublishCertificate returning true in > > LegacyValidationAuthorityPublisher? > > You can do the same with isFullEntityPublishingSupported, returning false. > > Cheers, > Tomas > > On 2018-10-15 16:35, Tomas Gustavsson wrote: > > > > It seems to be: > > > this.custompublisher.init(getProperties()); > > in CustomPublisherContainer.getCustomPublisher() > > > > getProperties calls getCustomPublisher...causing a recursion I guess. > > > > Did you try hardcoding willPublishCertificate returning true in > > LegacyValidationAuthorityPublisher? > > > > /Tomas > > > > > > On 2018-10-15 15:06, John R wrote: > >> I made a small mistake. The second error in the log doesn't happen when > >> the value of willPublishCertificate is hardcoded to false. When it's > >> hardcoded to false the enrollment passes. When it's hardcoded to true > >> the error occurs. > >> > >> On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... > >> <mailto:joh...@gm...>> wrote: > >> > >> Hi Thomas, thanks for the quick response. > >> > >> I'm attaching a file with 3 exceptions in it. They all basically > >> come down to the same thing - the use of getCustomPublisher > >> in CustomPublisherContainer . The version of ejbca as seen in the > >> log is 6.10.1.2 r27920. > >> Also I'm not sure if this is any help but while doing really light > >> debugging I saw that the ICustomPublisher that getCustomPublisher > >> returns in our case is LegacyValidationAuthorityPublisher which I > >> think is the reason for the recursion in the first place since it > >> doesn't have it's own implementation of those methods. > >> > >> On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson <to...@pr... > >> <mailto:to...@pr...>> wrote: > >> > >> > >> This is nothing we have heard before. Can you post the stack > >> trace you > >> get in server.log. As well as state the exact version you use. > >> > >> Regards, > >> Tomas > >> > >> On 2018-10-15 12:48, John R wrote: > >> > Hello, > >> > > >> > We tried upgrading from 6.2.0 to 6.10.0 following the guide on > >> the site. > >> > Everything seemed to work but now we can't enroll the > >> certificate. I did > >> > some light digging and the problem seems to be the method > >> > willPublishCertificate in CustomPublisherContainer which is > >> inherited > >> > by LegacyValidationAuthorityPublisher which is the actual > >> class returned > >> > by getCustomPublisher. It basically always creates a new > >> instance of > >> > itself and then calls the willPublishCertificate method on > >> itself and so > >> > on forever. > >> > > >> > I hardcoded it false and the enrollment started working. Then > >> I checked > >> > how it was in the original 6.2.0 source and saw that the > >> BasePublisher > >> > class had the method back then and it was hardcoded to true. > >> So I tried > >> > that on out 6.10.0 source and then got a > >> StackoverflowException from the > >> > method isFullEntityPublishingSupported again > >> > in CustomPublisherContainer. There it again ask for > >> getCustomPublisher, > >> > gets a new instance of itself and calls the method on the new > >> instance > >> > again resulting in an endless recursion. > >> > > >> > The whole process of ending with these issues is -> create > new end > >> > entity using our previously existing CAs --> go to public web > >> and try to > >> > enroll. > >> > > >> > What are we doing wrong? > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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...> - 2018-10-15 15:02:24
|
> Did you try hardcoding willPublishCertificate returning true in > LegacyValidationAuthorityPublisher? You can do the same with isFullEntityPublishingSupported, returning false. Cheers, Tomas On 2018-10-15 16:35, Tomas Gustavsson wrote: > > It seems to be: > this.custompublisher.init(getProperties()); > in CustomPublisherContainer.getCustomPublisher() > > getProperties calls getCustomPublisher...causing a recursion I guess. > > Did you try hardcoding willPublishCertificate returning true in > LegacyValidationAuthorityPublisher? > > /Tomas > > > On 2018-10-15 15:06, John R wrote: >> I made a small mistake. The second error in the log doesn't happen when >> the value of willPublishCertificate is hardcoded to false. When it's >> hardcoded to false the enrollment passes. When it's hardcoded to true >> the error occurs. >> >> On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... >> <mailto:joh...@gm...>> wrote: >> >> Hi Thomas, thanks for the quick response. >> >> I'm attaching a file with 3 exceptions in it. They all basically >> come down to the same thing - the use of getCustomPublisher >> in CustomPublisherContainer . The version of ejbca as seen in the >> log is 6.10.1.2 r27920. >> Also I'm not sure if this is any help but while doing really light >> debugging I saw that the ICustomPublisher that getCustomPublisher >> returns in our case is LegacyValidationAuthorityPublisher which I >> think is the reason for the recursion in the first place since it >> doesn't have it's own implementation of those methods. >> >> On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...>> wrote: >> >> >> This is nothing we have heard before. Can you post the stack >> trace you >> get in server.log. As well as state the exact version you use. >> >> Regards, >> Tomas >> >> On 2018-10-15 12:48, John R wrote: >> > Hello, >> > >> > We tried upgrading from 6.2.0 to 6.10.0 following the guide on >> the site. >> > Everything seemed to work but now we can't enroll the >> certificate. I did >> > some light digging and the problem seems to be the method >> > willPublishCertificate in CustomPublisherContainer which is >> inherited >> > by LegacyValidationAuthorityPublisher which is the actual >> class returned >> > by getCustomPublisher. It basically always creates a new >> instance of >> > itself and then calls the willPublishCertificate method on >> itself and so >> > on forever. >> > >> > I hardcoded it false and the enrollment started working. Then >> I checked >> > how it was in the original 6.2.0 source and saw that the >> BasePublisher >> > class had the method back then and it was hardcoded to true. >> So I tried >> > that on out 6.10.0 source and then got a >> StackoverflowException from the >> > method isFullEntityPublishingSupported again >> > in CustomPublisherContainer. There it again ask for >> getCustomPublisher, >> > gets a new instance of itself and calls the method on the new >> instance >> > again resulting in an endless recursion. >> > >> > The whole process of ending with these issues is -> create new end >> > entity using our previously existing CAs --> go to public web >> and try to >> > enroll. >> > >> > What are we doing wrong? >> > >> > >> > >> > >> > _______________________________________________ >> > 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: John R <joh...@gm...> - 2018-10-15 15:01:25
|
> > I overrode willPublishCertificate to return true in > LegacyValidationAuthorityPublisher. After that I still ended up in an > endless recursion because the other method isFullEntityPublishingSupported > in CustomPublisherContainer. Then I overrode that method in > LegacyValidationAuthorityPublisher and made it return false. Then I ended > up with an endless recursion because of storeCertificate in > CustomPublisherContainer. Obviously I can just keep overriding these > methods in LegacyValidationAuthorityPublisher and giving them a static > value but I'm not really sure of the broader implications of doing that. > > |
|
From: Tomas G. <to...@pr...> - 2018-10-15 14:35:26
|
It seems to be: this.custompublisher.init(getProperties()); in CustomPublisherContainer.getCustomPublisher() getProperties calls getCustomPublisher...causing a recursion I guess. Did you try hardcoding willPublishCertificate returning true in LegacyValidationAuthorityPublisher? /Tomas On 2018-10-15 15:06, John R wrote: > I made a small mistake. The second error in the log doesn't happen when > the value of willPublishCertificate is hardcoded to false. When it's > hardcoded to false the enrollment passes. When it's hardcoded to true > the error occurs. > > On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm... > <mailto:joh...@gm...>> wrote: > > Hi Thomas, thanks for the quick response. > > I'm attaching a file with 3 exceptions in it. They all basically > come down to the same thing - the use of getCustomPublisher > in CustomPublisherContainer . The version of ejbca as seen in the > log is 6.10.1.2 r27920. > Also I'm not sure if this is any help but while doing really light > debugging I saw that the ICustomPublisher that getCustomPublisher > returns in our case is LegacyValidationAuthorityPublisher which I > think is the reason for the recursion in the first place since it > doesn't have it's own implementation of those methods. > > On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson <to...@pr... > <mailto:to...@pr...>> wrote: > > > This is nothing we have heard before. Can you post the stack > trace you > get in server.log. As well as state the exact version you use. > > Regards, > Tomas > > On 2018-10-15 12:48, John R wrote: > > Hello, > > > > We tried upgrading from 6.2.0 to 6.10.0 following the guide on > the site. > > Everything seemed to work but now we can't enroll the > certificate. I did > > some light digging and the problem seems to be the method > > willPublishCertificate in CustomPublisherContainer which is > inherited > > by LegacyValidationAuthorityPublisher which is the actual > class returned > > by getCustomPublisher. It basically always creates a new > instance of > > itself and then calls the willPublishCertificate method on > itself and so > > on forever. > > > > I hardcoded it false and the enrollment started working. Then > I checked > > how it was in the original 6.2.0 source and saw that the > BasePublisher > > class had the method back then and it was hardcoded to true. > So I tried > > that on out 6.10.0 source and then got a > StackoverflowException from the > > method isFullEntityPublishingSupported again > > in CustomPublisherContainer. There it again ask for > getCustomPublisher, > > gets a new instance of itself and calls the method on the new > instance > > again resulting in an endless recursion. > > > > The whole process of ending with these issues is -> create new end > > entity using our previously existing CAs --> go to public web > and try to > > enroll. > > > > What are we doing wrong? > > > > > > > > > > _______________________________________________ > > 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: John R <joh...@gm...> - 2018-10-15 13:07:14
|
I made a small mistake. The second error in the log doesn't happen when the value of willPublishCertificate is hardcoded to false. When it's hardcoded to false the enrollment passes. When it's hardcoded to true the error occurs. On Mon, Oct 15, 2018 at 3:48 PM John R <joh...@gm...> wrote: > Hi Thomas, thanks for the quick response. > > I'm attaching a file with 3 exceptions in it. They all basically come down > to the same thing - the use of getCustomPublisher > in CustomPublisherContainer . The version of ejbca as seen in the log > is 6.10.1.2 r27920. > Also I'm not sure if this is any help but while doing really light > debugging I saw that the ICustomPublisher that getCustomPublisher returns > in our case is LegacyValidationAuthorityPublisher which I think is the > reason for the recursion in the first place since it doesn't have it's own > implementation of those methods. > > On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson <to...@pr...> > wrote: > >> >> This is nothing we have heard before. Can you post the stack trace you >> get in server.log. As well as state the exact version you use. >> >> Regards, >> Tomas >> >> On 2018-10-15 12:48, John R wrote: >> > Hello, >> > >> > We tried upgrading from 6.2.0 to 6.10.0 following the guide on the site. >> > Everything seemed to work but now we can't enroll the certificate. I did >> > some light digging and the problem seems to be the method >> > willPublishCertificate in CustomPublisherContainer which is inherited >> > by LegacyValidationAuthorityPublisher which is the actual class returned >> > by getCustomPublisher. It basically always creates a new instance of >> > itself and then calls the willPublishCertificate method on itself and so >> > on forever. >> > >> > I hardcoded it false and the enrollment started working. Then I checked >> > how it was in the original 6.2.0 source and saw that the BasePublisher >> > class had the method back then and it was hardcoded to true. So I tried >> > that on out 6.10.0 source and then got a StackoverflowException from the >> > method isFullEntityPublishingSupported again >> > in CustomPublisherContainer. There it again ask for getCustomPublisher, >> > gets a new instance of itself and calls the method on the new instance >> > again resulting in an endless recursion. >> > >> > The whole process of ending with these issues is -> create new end >> > entity using our previously existing CAs --> go to public web and try to >> > enroll. >> > >> > What are we doing wrong? >> > >> > >> > >> > >> > _______________________________________________ >> > Ejbca-develop mailing list >> > Ejb...@li... >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > |
|
From: John R <joh...@gm...> - 2018-10-15 12:48:28
|
Hi Thomas, thanks for the quick response. I'm attaching a file with 3 exceptions in it. They all basically come down to the same thing - the use of getCustomPublisher in CustomPublisherContainer . The version of ejbca as seen in the log is 6.10.1.2 r27920. Also I'm not sure if this is any help but while doing really light debugging I saw that the ICustomPublisher that getCustomPublisher returns in our case is LegacyValidationAuthorityPublisher which I think is the reason for the recursion in the first place since it doesn't have it's own implementation of those methods. On Mon, Oct 15, 2018 at 3:06 PM Tomas Gustavsson <to...@pr...> wrote: > > This is nothing we have heard before. Can you post the stack trace you > get in server.log. As well as state the exact version you use. > > Regards, > Tomas > > On 2018-10-15 12:48, John R wrote: > > Hello, > > > > We tried upgrading from 6.2.0 to 6.10.0 following the guide on the site. > > Everything seemed to work but now we can't enroll the certificate. I did > > some light digging and the problem seems to be the method > > willPublishCertificate in CustomPublisherContainer which is inherited > > by LegacyValidationAuthorityPublisher which is the actual class returned > > by getCustomPublisher. It basically always creates a new instance of > > itself and then calls the willPublishCertificate method on itself and so > > on forever. > > > > I hardcoded it false and the enrollment started working. Then I checked > > how it was in the original 6.2.0 source and saw that the BasePublisher > > class had the method back then and it was hardcoded to true. So I tried > > that on out 6.10.0 source and then got a StackoverflowException from the > > method isFullEntityPublishingSupported again > > in CustomPublisherContainer. There it again ask for getCustomPublisher, > > gets a new instance of itself and calls the method on the new instance > > again resulting in an endless recursion. > > > > The whole process of ending with these issues is -> create new end > > entity using our previously existing CAs --> go to public web and try to > > enroll. > > > > What are we doing wrong? > > > > > > > > > > _______________________________________________ > > 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...> - 2018-10-15 12:05:51
|
This is nothing we have heard before. Can you post the stack trace you get in server.log. As well as state the exact version you use. Regards, Tomas On 2018-10-15 12:48, John R wrote: > Hello, > > We tried upgrading from 6.2.0 to 6.10.0 following the guide on the site. > Everything seemed to work but now we can't enroll the certificate. I did > some light digging and the problem seems to be the method > willPublishCertificate in CustomPublisherContainer which is inherited > by LegacyValidationAuthorityPublisher which is the actual class returned > by getCustomPublisher. It basically always creates a new instance of > itself and then calls the willPublishCertificate method on itself and so > on forever. > > I hardcoded it false and the enrollment started working. Then I checked > how it was in the original 6.2.0 source and saw that the BasePublisher > class had the method back then and it was hardcoded to true. So I tried > that on out 6.10.0 source and then got a StackoverflowException from the > method isFullEntityPublishingSupported again > in CustomPublisherContainer. There it again ask for getCustomPublisher, > gets a new instance of itself and calls the method on the new instance > again resulting in an endless recursion. > > The whole process of ending with these issues is -> create new end > entity using our previously existing CAs --> go to public web and try to > enroll. > > What are we doing wrong? > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: John R <joh...@gm...> - 2018-10-15 10:49:17
|
Hello, We tried upgrading from 6.2.0 to 6.10.0 following the guide on the site. Everything seemed to work but now we can't enroll the certificate. I did some light digging and the problem seems to be the method willPublishCertificate in CustomPublisherContainer which is inherited by LegacyValidationAuthorityPublisher which is the actual class returned by getCustomPublisher. It basically always creates a new instance of itself and then calls the willPublishCertificate method on itself and so on forever. I hardcoded it false and the enrollment started working. Then I checked how it was in the original 6.2.0 source and saw that the BasePublisher class had the method back then and it was hardcoded to true. So I tried that on out 6.10.0 source and then got a StackoverflowException from the method isFullEntityPublishingSupported again in CustomPublisherContainer. There it again ask for getCustomPublisher, gets a new instance of itself and calls the method on the new instance again resulting in an endless recursion. The whole process of ending with these issues is -> create new end entity using our previously existing CAs --> go to public web and try to enroll. What are we doing wrong? |
|
From: Tomas G. <to...@pr...> - 2018-10-11 11:55:29
|
Here is an example from the documentation how to use the CLI to renew superadmin. https://www.ejbca.org/docs/Renewing_Superadmin.html Regards, Tomas --- PrimeKey Solutions AB Solna Access Plan A8, Sundbybergsvägen 1, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI On 2018-10-10 13:02, Gregory Edigarov wrote: > Hello, > > how can I force (so it will not look at database) reissue of superadmin > certificate using only cli tools? > > it seems to be the only issue stays for now, with my old ejbca database > in the new install. > > so decided to start a new thread. > > thank you. > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Gregory E. <edi...@qa...> - 2018-10-10 11:02:46
|
Hello, how can I force (so it will not look at database) reissue of superadmin certificate using only cli tools? it seems to be the only issue stays for now, with my old ejbca database in the new install. so decided to start a new thread. thank you. |
|
From: Gregory E. <edi...@qa...> - 2018-10-09 15:59:28
|
On 09.10.18 18:35, Gregory Edigarov wrote: > > > On 04.10.18 10:09, Tomas Gustavsson wrote: >> Hi, >> >> Upgrading from EJBCA 3.11 is possible yes, and has been done in large >> production installations. You will even find some threads about it in >> the Web Forum, upgrading successfully. >> >> EJBCA CE 6.3.1.1 is not the way to go though. Start by reading the >> official upgrade documentation: >> https://www.ejbca.org/docs/Upgrading_EJBCA.html >> and >> http://blog.ejbca.org/2017/12/the-definitive-ejbca-upgrade-guide.html >> >> Upgrading from a 8 year old version should not be expected to be without >> work from your side. Keeping a little more ahead on upgrades as the >> years go by is highly recommended, it will ensure upgrades are smooth on >> the way. Now you are up for a bit of ride :-) > hmmm. the proposed path seems to be a bit of complex. > what if I: > 1. install fresh ejbca-6... > 2. dump a copy of database (mysql with 'full insert' statements) > 3. make the necessary changes in the structure of a database > 4. put the data back. > if fact i've tried this way already, but for some yet unclear reason > after i put the database into (went fine) > and restart ejbca, that doesn't work. > will retry that tomorrow, when I'll have a fresh head. just a correction. the whole thing seem to start and work. but the problem now is the superadmin certificate mess, if I will get rid of the mess somehow, or just make it regenerate superadmin cert, it may even work correctly. >> Regards, >> Tomas >> --- >> Save time and money with an Enterprise support subscription. Please see >> www.primekey.com for more information. >> https://www.primekey.com/products/software/ >> >> On 2018-10-03 17:31, Gregory Edigarov wrote: >>> Hello folks. >>> >>> ok, after some adventures with various mistakes my copy of ejbca became >>> somewhat runnable. >>> >>> but the real task is to have it run on old database (we have a ejbca db >>> from version EJBCA 3.11.1 (r10959) and we need to put it into: >>> EJBCA CE 6.3.1.1) >>> Is that doable somehow? >>> >>> >>> On 03.10.18 10:17, Tomas Gustavsson wrote: >>>> It looks like your EJBCA did not get deployed in WildFly. >>>> >>>> After "ant deployear" you should check WildFly that it has started >>>> correctly without errors. >>>> >>>> The most common cause of failyre to deploy are errors in the database >>>> configuration. >>>> >>>> Regards, >>>> Tomas >>>> >>>> On 2018-10-02 17:35, Gregory Edigarov wrote: >>>>> ok. doing the steps described in the doc >>>>> >>>>> >>> >>> >>> _______________________________________________ >>> 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: Gregory E. <edi...@qa...> - 2018-10-09 15:35:32
|
On 04.10.18 10:09, Tomas Gustavsson wrote: > Hi, > > Upgrading from EJBCA 3.11 is possible yes, and has been done in large > production installations. You will even find some threads about it in > the Web Forum, upgrading successfully. > > EJBCA CE 6.3.1.1 is not the way to go though. Start by reading the > official upgrade documentation: > https://www.ejbca.org/docs/Upgrading_EJBCA.html > and > http://blog.ejbca.org/2017/12/the-definitive-ejbca-upgrade-guide.html > > Upgrading from a 8 year old version should not be expected to be without > work from your side. Keeping a little more ahead on upgrades as the > years go by is highly recommended, it will ensure upgrades are smooth on > the way. Now you are up for a bit of ride :-) hmmm. the proposed path seems to be a bit of complex. what if I: 1. install fresh ejbca-6... 2. dump a copy of database (mysql with 'full insert' statements) 3. make the necessary changes in the structure of a database 4. put the data back. if fact i've tried this way already, but for some yet unclear reason after i put the database into (went fine) and restart ejbca, that doesn't work. will retry that tomorrow, when I'll have a fresh head. > Regards, > Tomas > --- > Save time and money with an Enterprise support subscription. Please see > www.primekey.com for more information. > https://www.primekey.com/products/software/ > > On 2018-10-03 17:31, Gregory Edigarov wrote: >> Hello folks. >> >> ok, after some adventures with various mistakes my copy of ejbca became >> somewhat runnable. >> >> but the real task is to have it run on old database (we have a ejbca db >> from version EJBCA 3.11.1 (r10959) and we need to put it into: >> EJBCA CE 6.3.1.1) >> Is that doable somehow? >> >> >> On 03.10.18 10:17, Tomas Gustavsson wrote: >>> It looks like your EJBCA did not get deployed in WildFly. >>> >>> After "ant deployear" you should check WildFly that it has started >>> correctly without errors. >>> >>> The most common cause of failyre to deploy are errors in the database >>> configuration. >>> >>> Regards, >>> Tomas >>> >>> On 2018-10-02 17:35, Gregory Edigarov wrote: >>>> ok. doing the steps described in the doc >>>> >>>> >> >> >> _______________________________________________ >> 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...> - 2018-10-04 07:09:44
|
Hi, Upgrading from EJBCA 3.11 is possible yes, and has been done in large production installations. You will even find some threads about it in the Web Forum, upgrading successfully. EJBCA CE 6.3.1.1 is not the way to go though. Start by reading the official upgrade documentation: https://www.ejbca.org/docs/Upgrading_EJBCA.html and http://blog.ejbca.org/2017/12/the-definitive-ejbca-upgrade-guide.html Upgrading from a 8 year old version should not be expected to be without work from your side. Keeping a little more ahead on upgrades as the years go by is highly recommended, it will ensure upgrades are smooth on the way. Now you are up for a bit of ride :-) Regards, Tomas --- Save time and money with an Enterprise support subscription. Please see www.primekey.com for more information. https://www.primekey.com/products/software/ On 2018-10-03 17:31, Gregory Edigarov wrote: > Hello folks. > > ok, after some adventures with various mistakes my copy of ejbca became > somewhat runnable. > > but the real task is to have it run on old database (we have a ejbca db > from version EJBCA 3.11.1 (r10959) and we need to put it into: > EJBCA CE 6.3.1.1) > Is that doable somehow? > > > On 03.10.18 10:17, Tomas Gustavsson wrote: >> It looks like your EJBCA did not get deployed in WildFly. >> >> After "ant deployear" you should check WildFly that it has started >> correctly without errors. >> >> The most common cause of failyre to deploy are errors in the database >> configuration. >> >> Regards, >> Tomas >> >> On 2018-10-02 17:35, Gregory Edigarov wrote: >>> ok. doing the steps described in the doc >>> >>> > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Gregory E. <edi...@qa...> - 2018-10-03 15:32:06
|
Hello folks. ok, after some adventures with various mistakes my copy of ejbca became somewhat runnable. but the real task is to have it run on old database (we have a ejbca db from version EJBCA 3.11.1 (r10959) and we need to put it into: EJBCA CE 6.3.1.1) Is that doable somehow? On 03.10.18 10:17, Tomas Gustavsson wrote: > It looks like your EJBCA did not get deployed in WildFly. > > After "ant deployear" you should check WildFly that it has started > correctly without errors. > > The most common cause of failyre to deploy are errors in the database > configuration. > > Regards, > Tomas > > On 2018-10-02 17:35, Gregory Edigarov wrote: >> ok. doing the steps described in the doc >> >> |
|
From: Tomas G. <to...@pr...> - 2018-10-03 07:18:12
|
It looks like your EJBCA did not get deployed in WildFly. After "ant deployear" you should check WildFly that it has started correctly without errors. The most common cause of failyre to deploy are errors in the database configuration. Regards, Tomas On 2018-10-02 17:35, Gregory Edigarov wrote: > ok. doing the steps described in the doc > > https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.html > > ant runinstall > > press entrer to all questions leaving it to default for now (it is a > test install) > > and have the following : > > ejbca:initCA: > [echo] Initializing CA with 'ManagementCA' 'CN=ManagementCA,O=EJBCA > Sample,C=SE' 'soft' <ca.tokenpassword hidden> '2048' 'RSA' '3650' 'null' > 'SHA256WithRSA' -superadmincn 'SuperAdmin'... > [java] WildFly Naming version 1.0.7.Final > [java] ELY00001: WildFly Elytron version 1.2.2.Final > [java] Exception in thread "main" > java.util.ServiceConfigurationError: > org.ejbca.ui.cli.infrastructure.command.CliCommandPlugin: Provider > org.ejbca.ui.cli.ra.AddEndEntityCommand could not be instantiated > [java] at java.util.ServiceLoader.fail(ServiceLoader.java:232) > [java] at > java.util.ServiceLoader.access$100(ServiceLoader.java:185) > [java] at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384) > [java] at > java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > [java] at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > [java] at > org.ejbca.ui.cli.infrastructure.library.CommandLibrary.<init>(CommandLibrary.java:55) > > [java] at > org.ejbca.ui.cli.infrastructure.library.CommandLibrary.<clinit>(CommandLibrary.java:39) > > [java] at org.ejbca.ui.cli.EjbcaEjbCli.main(EjbcaEjbCli.java:29) > [java] Caused by: javax.ejb.NoSuchEJBException: EJBCLIENT000079: > Unable to discover destination for request for EJB StatelessEJBLocator > for "ejbca/cesecore-ejb/GlobalConfigurationSessionBean", view is > interface org.cesecore.configuration.GlobalConfigurationSessionRemote, > affinity is None > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:108) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) > > [java] at > org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:913) > > [java] at > org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177) > > [java] at > org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112) > > [java] at com.sun.proxy.$Proxy0.getCachedConfiguration(Unknown > Source) > [java] at > org.ejbca.ui.cli.ra.AddEndEntityCommand.<init>(AddEndEntityCommand.java:93) > [java] at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > [java] at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > [java] at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > [java] at > java.lang.reflect.Constructor.newInstance(Constructor.java:423) > [java] at java.lang.Class.newInstance(Class.java:442) > [java] at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) > [java] ... 5 more > [java] Suppressed: javax.ejb.NoSuchEJBException: No such EJB: > ejbca/cesecore-ejb/GlobalConfigurationSessionBean @ > http-remoting://localhost:4447 > [java] at > org.jboss.ejb.protocol.remote.EJBClientChannel$MethodInvocation.handleResponse(EJBClientChannel.java:1070) > > [java] at > org.jboss.ejb.protocol.remote.EJBClientChannel$MethodInvocation.handleResponse(EJBClientChannel.java:997) > > [java] at > org.jboss.remoting3.util.InvocationTracker.signalResponse(InvocationTracker.java:167) > > [java] at > org.jboss.ejb.protocol.remote.EJBClientChannel.processMessage(EJBClientChannel.java:186) > > [java] at > org.jboss.ejb.protocol.remote.EJBClientChannel.access$100(EJBClientChannel.java:112) > > [java] at > org.jboss.ejb.protocol.remote.EJBClientChannel$1$1.handleMessage(EJBClientChannel.java:675) > > [java] at > org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > > [java] at > org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) > > [java] at > org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > > [java] at > org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > > [java] at > org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > > [java] at > org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > > [java] at java.lang.Thread.run(Thread.java:748) > > what's that? > > On 02.10.18 12:31, Tomas Gustavsson wrote: >> Hi, >> >> If you are running WildFly you should absolutely not run "ant deploy". >> >> See the WildFly installation instructions. >> https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.html >> >> Regards, >> Tomas >> >> On 2018-10-02 10:56, Gregory Edigarov wrote: >>> >>> On 01.10.18 17:52, Gregory Edigarov wrote: >>>> >>>> On 01.10.18 17:24, Tomas Gustavsson wrote: >>>>> Congratulations. First tester o WildFly 14 :-) >>>> good to know :-) >>>> well, I am absolutely not bound to it. I think I will try WildFly 12, >>>> if you advise. >>>>> I've never tried on that, WildFly 12 and JBoss EAP 7.1 is known to >>>>> work >>>>> though. >>>>> >>>>> Related to the error, do you have any idea what the "smallrye" is? >>>>> This >>>>> seem to be the failing part in the deployment. >>> Hello, Thomas >>> >>> I've tried and things seemed to be going smooth, except one small >>> caveat. My datasource is already configured via web interface >>> so I want to skip creation of datasource when I do deployment via 'ant >>> deploy'. Is that possible? >>> >>> -- >>> With best regards, >>> Gregory Edigarov >>> >>> >>> _______________________________________________ >>> 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: Gregory E. <edi...@qa...> - 2018-10-02 15:35:39
|
ok. doing the steps described in the doc https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.html ant runinstall press entrer to all questions leaving it to default for now (it is a test install) and have the following : ejbca:initCA: [echo] Initializing CA with 'ManagementCA' 'CN=ManagementCA,O=EJBCA Sample,C=SE' 'soft' <ca.tokenpassword hidden> '2048' 'RSA' '3650' 'null' 'SHA256WithRSA' -superadmincn 'SuperAdmin'... [java] WildFly Naming version 1.0.7.Final [java] ELY00001: WildFly Elytron version 1.2.2.Final [java] Exception in thread "main" java.util.ServiceConfigurationError: org.ejbca.ui.cli.infrastructure.command.CliCommandPlugin: Provider org.ejbca.ui.cli.ra.AddEndEntityCommand could not be instantiated [java] at java.util.ServiceLoader.fail(ServiceLoader.java:232) [java] at java.util.ServiceLoader.access$100(ServiceLoader.java:185) [java] at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384) [java] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) [java] at java.util.ServiceLoader$1.next(ServiceLoader.java:480) [java] at org.ejbca.ui.cli.infrastructure.library.CommandLibrary.<init>(CommandLibrary.java:55) [java] at org.ejbca.ui.cli.infrastructure.library.CommandLibrary.<clinit>(CommandLibrary.java:39) [java] at org.ejbca.ui.cli.EjbcaEjbCli.main(EjbcaEjbCli.java:29) [java] Caused by: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "ejbca/cesecore-ejb/GlobalConfigurationSessionBean", view is interface org.cesecore.configuration.GlobalConfigurationSessionRemote, affinity is None [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:108) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [java] at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [java] at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:913) [java] at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177) [java] at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112) [java] at com.sun.proxy.$Proxy0.getCachedConfiguration(Unknown Source) [java] at org.ejbca.ui.cli.ra.AddEndEntityCommand.<init>(AddEndEntityCommand.java:93) [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [java] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) [java] at java.lang.Class.newInstance(Class.java:442) [java] at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) [java] ... 5 more [java] Suppressed: javax.ejb.NoSuchEJBException: No such EJB: ejbca/cesecore-ejb/GlobalConfigurationSessionBean @ http-remoting://localhost:4447 [java] at org.jboss.ejb.protocol.remote.EJBClientChannel$MethodInvocation.handleResponse(EJBClientChannel.java:1070) [java] at org.jboss.ejb.protocol.remote.EJBClientChannel$MethodInvocation.handleResponse(EJBClientChannel.java:997) [java] at org.jboss.remoting3.util.InvocationTracker.signalResponse(InvocationTracker.java:167) [java] at org.jboss.ejb.protocol.remote.EJBClientChannel.processMessage(EJBClientChannel.java:186) [java] at org.jboss.ejb.protocol.remote.EJBClientChannel.access$100(EJBClientChannel.java:112) [java] at org.jboss.ejb.protocol.remote.EJBClientChannel$1$1.handleMessage(EJBClientChannel.java:675) [java] at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) [java] at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) [java] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [java] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [java] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [java] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [java] at java.lang.Thread.run(Thread.java:748) what's that? On 02.10.18 12:31, Tomas Gustavsson wrote: > Hi, > > If you are running WildFly you should absolutely not run "ant deploy". > > See the WildFly installation instructions. > https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.html > > Regards, > Tomas > > On 2018-10-02 10:56, Gregory Edigarov wrote: >> >> On 01.10.18 17:52, Gregory Edigarov wrote: >>> >>> On 01.10.18 17:24, Tomas Gustavsson wrote: >>>> Congratulations. First tester o WildFly 14 :-) >>> good to know :-) >>> well, I am absolutely not bound to it. I think I will try WildFly 12, >>> if you advise. >>>> I've never tried on that, WildFly 12 and JBoss EAP 7.1 is known to work >>>> though. >>>> >>>> Related to the error, do you have any idea what the "smallrye" is? This >>>> seem to be the failing part in the deployment. >> Hello, Thomas >> >> I've tried and things seemed to be going smooth, except one small >> caveat. My datasource is already configured via web interface >> so I want to skip creation of datasource when I do deployment via 'ant >> deploy'. Is that possible? >> >> -- >> With best regards, >> Gregory Edigarov >> >> >> _______________________________________________ >> 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...> - 2018-10-02 09:52:35
|
Hi, The arabic translation is just not complete, that's the simple reason. So it's more of a display case at the moment, that it can be done. Translations are rather easy to do though, as everything is in language files. Cheers, Tomas On 2018-10-02 11:07, medina seid wrote: > Hello Everyone, > I am running EJBCA_CE_6_10 VM and working properly. The issue i have > seen is when changing the preference language in the RA web to Arabic it > only change text direction(right to left) nothing more. Do i need other > configuration to change language? > ejbca ra web arabic.png > > > > > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2018-10-02 09:48:05
|
Hi Vikas, If you contact Eric or Alex we can talk about Docker containers more. The rough timeline for more thorough containers (which are part of our CI pipeline) is end of the year. So we can definitely work with you on containers. Regards, Tomas On 2018-10-02 07:42, Vikas Gupta wrote: > Thanks Tomas. That's great. Are you able to share the Dockerfile for pk/dev-ejbca docker image? > >> We are also working on an official Docker build at PrimeKey so that will come soon. > What's the rough timeline for this? > > Thanks. > -Vikas > > On 9/29/18, 12:46 AM, "Tomas Gustavsson" <to...@pr...> wrote: > > > Hi, > > Yes EJBCA runs great in Docker. I have my VA/RA running in a Docker > container (one mariadb docker and one ejbca docker), and I connect to > this from my CA running natively on the laptop. It works great! > > Easy set up with two simple commands: > > sudo docker run --name mariadb -e MYSQL_ROOT_PASSWORD=password -e > MYSQL_DATABASE=ejbca -e MYSQL_USER=ejbca -e MYSQL_PASSWORD=password -d > mariadb > > sudo docker run \ > --name ejbca.dev.primekey.com \ > --hostname ejbca.dev.primekey.com \ > --publish 18080:8080 \ > --publish 18442:8442 \ > --publish 18443:8443 \ > --link mariadb:mariadb \ > --volume dev-ejbca_ejbca_custom:/etc/ejbca \ > --volume > dev-ejbca_wildfly_configuration:/opt/wildfly/standalone/configuration \ > --volume dev-ejbca_wildfly_deployments:/opt/wildfly/standalone/deployments \ > --volume dev-ejbca_wildfly_log:/opt/wildfly/standalone/log \ > -e MYSQL_IP_ADDRESS=mariadb \ > -e MYSQL_DATABASE=ejbca \ > -e MYSQL_USER=ejbca \ > -e MYSQL_PASSWORD=password \ > -d \ > pk/dev-ejbca > > The docker links you found look quite old, 3 years I don't know how > useful it is. We made our own Development Docker builds at PrimeKey. > > We are also working on an official Docker build at PrimeKey so that will > come soon. > > Regards, > Tomas > > > On 2018-09-28 20:43, Vikas Gupta wrote: > > Hi EJBCA devs, > > > > > > > > I am trying to run a standalone EJBCA VA. I was curious if anyone here > > has used EJBCA inside docker. How was your experience? I found these 2 > > repos after a quick google search: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tsaarni_docker-2Dejbca&d=DwIGaQ&c=HAYSQ9u8txbDCH3D0R6amQ&r=Qzr5x6JZ4B51CrdGxmVEw0fGt1JX6-VQgehxcy1Q5a0&m=LQuM-lvQM_525xRiCW5Cs1a3uev70mYq_YJSckmO5p8&s=Nqdj01iLd88QRCyYT1Y_nG7kNGtBD-wjQcZsc6WYG-o&e= > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_r_vkyii_ejbca&d=DwIGaQ&c=HAYSQ9u8txbDCH3D0R6amQ&r=Qzr5x6JZ4B51CrdGxmVEw0fGt1JX6-VQgehxcy1Q5a0&m=LQuM-lvQM_525xRiCW5Cs1a3uev70mYq_YJSckmO5p8&s=q6BHa4guqOfyvfm5qtkM4qs_e5m9OnKO_5-rdbCGyOM&e= > > > > > > > > Thanks. > > > > -- > > > > Vikas > > > > > > > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ejbca-2Ddevelop&d=DwIGaQ&c=HAYSQ9u8txbDCH3D0R6amQ&r=Qzr5x6JZ4B51CrdGxmVEw0fGt1JX6-VQgehxcy1Q5a0&m=LQuM-lvQM_525xRiCW5Cs1a3uev70mYq_YJSckmO5p8&s=MaCP4AqwUPbplzFrhAiCq7fYOUa7H-YB21vavuSwHOI&e= > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ejbca-2Ddevelop&d=DwIGaQ&c=HAYSQ9u8txbDCH3D0R6amQ&r=Qzr5x6JZ4B51CrdGxmVEw0fGt1JX6-VQgehxcy1Q5a0&m=LQuM-lvQM_525xRiCW5Cs1a3uev70mYq_YJSckmO5p8&s=MaCP4AqwUPbplzFrhAiCq7fYOUa7H-YB21vavuSwHOI&e= > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2018-10-02 09:31:15
|
Hi, If you are running WildFly you should absolutely not run "ant deploy". See the WildFly installation instructions. https://www.ejbca.org/docs/WildFly_10___JBoss_EAP_7.html Regards, Tomas On 2018-10-02 10:56, Gregory Edigarov wrote: > > > On 01.10.18 17:52, Gregory Edigarov wrote: >> >> >> On 01.10.18 17:24, Tomas Gustavsson wrote: >>> Congratulations. First tester o WildFly 14 :-) >> good to know :-) >> well, I am absolutely not bound to it. I think I will try WildFly 12, >> if you advise. >>> I've never tried on that, WildFly 12 and JBoss EAP 7.1 is known to work >>> though. >>> >>> Related to the error, do you have any idea what the "smallrye" is? This >>> seem to be the failing part in the deployment. > Hello, Thomas > > I've tried and things seemed to be going smooth, except one small > caveat. My datasource is already configured via web interface > so I want to skip creation of datasource when I do deployment via 'ant > deploy'. Is that possible? > > -- > With best regards, > Gregory Edigarov > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: medina s. <med...@gm...> - 2018-10-02 09:06:28
|
Hello Everyone, I am running EJBCA_CE_6_10 VM and working properly. The issue i have seen is when changing the preference language in the RA web to Arabic it only change text direction(right to left) nothing more. Do i need other configuration to change language? [image: ejbca ra web arabic.png] |
106 messages has been excluded from this view by a project administrator.
