ejbca-develop — Development discussions

Re: [Ejbca-develop] OID Name in SAN for Search Guard node TLS certificate

[Tomas G. <to...@pr...>]

registeredID is available since this issue:
https://jira.primekey.se/browse/ECA-5279

Not in the released community version unfortunately, as it is since
6.5.4/6.6.0

Regards,
Tomas

On 2017-05-09 17:19, Willi Trace wrote:
> According this example:
> https://github.com/floragunncom/search-guard-ssl/blob/5.3.0/example-pki-scripts/gen_node_cert_openssl.sh
> 
> It seems that OIDName is registeredID.
> The same as SAN type oid in Java keytool.
> 
> How can I set registeredID in SAN in EJBCA End Entity Profile?
> 
> Best regards,
> WT
> 
> On Tuesday, May 9, 2017, Tomas Gustavsson <to...@pr...
> <mailto:to...@pr...>> wrote:
> 
> 
>     What is OIDName and where is it specified?
> 
>     RFC5280 specifies SANs, se section 4.2.1.6.
>     https://www.ietf.org/rfc/rfc5280.txt
>     <https://www.ietf.org/rfc/rfc5280.txt>
> 
>     I can't find OIDName there.
> 
>     My best guess is that you mean registeredID, but the Search Guard spec
>     should explain better what OIDName is, since it's not one of the
>     standard SAN fields. I can't find it in the RedHat spec that it points
>     to either...
> 
>     Cheers,
>     Tomas
>     **********
>     PrimeKey Solutions AB
>     Lundagatan 16, 171 63 Solna, Sweden
>     Mob: +46 (0)707421096
>     Internet: www.primekey.com <http://www.primekey.com>
>     Twitter: twitter.com/primekeyPKI <http://twitter.com/primekeyPKI>
>     **********
> 
> 
>     On 2017-05-09 15:53, Willi Trace wrote:
>     > Dear All,
>     >
>     > I would like to issue certificates for Search Guard through EJBCA.
>     > Search Guard has its own requirements for certificate SAN which should
>     > contain OID Name with some value (default 1.2.3.4.5.5):
>     >
>     https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md
>     <https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md>
>     >
>     > How can be such SAN configured in EJBCA?
>     >
>     > There are these options:
>     > RFC 822 Name
>     > DNS Name
>     > IP Address
>     > Directory Name
>     > Uniform Resource Identifier
>     > MS UPN
>     > MS GUID
>     > Kerberos KPN
>     > Permanent Identifier
>     >
>     > I tried to use Permanent Identifier with value OIDName/1.2.3.4.5.5 but
>     > it is not correct.
>     > According keytool -list -v I have the following:
>     > #8: ObjectId: 2.5.29.17 Criticality=false
>     > SubjectAlternativeName [
>     >   Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.5.5.7.8.3
>     > ]
>     >
>     > Instead of
>     > #8: ObjectId: 2.5.29.17 Criticality=false
>     > SubjectAlternativeName [
>     >   OIDName: 1.2.3.4.5.5
>     > ]
>     >
>     > Is there any way how to do it in EJBCA or it should be developed
>     somehow
>     > as custom SAN OID?
>     >
>     > Best regards
>     > WT
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Check out the vibrant tech community on one of the world's most
>     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     >
>     >
>     >
>     > _______________________________________________
>     > Ejbca-develop mailing list
>     > Ejb...@li... <javascript:;>
>     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >
> 
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Ejbca-develop mailing list
>     Ejb...@li... <javascript:;>
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] OID Name in SAN for Search Guard node TLS certificate

[Willi T. <wil...@gm...>]

According this example:
https://github.com/floragunncom/search-guard-ssl/blob/5.3.0/example-pki-scripts/gen_node_cert_openssl.sh

It seems that OIDName is registeredID.
The same as SAN type oid in Java keytool.

How can I set registeredID in SAN in EJBCA End Entity Profile?

Best regards,
WT

On Tuesday, May 9, 2017, Tomas Gustavsson <to...@pr...> wrote:

>
> What is OIDName and where is it specified?
>
> RFC5280 specifies SANs, se section 4.2.1.6.
> https://www.ietf.org/rfc/rfc5280.txt
>
> I can't find OIDName there.
>
> My best guess is that you mean registeredID, but the Search Guard spec
> should explain better what OIDName is, since it's not one of the
> standard SAN fields. I can't find it in the RedHat spec that it points
> to either...
>
> Cheers,
> Tomas
> **********
> PrimeKey Solutions AB
> Lundagatan 16, 171 63 Solna, Sweden
> Mob: +46 (0)707421096
> Internet: www.primekey.com
> Twitter: twitter.com/primekeyPKI
> **********
>
>
> On 2017-05-09 15:53, Willi Trace wrote:
> > Dear All,
> >
> > I would like to issue certificates for Search Guard through EJBCA.
> > Search Guard has its own requirements for certificate SAN which should
> > contain OID Name with some value (default 1.2.3.4.5.5):
> > https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_
> certificates.md
> >
> > How can be such SAN configured in EJBCA?
> >
> > There are these options:
> > RFC 822 Name
> > DNS Name
> > IP Address
> > Directory Name
> > Uniform Resource Identifier
> > MS UPN
> > MS GUID
> > Kerberos KPN
> > Permanent Identifier
> >
> > I tried to use Permanent Identifier with value OIDName/1.2.3.4.5.5 but
> > it is not correct.
> > According keytool -list -v I have the following:
> > #8: ObjectId: 2.5.29.17 Criticality=false
> > SubjectAlternativeName [
> >   Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.5.5.7.8.3
> > ]
> >
> > Instead of
> > #8: ObjectId: 2.5.29.17 Criticality=false
> > SubjectAlternativeName [
> >   OIDName: 1.2.3.4.5.5
> > ]
> >
> > Is there any way how to do it in EJBCA or it should be developed somehow
> > as custom SAN OID?
> >
> > Best regards
> > WT
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li... <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] OID Name in SAN for Search Guard node TLS certificate

[Tomas G. <to...@pr...>]

What is OIDName and where is it specified?

RFC5280 specifies SANs, se section 4.2.1.6.
https://www.ietf.org/rfc/rfc5280.txt

I can't find OIDName there.

My best guess is that you mean registeredID, but the Search Guard spec
should explain better what OIDName is, since it's not one of the
standard SAN fields. I can't find it in the RedHat spec that it points
to either...

Cheers,
Tomas
**********
PrimeKey Solutions AB
Lundagatan 16, 171 63 Solna, Sweden
Mob: +46 (0)707421096
Internet: www.primekey.com
Twitter: twitter.com/primekeyPKI
**********


On 2017-05-09 15:53, Willi Trace wrote:
> Dear All,
> 
> I would like to issue certificates for Search Guard through EJBCA.
> Search Guard has its own requirements for certificate SAN which should
> contain OID Name with some value (default 1.2.3.4.5.5):
> https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md
> 
> How can be such SAN configured in EJBCA?
> 
> There are these options:
> RFC 822 Name
> DNS Name
> IP Address
> Directory Name
> Uniform Resource Identifier
> MS UPN
> MS GUID
> Kerberos KPN
> Permanent Identifier
> 
> I tried to use Permanent Identifier with value OIDName/1.2.3.4.5.5 but
> it is not correct.
> According keytool -list -v I have the following:
> #8: ObjectId: 2.5.29.17 Criticality=false
> SubjectAlternativeName [
>   Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.5.5.7.8.3
> ]
> 
> Instead of
> #8: ObjectId: 2.5.29.17 Criticality=false
> SubjectAlternativeName [
>   OIDName: 1.2.3.4.5.5
> ]
> 
> Is there any way how to do it in EJBCA or it should be developed somehow
> as custom SAN OID?
> 
> Best regards
> WT
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] OID Name in SAN for Search Guard node TLS certificate

[Willi T. <wil...@gm...>]

Dear All,

I would like to issue certificates for Search Guard through EJBCA. Search
Guard has its own requirements for certificate SAN which should contain OID
Name with some value (default 1.2.3.4.5.5):
https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md

How can be such SAN configured in EJBCA?

There are these options:
RFC 822 Name
DNS Name
IP Address
Directory Name
Uniform Resource Identifier
MS UPN
MS GUID
Kerberos KPN
Permanent Identifier

I tried to use Permanent Identifier with value OIDName/1.2.3.4.5.5 but it
is not correct.
According keytool -list -v I have the following:
#8: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.5.5.7.8.3
]

Instead of
#8: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  OIDName: 1.2.3.4.5.5
]

Is there any way how to do it in EJBCA or it should be developed somehow as
custom SAN OID?

Best regards
WT

[Ejbca-develop] Instant Certificate Solution

[Christian F. <pu...@fe...>]

Hello,

External Registration Authority for instant certificates got some
improvements:

* Supports Authentication (by Apache Shiro)
* latest versions of client side Javascript libraries
* Improved build system for Javascript libraries
* latest versions of server side Java libraries

https://github.com/ip6li/registration-authority

regards
Christian

Re: [Ejbca-develop] Script for set up EJBCA on Wildfly 10

[Christian F. <pu...@fe...>]

Hi Tomas,

new version is available now at
https://gist.github.com/ip6li/9801a5ed958feb7de6136ea175572bdf

sha256sum of current version:
795bbf8b8156ad970b46fb2b40185fd387344e84d22879921133e8c44154f611
ejbca-setup

Improvements and fixes:
* Uses current user for install, except root
* wget replaced by curl
* installs tar, if not available
* Logging config was changed according your recommendations

regards
Christian

Am 02.05.2017 um 12:38 schrieb Tomas Gustavsson:
> Hi Christian,
> 
> I tested the script on CentOS 7. Worked well and was up and running in
> no time
> 
> The things I had to figure out:
> 1. script must be run as user "ejbca". I started running as user "user"
> and it went on until trying to build EJBCA when it failed. Could be
> checked/warned for in the beginning.
> 2. CentOS has curl installed by default I think, so if the script used
> curl, the additional wget package would be needed to install.
> 
> As a side-note, in my default installs I usually don't configure
> log4j-jboss6.xml, I just let wildfly log to server.log as default and
> enable/disable EJBCA debug logging dynamically with:
> 
> /subsystem=logging/logger=org.ejbca:add
> /subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=DEBUG)
> /subsystem=logging/logger=org.cesecore:add
> /subsystem=logging/logger=org.cesecore:write-attribute(name=level,
> value=DEBUG)
> 
> Cheers,
> Tomas

Re: [Ejbca-develop] Script for set up EJBCA on Wildfly 10

[Tomas G. <to...@pr...>]

Hi Christian,

I tested the script on CentOS 7. Worked well and was up and running in
no time

The things I had to figure out:
1. script must be run as user "ejbca". I started running as user "user"
and it went on until trying to build EJBCA when it failed. Could be
checked/warned for in the beginning.
2. CentOS has curl installed by default I think, so if the script used
curl, the additional wget package would be needed to install.

As a side-note, in my default installs I usually don't configure
log4j-jboss6.xml, I just let wildfly log to server.log as default and
enable/disable EJBCA debug logging dynamically with:

/subsystem=logging/logger=org.ejbca:add
/subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=DEBUG)
/subsystem=logging/logger=org.cesecore:add
/subsystem=logging/logger=org.cesecore:write-attribute(name=level,
value=DEBUG)

Cheers,
Tomas

On 2017-04-28 13:11, Christian Felsing wrote:
> Hello,
> 
> hopefully useful if you want to set up EJBCA on Wildfly 10:
> 
> https://gist.github.com/ip6li/9801a5ed958feb7de6136ea175572bdf
> 
> That script assumes an existing database (MariaDB). It installs required
> packages (supports Debian and CentOS versions with systemd) and requests
> Wildfly and EJBCA from their download URLs.
> Creates required config files and does all stuff to get a running EJBCA
> on Wildfly 10.
> Systemd will care about start/stop that.
> 
> Regards
> Christian
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Script for set up EJBCA on Wildfly 10

[Christian F. <pu...@fe...>]

Hello,

hopefully useful if you want to set up EJBCA on Wildfly 10:

https://gist.github.com/ip6li/9801a5ed958feb7de6136ea175572bdf

That script assumes an existing database (MariaDB). It installs required
packages (supports Debian and CentOS versions with systemd) and requests
Wildfly and EJBCA from their download URLs.
Creates required config files and does all stuff to get a running EJBCA
on Wildfly 10.
Systemd will care about start/stop that.

Regards
Christian

[Ejbca-develop] How can I insert a certificate for an extraCert into the database for RA mode?

[Taeyun K. <tae...@in...>]

Hi, 

Sorry if this is a basic question.
(I'm newbie to both CA itself and EJBCA, and I'm in somewhat urgent
situation.)

In the administrator's manual (https://www.ejbca.org/docs/adminguide.html),
there is a paragraph for a PKIMessage verifier named EndEntitySertificate as
follows:

'In RA mode, as a parameter, this module expects the name of the CA that
that has issued the certificate in the extraCert field. If a parameter is
specified, EJBCA will then check if the certificate in extraCert does exist
in the database, that it was issued by the right CA (the CA specified as a
parameter) and that it belongs to a registerd administrator in EJBCA with
the right authorizations to perform the operations required in the request.'

Question:
Here, I don't know the meaning of 'extraCert does exist in the database'.
How can I insert a certificate (that is, extraCert) into the database?

Thank you in advance.
Again, sorry for a basic question.

Re: [Ejbca-develop] Allow to modify the built-in password encryption key?

[Jaime H. E. <hab...@gm...>]

On Fri, Mar 24, 2017 at 9:03 PM, Jaime Hablutzel Egoavil <
hab...@gm...> wrote:

>
>
> On Mar 22, 2017 3:36 AM, "Tomas Gustavsson" <to...@pr...> wrote:
>
>
> Hi,
>
> We don't call it encryption, but obfuscation, since we don't claim the
> purpose is to encrypt data so it can not be recovered.
>
>
> But note that it could provide *real encryption*, at least for the DBA
> role, if the encryption key would be configurable. I say, given that the
> DBA would't have access to the custom encryption key (stored in a property
> file), he would be unable to decrypt auto-activation passwords stored in
> the database, so, even when his has access to soft crypto tokens stored in
> the database he would be unable to use them at all.
>
>
> That said, making it into user configurable encryption is a good idea, I
> agree. Patches would be very welcome.
>
>
> I will try to work on this next time I come back to EJBCA related tasks.
>

I've created a feature request at
https://jira.primekey.se/projects/COMMUNITY/issues/COMMUNITY-65 and it
includes a proposed patch. Please take a look at it and let me know if you
find it appropriate.

Regards.


>
>
> Regards,
> Tomas
>
> On 2017-03-21 18:45, Jaime Hablutzel Egoavil wrote:
> > I'm looking that EJBCA is currently hardcoding the password encryption
> > key in org.cesecore.util.StringTools:
> >
> > ...
> > private static final char[] p =
> > deobfuscate("*OBF:1m0r1kmo1ioe1ia01j8z17y41l0q1abo1abm1abg1a
> be1kyc17ya1j631i5y1ik01kjy1lxf*").toCharArray();
> > ...
> >
> > But, why don't you allow it to be overrided from configuration files?,
> > this way, encrypted auto-activation passwords would be more secure for
> > the ones aware of the possibility to override the default encryption key.
> >
> > Finally and just for reference, take a look at the following similar
> > mechanism (where users are even forced to change the encryption
> > key/password) in a completely different
> > framework, https://www.playframework.com/documentation/2.5.x/Applicatio
> nSecret (the
> > first paragraph suffices).
> >
> >
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
>


-- 
Jaime Hablutzel -  RPC 994690880

[Ejbca-develop] EJBCA Community 6.5.0.5 released

[Tomas G. <to...@pr...>]

Hi,

We are pleased to release EJBCA Community 6.5.0.5.

This release fixes two upgrade bugs, when upgrading from EJBCA 4.0 or
earlier, and backports two other minor fixes. Upgrades from EJBCA 4.0
should now work smoothly.
All in all, there are only 4 fixes in this release.

You can also see a summary of all changes from the last Community
release in the download section.
https://sourceforge.net/projects/ejbca/files/ejbca6/ejbca_6_5_0/

Read the full change log (Changelog.txt) for details, and see the
UPGRADE document for all functionality changes and upgrade instructions.
These are both available in the download package.


Regards,
The EJBCA Team

Re: [Ejbca-develop] Allow to modify the built-in password encryption key?

[Jaime H. E. <hab...@gm...>]

On Mar 22, 2017 3:36 AM, "Tomas Gustavsson" <to...@pr...> wrote:


Hi,

We don't call it encryption, but obfuscation, since we don't claim the
purpose is to encrypt data so it can not be recovered.


But note that it could provide *real encryption*, at least for the DBA
role, if the encryption key would be configurable. I say, given that the
DBA would't have access to the custom encryption key (stored in a property
file), he would be unable to decrypt auto-activation passwords stored in
the database, so, even when his has access to soft crypto tokens stored in
the database he would be unable to use them at all.


That said, making it into user configurable encryption is a good idea, I
agree. Patches would be very welcome.


I will try to work on this next time I come back to EJBCA related tasks.


Regards,
Tomas

On 2017-03-21 18:45, Jaime Hablutzel Egoavil wrote:
> I'm looking that EJBCA is currently hardcoding the password encryption
> key in org.cesecore.util.StringTools:
>
> ...
> private static final char[] p =
> deobfuscate("*OBF:1m0r1kmo1ioe1ia01j8z17y41l0q1abo1abm1abg1a
be1kyc17ya1j631i5y1ik01kjy1lxf*").toCharArray();
> ...
>
> But, why don't you allow it to be overrided from configuration files?,
> this way, encrypted auto-activation passwords would be more secure for
> the ones aware of the possibility to override the default encryption key.
>
> Finally and just for reference, take a look at the following similar
> mechanism (where users are even forced to change the encryption
> key/password) in a completely different
> framework, https://www.playframework.com/documentation/2.5.x/Applicatio
nSecret (the
> first paragraph suffices).
>
>
>
> --
> Jaime Hablutzel -  RPC 994690880
>
>
> ------------------------------------------------------------
------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

Next time I get around this funcionality and code again I will try to
create a patch ;).

On Fri, Mar 24, 2017 at 2:52 AM, Tomas Gustavsson <to...@pr...> wrote:

>
> Ok, I understand your point, it is certainly valid.
>
> If provided with a patch, we would include it.
>
> Regards,
> Tomas
>
> On 2017-03-24 00:35, Jaime Hablutzel Egoavil wrote:
> >
> >
> > On Wed, Mar 22, 2017 at 3:07 AM, Tomas Gustavsson <to...@pr...
> > <mailto:to...@pr...>> wrote:
> >
> >
> >     The comment states that it is for verifying the supplied PIN. I.e.
> that
> >     it works.
> >
> >
> > If I'm just about to set auto-activation for a PKCS #11 crypto token,
> > what is the purpose of verifying the old pin?. It should suffice to ask
> > for the new pin and set auto-activation with that.
> >
> >
> >
> >     What is it exactly that you want to do, and what are your
> expectations
> >     of the process?
> >
> >
> > I just think that the following command should suffice to update a pin
> > and set auto-activation for a PKCS #11 crypto token. No need for
> --oldpin.
> >
> > $ ejbca.sh cryptotoken setpin --token ManagementCA --newpin
> > partitionpassword
> >
> >
> >
> >     /Tomas
> >
> >     On 2017-03-21 18:34, Jaime Hablutzel Egoavil wrote:
> >     >
> >     >
> >     > On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <
> to...@pr... <mailto:to...@pr...>
> >     > <mailto:to...@pr... <mailto:to...@pr...>>> wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     The "--help" text provides this information:
> >     >
> >     >     For soft CryptoTokens the underlying keystore's pin will be
> modified and
> >     >     this requires the current activation PIN.
> >     >
> >     >     So, being a generic command, it will use the "oldpin" to open
> the P12
> >     >     file, and change password to "newpin".
> >     >
> >     >
> >     > Ok, for soft tokens it makes perfect sense: you need the previous
> PIN to
> >     > open the P12 and protect it again, but the code I quoted doesn't
> apply
> >     > for soft tokens, I'm quoting a larger chunk now:
> >     >
> >     > if
> >     >
> >     (*SoftCryptoToken.class.getName().equals(cryptoToken.
> getClass().getName())*)
> >     > {
> >     >     ...
> >     > *} else {*
> >     >     if (oldAutoActivationPin != null) {
> >     >         // If we have an old auto-activation pin we will compare
> the
> >     > "current" with this value to avoid deactivating the token
> >     >         if (!oldAutoActivationPin.equals(new
> >     > String(currentAuthenticationCode))) {
> >     >             final String msg = "Supplied PIN did not match
> >     > auto-activation PIN.";
> >     >             log.info <http://log.info> <http://log.info>(msg);
> >     >             throw new CryptoTokenAuthenticationFaile
> dException(msg);
> >     >         } else {
> >     >             log.debug("Successfully verified the PIN for non-soft
> >     > CryptoToken by comparing supplied PIN to auto-activation PIN.");
> >     >         }
> >     >     } else {
> >     >         *// If we don't have an auto-activation pin to compare the
> >     > supplied PIN to, we need to verify the supplied*
> >     > *        // PIN can be used in a de-activation/activation cycle.*
> >     > *        final boolean wasInactive =
> >     > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
> >     > *        cryptoToken.deactivate();*
> >     > *        cryptoToken.activate(currentAuthenticationCode);*
> >     > *        if (wasInactive) {*
> >     > *            // Note that there is a small glitch here where the
> token
> >     > was active, but we have no other options to verify the pin*
> >     > *            cryptoToken.deactivate();*
> >     > *        }*
> >     >     }
> >     >     if (newAuthenticationCode == null) {
> >     >
> >      cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_
> PROPERTY);
> >     >     } else {
> >     >         BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties,
> new
> >     > String(newAuthenticationCode), true);
> >     >     }
> >     >     cryptoToken.setProperties(cryptoTokenProperties);
> >     > }
> >     >
> >     > The highlighted section is the one that currently applies to PKCS
> #11
> >     > crypto tokens and I just don't understand what is its purpose.
> >     >
> >     >
> >     >     The command just doesn't sense
> >     >     that you are not changing anything, but just giving the same
> PIN.
> >     >
> >     >     Cheers,
> >     >     Tomas
> >     >
> >     >     On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
> >     >     > Let's say I have a PKCS #11 crypto token deactivated and
> having
> >     >     > auto-activation disabled. Now, if I want to activate the
> >     crypto token
> >     >     > and turn on auto-activation using the local CLI I need to
> >     use the
> >     >     > following command:
> >     >     >
> >     >     > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
> >     >     > partitionpassword --newpin partitionpassword
> >     >     >
> >     >     > Where --oldpin is a mandatory parameter, but... why?, given
> >     that the new
> >     >     > PIN should suffice to activate the partition and enable
> >     auto-activation.
> >     >     >
> >     >     > Furthermore, I can see the following code being executed for
> the
> >     >     > previous operation (where currentAuthenticationCode
> >     corresponds to
> >     >     > --oldpin).
> >     >     >
> >     >     > // If we don't have an auto-activation pin to compare the
> >     supplied PIN
> >     >     > to, we need to verify the supplied
> >     >     > // PIN can be used in a de-activation/activation cycle.
> >     >     > final boolean wasInactive =
> >     >     > !isCryptoTokenStatusActive(authenticationToken,
> cryptoTokenId);
> >     >     > cryptoToken.deactivate();
> >     >     > cryptoToken.activate(*currentAuthenticationCode*);
> >     >     > if (wasInactive) {
> >     >     >   // Note that there is a small glitch here where the token
> >     was active,
> >     >     > but we have no other options to verify the pin
> >     >     >   cryptoToken.deactivate();
> >     >     > }
> >     >     >
> >     >     > But I can't figure it out the reason to exercise this
> >     >     > de-activation/activation cycle in the current scenario. Why
> >     would you
> >     >     > want to test the previous or current PIN when you are about
> >     to set a new
> >     >     > one?.
> >     >     >
> >     >     > Can you please provide some explanation on the reason to
> require
> >     >     > --oldpin and what the previous code is doing?
> >     >     >
> >     >     > Note: Previous commands and code snippets apply to EJBCA CE
> >     6.5.0.4.
> >     >     >
> >     >     > --
> >     >     > Jaime Hablutzel -  RPC 994690880
> >     >     >
> >     >     >
> >     >     >
> >     >
> >      ------------------------------------------------------------
> ------------------
> >     >     > Check out the vibrant tech community on one of the world's
> most
> >     >     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > Ejbca-develop mailing list
> >     >     > Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     >     <mailto:Ejb...@li...
> >     <mailto:Ejb...@li...>>
> >     >     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >     >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>>
> >     >     >
> >     >
> >     >     ------------------------------------------------------------
> ------------------
> >     >     Check out the vibrant tech community on one of the world's most
> >     >     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     >     _______________________________________________
> >     >     Ejbca-develop mailing list
> >     >     Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     >     <mailto:Ejb...@li...
> >     <mailto:Ejb...@li...>>
> >     >     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >     >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>>
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     > Jaime Hablutzel -  RPC 994690880
> >     >
> >     >
> >     >
> >     ------------------------------------------------------------
> ------------------
> >     > Check out the vibrant tech community on one of the world's most
> >     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Ejbca-develop mailing list
> >     > Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >     >
> >
> >     ------------------------------------------------------------
> ------------------
> >     Check out the vibrant tech community on one of the world's most
> >     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     _______________________________________________
> >     Ejbca-develop mailing list
> >     Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >
> >
> >
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>



-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Tomas G. <to...@pr...>]

Ok, I understand your point, it is certainly valid.

If provided with a patch, we would include it.

Regards,
Tomas

On 2017-03-24 00:35, Jaime Hablutzel Egoavil wrote:
> 
> 
> On Wed, Mar 22, 2017 at 3:07 AM, Tomas Gustavsson <to...@pr...
> <mailto:to...@pr...>> wrote:
> 
> 
>     The comment states that it is for verifying the supplied PIN. I.e. that
>     it works.
> 
> 
> If I'm just about to set auto-activation for a PKCS #11 crypto token,
> what is the purpose of verifying the old pin?. It should suffice to ask
> for the new pin and set auto-activation with that.
>  
> 
> 
>     What is it exactly that you want to do, and what are your expectations
>     of the process?
> 
> 
> I just think that the following command should suffice to update a pin
> and set auto-activation for a PKCS #11 crypto token. No need for --oldpin.
> 
> $ ejbca.sh cryptotoken setpin --token ManagementCA --newpin
> partitionpassword
>  
> 
> 
>     /Tomas
> 
>     On 2017-03-21 18:34, Jaime Hablutzel Egoavil wrote:
>     >
>     >
>     > On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr... <mailto:to...@pr...>
>     > <mailto:to...@pr... <mailto:to...@pr...>>> wrote:
>     >
>     >     Hi,
>     >
>     >     The "--help" text provides this information:
>     >
>     >     For soft CryptoTokens the underlying keystore's pin will be modified and
>     >     this requires the current activation PIN.
>     >
>     >     So, being a generic command, it will use the "oldpin" to open the P12
>     >     file, and change password to "newpin".
>     >
>     >
>     > Ok, for soft tokens it makes perfect sense: you need the previous PIN to
>     > open the P12 and protect it again, but the code I quoted doesn't apply
>     > for soft tokens, I'm quoting a larger chunk now:
>     >
>     > if
>     >
>     (*SoftCryptoToken.class.getName().equals(cryptoToken.getClass().getName())*)
>     > {
>     >     ...
>     > *} else {*
>     >     if (oldAutoActivationPin != null) {
>     >         // If we have an old auto-activation pin we will compare the
>     > "current" with this value to avoid deactivating the token
>     >         if (!oldAutoActivationPin.equals(new
>     > String(currentAuthenticationCode))) {
>     >             final String msg = "Supplied PIN did not match
>     > auto-activation PIN.";
>     >             log.info <http://log.info> <http://log.info>(msg);
>     >             throw new CryptoTokenAuthenticationFailedException(msg);
>     >         } else {
>     >             log.debug("Successfully verified the PIN for non-soft
>     > CryptoToken by comparing supplied PIN to auto-activation PIN.");
>     >         }
>     >     } else {
>     >         *// If we don't have an auto-activation pin to compare the
>     > supplied PIN to, we need to verify the supplied*
>     > *        // PIN can be used in a de-activation/activation cycle.*
>     > *        final boolean wasInactive =
>     > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
>     > *        cryptoToken.deactivate();*
>     > *        cryptoToken.activate(currentAuthenticationCode);*
>     > *        if (wasInactive) {*
>     > *            // Note that there is a small glitch here where the token
>     > was active, but we have no other options to verify the pin*
>     > *            cryptoToken.deactivate();*
>     > *        }*
>     >     }
>     >     if (newAuthenticationCode == null) {
>     >       
>      cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_PROPERTY);
>     >     } else {
>     >         BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties, new
>     > String(newAuthenticationCode), true);
>     >     }
>     >     cryptoToken.setProperties(cryptoTokenProperties);
>     > }
>     >
>     > The highlighted section is the one that currently applies to PKCS #11
>     > crypto tokens and I just don't understand what is its purpose.
>     >
>     >
>     >     The command just doesn't sense
>     >     that you are not changing anything, but just giving the same PIN.
>     >
>     >     Cheers,
>     >     Tomas
>     >
>     >     On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
>     >     > Let's say I have a PKCS #11 crypto token deactivated and having
>     >     > auto-activation disabled. Now, if I want to activate the
>     crypto token
>     >     > and turn on auto-activation using the local CLI I need to
>     use the
>     >     > following command:
>     >     >
>     >     > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
>     >     > partitionpassword --newpin partitionpassword
>     >     >
>     >     > Where --oldpin is a mandatory parameter, but... why?, given
>     that the new
>     >     > PIN should suffice to activate the partition and enable
>     auto-activation.
>     >     >
>     >     > Furthermore, I can see the following code being executed for the
>     >     > previous operation (where currentAuthenticationCode
>     corresponds to
>     >     > --oldpin).
>     >     >
>     >     > // If we don't have an auto-activation pin to compare the
>     supplied PIN
>     >     > to, we need to verify the supplied
>     >     > // PIN can be used in a de-activation/activation cycle.
>     >     > final boolean wasInactive =
>     >     > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
>     >     > cryptoToken.deactivate();
>     >     > cryptoToken.activate(*currentAuthenticationCode*);
>     >     > if (wasInactive) {
>     >     >   // Note that there is a small glitch here where the token
>     was active,
>     >     > but we have no other options to verify the pin
>     >     >   cryptoToken.deactivate();
>     >     > }
>     >     >
>     >     > But I can't figure it out the reason to exercise this
>     >     > de-activation/activation cycle in the current scenario. Why
>     would you
>     >     > want to test the previous or current PIN when you are about
>     to set a new
>     >     > one?.
>     >     >
>     >     > Can you please provide some explanation on the reason to require
>     >     > --oldpin and what the previous code is doing?
>     >     >
>     >     > Note: Previous commands and code snippets apply to EJBCA CE
>     6.5.0.4.
>     >     >
>     >     > --
>     >     > Jaime Hablutzel -  RPC 994690880
>     >     >
>     >     >
>     >     >
>     >   
>      ------------------------------------------------------------------------------
>     >     > Check out the vibrant tech community on one of the world's most
>     >     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > Ejbca-develop mailing list
>     >     > Ejb...@li...
>     <mailto:Ejb...@li...>
>     >     <mailto:Ejb...@li...
>     <mailto:Ejb...@li...>>
>     >     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>>
>     >     >
>     >
>     >     ------------------------------------------------------------------------------
>     >     Check out the vibrant tech community on one of the world's most
>     >     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     >     _______________________________________________
>     >     Ejbca-develop mailing list
>     >     Ejb...@li...
>     <mailto:Ejb...@li...>
>     >     <mailto:Ejb...@li...
>     <mailto:Ejb...@li...>>
>     >     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>>
>     >
>     >
>     >
>     >
>     > --
>     > Jaime Hablutzel -  RPC 994690880
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Check out the vibrant tech community on one of the world's most
>     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     >
>     >
>     >
>     > _______________________________________________
>     > Ejbca-develop mailing list
>     > Ejb...@li...
>     <mailto:Ejb...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >
> 
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Ejbca-develop mailing list
>     Ejb...@li...
>     <mailto:Ejb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> 
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

On Wed, Mar 22, 2017 at 3:07 AM, Tomas Gustavsson <to...@pr...> wrote:

>
> The comment states that it is for verifying the supplied PIN. I.e. that
> it works.
>

If I'm just about to set auto-activation for a PKCS #11 crypto token, what
is the purpose of verifying the old pin?. It should suffice to ask for the
new pin and set auto-activation with that.


>
> What is it exactly that you want to do, and what are your expectations
> of the process?
>

I just think that the following command should suffice to update a pin and
set auto-activation for a PKCS #11 crypto token. No need for --oldpin.

$ ejbca.sh cryptotoken setpin --token ManagementCA --newpin
partitionpassword


>
> /Tomas
>
> On 2017-03-21 18:34, Jaime Hablutzel Egoavil wrote:
> >
> >
> > On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr...
> > <mailto:to...@pr...>> wrote:
> >
> >     Hi,
> >
> >     The "--help" text provides this information:
> >
> >     For soft CryptoTokens the underlying keystore's pin will be modified
> and
> >     this requires the current activation PIN.
> >
> >     So, being a generic command, it will use the "oldpin" to open the P12
> >     file, and change password to "newpin".
> >
> >
> > Ok, for soft tokens it makes perfect sense: you need the previous PIN to
> > open the P12 and protect it again, but the code I quoted doesn't apply
> > for soft tokens, I'm quoting a larger chunk now:
> >
> > if
> > (*SoftCryptoToken.class.getName().equals(cryptoToken.getClas
> s().getName())*)
> > {
> >     ...
> > *} else {*
> >     if (oldAutoActivationPin != null) {
> >         // If we have an old auto-activation pin we will compare the
> > "current" with this value to avoid deactivating the token
> >         if (!oldAutoActivationPin.equals(new
> > String(currentAuthenticationCode))) {
> >             final String msg = "Supplied PIN did not match
> > auto-activation PIN.";
> >             log.info <http://log.info>(msg);
> >             throw new CryptoTokenAuthenticationFailedException(msg);
> >         } else {
> >             log.debug("Successfully verified the PIN for non-soft
> > CryptoToken by comparing supplied PIN to auto-activation PIN.");
> >         }
> >     } else {
> >         *// If we don't have an auto-activation pin to compare the
> > supplied PIN to, we need to verify the supplied*
> > *        // PIN can be used in a de-activation/activation cycle.*
> > *        final boolean wasInactive =
> > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
> > *        cryptoToken.deactivate();*
> > *        cryptoToken.activate(currentAuthenticationCode);*
> > *        if (wasInactive) {*
> > *            // Note that there is a small glitch here where the token
> > was active, but we have no other options to verify the pin*
> > *            cryptoToken.deactivate();*
> > *        }*
> >     }
> >     if (newAuthenticationCode == null) {
> >         cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_P
> ROPERTY);
> >     } else {
> >         BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties, new
> > String(newAuthenticationCode), true);
> >     }
> >     cryptoToken.setProperties(cryptoTokenProperties);
> > }
> >
> > The highlighted section is the one that currently applies to PKCS #11
> > crypto tokens and I just don't understand what is its purpose.
> >
> >
> >     The command just doesn't sense
> >     that you are not changing anything, but just giving the same PIN.
> >
> >     Cheers,
> >     Tomas
> >
> >     On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
> >     > Let's say I have a PKCS #11 crypto token deactivated and having
> >     > auto-activation disabled. Now, if I want to activate the crypto
> token
> >     > and turn on auto-activation using the local CLI I need to use the
> >     > following command:
> >     >
> >     > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
> >     > partitionpassword --newpin partitionpassword
> >     >
> >     > Where --oldpin is a mandatory parameter, but... why?, given that
> the new
> >     > PIN should suffice to activate the partition and enable
> auto-activation.
> >     >
> >     > Furthermore, I can see the following code being executed for the
> >     > previous operation (where currentAuthenticationCode corresponds to
> >     > --oldpin).
> >     >
> >     > // If we don't have an auto-activation pin to compare the supplied
> PIN
> >     > to, we need to verify the supplied
> >     > // PIN can be used in a de-activation/activation cycle.
> >     > final boolean wasInactive =
> >     > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
> >     > cryptoToken.deactivate();
> >     > cryptoToken.activate(*currentAuthenticationCode*);
> >     > if (wasInactive) {
> >     >   // Note that there is a small glitch here where the token was
> active,
> >     > but we have no other options to verify the pin
> >     >   cryptoToken.deactivate();
> >     > }
> >     >
> >     > But I can't figure it out the reason to exercise this
> >     > de-activation/activation cycle in the current scenario. Why would
> you
> >     > want to test the previous or current PIN when you are about to set
> a new
> >     > one?.
> >     >
> >     > Can you please provide some explanation on the reason to require
> >     > --oldpin and what the previous code is doing?
> >     >
> >     > Note: Previous commands and code snippets apply to EJBCA CE
> 6.5.0.4.
> >     >
> >     > --
> >     > Jaime Hablutzel -  RPC 994690880
> >     >
> >     >
> >     >
> >     -----------------------------------------------------------
> -------------------
> >     > Check out the vibrant tech community on one of the world's most
> >     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Ejbca-develop mailing list
> >     > Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >     >
> >
> >     -----------------------------------------------------------
> -------------------
> >     Check out the vibrant tech community on one of the world's most
> >     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     _______________________________________________
> >     Ejbca-develop mailing list
> >     Ejb...@li...
> >     <mailto:Ejb...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> >
> >
> >
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>



-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] creating multi-domains SSL certificates

[<ad...@dj...>]

Thanks :)

It's working well :)

Regards,

Alain

March 21, 2017 9:01 AM, "Tomas Gustavsson" <to...@pr...> wrote:

> Hi,
> 
> You can add multiple DNS names when editing an End Entity profile. That
> is the recommended way.
> 
> Regards,
> Tomas
> **********
> PrimeKey Solutions AB
> Lundagatan 16, 171 63 Solna, Sweden
> Mob: +46 (0)707421096
> Internet: www.primekey.se
> Twitter: twitter.com/primekeyPKI
> **********
> 
> On 2017-03-20 09:32, ad...@dj... wrote:
> 
>> Hello,
>> 
>> I am discovering EJBCA and CA management. I installed it and it's
>> working well to generate single domain certificate for SSL servers but I
>> am not sure how I could/should generate a certificate for multiple
>> domain like: www.domain.com, mail.domain.com and www.otherdomain.com. I
>> added "DNS Name" in Subject Alternative Name but I am not sure what is
>> the recommended way to do it. Can you give me advices ?
>> 
>> Thanks,
>> 
>> Alain
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> 
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] Allow to modify the built-in password encryption key?

[Tomas G. <to...@pr...>]

Hi,

We don't call it encryption, but obfuscation, since we don't claim the
purpose is to encrypt data so it can not be recovered.

That said, making it into user configurable encryption is a good idea, I
agree. Patches would be very welcome.

Regards,
Tomas

On 2017-03-21 18:45, Jaime Hablutzel Egoavil wrote:
> I'm looking that EJBCA is currently hardcoding the password encryption
> key in org.cesecore.util.StringTools:
> 
> ...
> private static final char[] p =
> deobfuscate("*OBF:1m0r1kmo1ioe1ia01j8z17y41l0q1abo1abm1abg1abe1kyc17ya1j631i5y1ik01kjy1lxf*").toCharArray();
> ...
> 
> But, why don't you allow it to be overrided from configuration files?,
> this way, encrypted auto-activation passwords would be more secure for
> the ones aware of the possibility to override the default encryption key. 
> 
> Finally and just for reference, take a look at the following similar
> mechanism (where users are even forced to change the encryption
> key/password) in a completely different
> framework, https://www.playframework.com/documentation/2.5.x/ApplicationSecret (the
> first paragraph suffices).
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Tomas G. <to...@pr...>]

The comment states that it is for verifying the supplied PIN. I.e. that
it works.

What is it exactly that you want to do, and what are your expectations
of the process?

/Tomas

On 2017-03-21 18:34, Jaime Hablutzel Egoavil wrote:
> 
> 
> On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr...
> <mailto:to...@pr...>> wrote:
> 
>     Hi,
> 
>     The "--help" text provides this information:
> 
>     For soft CryptoTokens the underlying keystore's pin will be modified and
>     this requires the current activation PIN.
> 
>     So, being a generic command, it will use the "oldpin" to open the P12
>     file, and change password to "newpin".
> 
> 
> Ok, for soft tokens it makes perfect sense: you need the previous PIN to
> open the P12 and protect it again, but the code I quoted doesn't apply
> for soft tokens, I'm quoting a larger chunk now:
> 
> if
> (*SoftCryptoToken.class.getName().equals(cryptoToken.getClass().getName())*)
> {
>     ...
> *} else {*
>     if (oldAutoActivationPin != null) {
>         // If we have an old auto-activation pin we will compare the
> "current" with this value to avoid deactivating the token
>         if (!oldAutoActivationPin.equals(new
> String(currentAuthenticationCode))) {
>             final String msg = "Supplied PIN did not match
> auto-activation PIN.";
>             log.info <http://log.info>(msg);
>             throw new CryptoTokenAuthenticationFailedException(msg);
>         } else {
>             log.debug("Successfully verified the PIN for non-soft
> CryptoToken by comparing supplied PIN to auto-activation PIN.");
>         }
>     } else {
>         *// If we don't have an auto-activation pin to compare the
> supplied PIN to, we need to verify the supplied*
> *        // PIN can be used in a de-activation/activation cycle.*
> *        final boolean wasInactive =
> !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
> *        cryptoToken.deactivate();*
> *        cryptoToken.activate(currentAuthenticationCode);*
> *        if (wasInactive) {*
> *            // Note that there is a small glitch here where the token
> was active, but we have no other options to verify the pin*
> *            cryptoToken.deactivate();*
> *        }*
>     }
>     if (newAuthenticationCode == null) {
>         cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_PROPERTY);
>     } else {
>         BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties, new
> String(newAuthenticationCode), true);
>     }
>     cryptoToken.setProperties(cryptoTokenProperties);
> }
> 
> The highlighted section is the one that currently applies to PKCS #11
> crypto tokens and I just don't understand what is its purpose.
>  
> 
>     The command just doesn't sense
>     that you are not changing anything, but just giving the same PIN.
> 
>     Cheers,
>     Tomas
> 
>     On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
>     > Let's say I have a PKCS #11 crypto token deactivated and having
>     > auto-activation disabled. Now, if I want to activate the crypto token
>     > and turn on auto-activation using the local CLI I need to use the
>     > following command:
>     >
>     > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
>     > partitionpassword --newpin partitionpassword
>     >
>     > Where --oldpin is a mandatory parameter, but... why?, given that the new
>     > PIN should suffice to activate the partition and enable auto-activation.
>     >
>     > Furthermore, I can see the following code being executed for the
>     > previous operation (where currentAuthenticationCode corresponds to
>     > --oldpin).
>     >
>     > // If we don't have an auto-activation pin to compare the supplied PIN
>     > to, we need to verify the supplied
>     > // PIN can be used in a de-activation/activation cycle.
>     > final boolean wasInactive =
>     > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
>     > cryptoToken.deactivate();
>     > cryptoToken.activate(*currentAuthenticationCode*);
>     > if (wasInactive) {
>     >   // Note that there is a small glitch here where the token was active,
>     > but we have no other options to verify the pin
>     >   cryptoToken.deactivate();
>     > }
>     >
>     > But I can't figure it out the reason to exercise this
>     > de-activation/activation cycle in the current scenario. Why would you
>     > want to test the previous or current PIN when you are about to set a new
>     > one?.
>     >
>     > Can you please provide some explanation on the reason to require
>     > --oldpin and what the previous code is doing?
>     >
>     > Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.
>     >
>     > --
>     > Jaime Hablutzel -  RPC 994690880
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Check out the vibrant tech community on one of the world's most
>     > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     >
>     >
>     >
>     > _______________________________________________
>     > Ejbca-develop mailing list
>     > Ejb...@li...
>     <mailto:Ejb...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >
> 
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Ejbca-develop mailing list
>     Ejb...@li...
>     <mailto:Ejb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
> 
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Allow to modify the built-in password encryption key?

[Jaime H. E. <hab...@gm...>]

I'm looking that EJBCA is currently hardcoding the password encryption key
in org.cesecore.util.StringTools:

...
private static final char[] p = deobfuscate("
*OBF:1m0r1kmo1ioe1ia01j8z17y41l0q1abo1abm1abg1abe1kyc17ya1j631i5y1ik01kjy1lxf*
").toCharArray();
...

But, why don't you allow it to be overrided from configuration files?, this
way, encrypted auto-activation passwords would be more secure for the ones
aware of the possibility to override the default encryption key.

Finally and just for reference, take a look at the following similar
mechanism (where users are even forced to change the encryption
key/password) in a completely different framework,
https://www.playframework.com/documentation/2.5.x/ApplicationSecret (the
first paragraph suffices).



-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr...>
wrote:

> Hi,
>
> The "--help" text provides this information:
>
> For soft CryptoTokens the underlying keystore's pin will be modified and
> this requires the current activation PIN.
>
> So, being a generic command, it will use the "oldpin" to open the P12
> file, and change password to "newpin".


Ok, for soft tokens it makes perfect sense: you need the previous PIN to
open the P12 and protect it again, but the code I quoted doesn't apply for
soft tokens, I'm quoting a larger chunk now:

if (
*SoftCryptoToken.class.getName().equals(cryptoToken.getClass().getName())*)
{
    ...
*} else {*
    if (oldAutoActivationPin != null) {
        // If we have an old auto-activation pin we will compare the
"current" with this value to avoid deactivating the token
        if (!oldAutoActivationPin.equals(new
String(currentAuthenticationCode))) {
            final String msg = "Supplied PIN did not match auto-activation
PIN.";
            log.info(msg);
            throw new CryptoTokenAuthenticationFailedException(msg);
        } else {
            log.debug("Successfully verified the PIN for non-soft
CryptoToken by comparing supplied PIN to auto-activation PIN.");
        }
    } else {
        *// If we don't have an auto-activation pin to compare the supplied
PIN to, we need to verify the supplied*
*        // PIN can be used in a de-activation/activation cycle.*
*        final boolean wasInactive =
!isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
*        cryptoToken.deactivate();*
*        cryptoToken.activate(currentAuthenticationCode);*
*        if (wasInactive) {*
*            // Note that there is a small glitch here where the token was
active, but we have no other options to verify the pin*
*            cryptoToken.deactivate();*
*        }*
    }
    if (newAuthenticationCode == null) {
        cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_PROPERTY);
    } else {
        BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties, new
String(newAuthenticationCode), true);
    }
    cryptoToken.setProperties(cryptoTokenProperties);
}

The highlighted section is the one that currently applies to PKCS #11
crypto tokens and I just don't understand what is its purpose.


> The command just doesn't sense
> that you are not changing anything, but just giving the same PIN.
>
> Cheers,
> Tomas
>
> On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
> > Let's say I have a PKCS #11 crypto token deactivated and having
> > auto-activation disabled. Now, if I want to activate the crypto token
> > and turn on auto-activation using the local CLI I need to use the
> > following command:
> >
> > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
> > partitionpassword --newpin partitionpassword
> >
> > Where --oldpin is a mandatory parameter, but... why?, given that the new
> > PIN should suffice to activate the partition and enable auto-activation.
> >
> > Furthermore, I can see the following code being executed for the
> > previous operation (where currentAuthenticationCode corresponds to
> > --oldpin).
> >
> > // If we don't have an auto-activation pin to compare the supplied PIN
> > to, we need to verify the supplied
> > // PIN can be used in a de-activation/activation cycle.
> > final boolean wasInactive =
> > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
> > cryptoToken.deactivate();
> > cryptoToken.activate(*currentAuthenticationCode*);
> > if (wasInactive) {
> >   // Note that there is a small glitch here where the token was active,
> > but we have no other options to verify the pin
> >   cryptoToken.deactivate();
> > }
> >
> > But I can't figure it out the reason to exercise this
> > de-activation/activation cycle in the current scenario. Why would you
> > want to test the previous or current PIN when you are about to set a new
> > one?.
> >
> > Can you please provide some explanation on the reason to require
> > --oldpin and what the previous code is doing?
> >
> > Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>



-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Tomas G. <to...@pr...>]

Hi,

The "--help" text provides this information:

For soft CryptoTokens the underlying keystore's pin will be modified and
this requires the current activation PIN.

So, being a generic command, it will use the "oldpin" to open the P12
file, and change password to "newpin". The command just doesn't sense
that you are not changing anything, but just giving the same PIN.

Cheers,
Tomas

On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
> Let's say I have a PKCS #11 crypto token deactivated and having
> auto-activation disabled. Now, if I want to activate the crypto token
> and turn on auto-activation using the local CLI I need to use the
> following command:
> 
> $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
> partitionpassword --newpin partitionpassword
> 
> Where --oldpin is a mandatory parameter, but... why?, given that the new
> PIN should suffice to activate the partition and enable auto-activation. 
> 
> Furthermore, I can see the following code being executed for the
> previous operation (where currentAuthenticationCode corresponds to
> --oldpin).
> 
> // If we don't have an auto-activation pin to compare the supplied PIN
> to, we need to verify the supplied
> // PIN can be used in a de-activation/activation cycle.
> final boolean wasInactive =
> !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
> cryptoToken.deactivate();
> cryptoToken.activate(*currentAuthenticationCode*);
> if (wasInactive) {
>   // Note that there is a small glitch here where the token was active,
> but we have no other options to verify the pin
>   cryptoToken.deactivate();
> }
> 
> But I can't figure it out the reason to exercise this
> de-activation/activation cycle in the current scenario. Why would you
> want to test the previous or current PIN when you are about to set a new
> one?.
> 
> Can you please provide some explanation on the reason to require
> --oldpin and what the previous code is doing?
> 
> Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] creating multi-domains SSL certificates

[Tomas G. <to...@pr...>]

Hi,

You can add multiple DNS names when editing an End Entity profile. That
is the recommended way.

Regards,
Tomas
**********
PrimeKey Solutions AB
Lundagatan 16, 171 63 Solna, Sweden
Mob: +46 (0)707421096
Internet: www.primekey.se
Twitter: twitter.com/primekeyPKI
**********

On 2017-03-20 09:32, ad...@dj... wrote:
> 
> Hello,
> 
> I am discovering EJBCA and CA management. I installed it and it's
> working well to generate single domain certificate for SSL servers but I
> am not sure how I could/should generate a certificate for multiple
> domain like: www.domain.com, mail.domain.com and www.otherdomain.com. I
> added "DNS Name" in Subject Alternative Name but I am not sure what is
> the recommended way to do it. Can you give me advices ?
> 
> Thanks,
> 
> Alain
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

Let's say I have a PKCS #11 crypto token deactivated and having
auto-activation disabled. Now, if I want to activate the crypto token and
turn on auto-activation using the local CLI I need to use the following
command:

$ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
partitionpassword --newpin partitionpassword

Where --oldpin is a mandatory parameter, but... why?, given that the new
PIN should suffice to activate the partition and enable auto-activation.

Furthermore, I can see the following code being executed for the previous
operation (where currentAuthenticationCode corresponds to --oldpin).

// If we don't have an auto-activation pin to compare the supplied PIN to,
we need to verify the supplied
// PIN can be used in a de-activation/activation cycle.
final boolean wasInactive = !isCryptoTokenStatusActive(authenticationToken,
cryptoTokenId);
cryptoToken.deactivate();
cryptoToken.activate(*currentAuthenticationCode*);
if (wasInactive) {
  // Note that there is a small glitch here where the token was active, but
we have no other options to verify the pin
  cryptoToken.deactivate();
}

But I can't figure it out the reason to exercise this
de-activation/activation cycle in the current scenario. Why would you want
to test the previous or current PIN when you are about to set a new one?.

Can you please provide some explanation on the reason to require --oldpin
and what the previous code is doing?

Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.

-- 
Jaime Hablutzel -  RPC 994690880

[Ejbca-develop] creating multi-domains SSL certificates

[<ad...@dj...>]

Hello,

I am discovering EJBCA and CA management. I installed it and it's working well to generate single domain certificate for SSL servers but I am not sure how I could/should generate a certificate for multiple domain like: www.domain.com, mail.domain.com and www.otherdomain.com. I added "DNS Name" in Subject Alternative Name but I am not sure what is the recommended way to do it. Can you give me advices ?

Thanks,

Alain

Re: [Ejbca-develop] API for adding EndEntity programmatically.

[Andreas K. <ku...@tr...>]

Hi Shrikant,

maybe the CMP interface is the right option for your requirement. See
the primekey blog:

http://blog.ejbca.org/2014/03/using-cmp-with-bouncycastle-java-api.html

Greetings,

Andreas
> Anders
>
> It seems I can set the end entity profile name (string) in the UserDataVOWS. And this use UserDataVOWS in EjbcaWS.certificateRequest(). This make me think one has to manually create the end entity profile from EJBCA GUI.
>
> We wanted to avoid that. Instead, we are looking for functionality to programmatically (dynamically using code) create end entity profile.
>
> Thank you and appreciate it.
> Shri
> __________________________________________________
> Shrikant Patel  |  817.367.4302
>
> -----Original Message-----
> From: Anders Rundgren [mailto:and...@gm...]
> Sent: Thursday, March 16, 2017 12:52 AM
> To: ejb...@li...
> Subject: Re: [Ejbca-develop] API for adding EndEntity programmatically.
>
> On 2017-03-15 23:14, Shrikant Patel wrote:
>>     Hi Experts,
>>
>>
>>     From documentation, it seems for every entity\user we need to create the certificate, we need to have End Entity in EJB CA.
>>
>>
>>     From looking at EjbcaWS documentation I don't see API for adding end entity programmatically. Am I missing anything??
> Hi Shri,
>
> This is what you are looking for:
> https://www.ejbca.org/docs/ws/org/ejbca/core/protocol/ws/client/gen/UserDataVOWS.html
>
> Anders
>> Thanks,
>>
>> Shri
>>
>> This e-mail and its contents (to include attachments) are the property of National Health Systems, Inc., its subsidiaries and affiliates, including but not limited to Rx.com Community Healthcare Network, Inc. and its subsidiaries, and may contain confidential and proprietary or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that any unauthorized disclosure, copying, or distribution of this e-mail or of its attachments, or the taking of any unauthorized action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, please immediately notify the sender by telephone at 800-433-5719 or return e-mail and permanently delete the original e-mail.
>>
>>
>> ----------------------------------------------------------------------
>> -------- Check out the vibrant tech community on one of the world's
>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> This e-mail and its contents (to include attachments) are the property of National Health Systems, Inc., its subsidiaries and affiliates, including but not limited to Rx.com Community Healthcare Network, Inc. and its subsidiaries, and may contain confidential and proprietary or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that any unauthorized disclosure, copying, or distribution of this e-mail or of its attachments, or the taking of any unauthorized action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, please immediately notify the sender by telephone at 800-433-5719 or return e-mail and permanently delete the original e-mail.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: ku...@tr...

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales