ejbca-develop — Development discussions

Re: [Ejbca-develop] status GENERATED in case of expired enrollment code

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

Aha interesting. I see no direct issues using failed instead of generated. 

/Tomas 

"Michael Ströder" <mi...@st...> skrev: (21 oktober 2014 17:26:22 CEST)
>HI!
>
>I've set up the "User Password Expire Service" which works and sends
>the user a
>notification about the expired enrollment code.
>
>But it sets the status of the user to GENERATED which triggers another
>e-mail
>notification in my setup informing the user about a cert being
>successfully
>issued to him.
>
>Why not set the user to status FAILED?
>
>Ciao, Michael.
>
>
>
>------------------------------------------------------------------------------
>Comprehensive Server Monitoring with Site24x7.
>Monitor 10 servers for $9/Month.
>Get alerted through email, SMS, voice calls or mobile push
>notifications.
>Take corrective actions from your mobile device.
>http://p.sf.net/sfu/Zoho
>_______________________________________________
>Ejbca-develop mailing list
>Ejb...@li...
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop

[Ejbca-develop] status GENERATED in case of expired enrollment code

[Michael S. <mi...@st...>]

HI!

I've set up the "User Password Expire Service" which works and sends the user a
notification about the expired enrollment code.

But it sets the status of the user to GENERATED which triggers another e-mail
notification in my setup informing the user about a cert being successfully
issued to him.

Why not set the user to status FAILED?

Ciao, Michael.

Re: [Ejbca-develop] ejbca.sh ra addendentity with e-mail notification fails

[Michael S. <mi...@st...>]

On Tue, 21 Oct 2014 14:57:16 +0200 "Michael Ströder" <mi...@st...>
wrote
> what's wrong with the command-line below?
> The end entity profile has various e-mail notifications configured but as you
> can see the e-mail address is set.

Ok, --type 257 did it. But why is that required at all?
The end entity profile already specifys all the stuff (end entity and
notifications).

Ciao, Michael.

> /opt/ejbca_ce_6_2_0/bin/ejbca.sh ra addendentity --username
> 'mi...@st...' --dn 'E=m...@st...,CN=Michael
> Ströder,O=stroeder.com' --caname 'CA_Test-Email-CA-1-2014-10' --token
> USERGENERATED --type 1 --altname 'rfc...@st...'
> --eeprofile EEP_EmailUser --certprofile CP_EmailUser --email
> 'mi...@st...' --password=foo123
> [..]
> Given userdata doesn't fullfill end entity profile. : Email notification is
> required.

[Ejbca-develop] ejbca.sh ra addendentity with e-mail notification fails

[Michael S. <mi...@st...>]

HI!

what's wrong with the command-line below?
The end entity profile has various e-mail notifications configured but as you
can see the e-mail address is set.

BTW:
Any reason why even /opt/ejbca_ce_6_2_0/bin/ejbca.sh ra addendentity --help
takes so much time?

Ciao, Michael.

/opt/ejbca_ce_6_2_0/bin/ejbca.sh ra addendentity --username
'mi...@st...' --dn 'E=m...@st...,CN=Michael
Ströder,O=stroeder.com' --caname 'CA_Test-Email-CA-1-2014-10' --token
USERGENERATED --type 1 --altname 'rfc...@st...' --eeprofile
EEP_EmailUser --certprofile CP_EmailUser --email 'mi...@st...'
--password=foo123
SETTING: --username as mi...@st...
SETTING: --dn as E=m...@st...,CN=Michael Ströder,O=stroeder.com
SETTING: --caname as CA_Test-Email-CA-1-2014-10
SETTING: --token as USERGENERATED
SETTING: --type as 1
SETTING: --altname as rfc...@st...
SETTING: --eeprofile as EEP_EmailUser
SETTING: --certprofile as CP_EmailUser
SETTING: --email as mi...@st...
SETTING: --password as foo123
Using certificate profile: CP_EmailUser, with id: 1588078426
Using entity profile: EEP_EmailUser, with id: 1387345658
Trying to add end entity:
Username: mi...@st...
Password: <password hidden>
DN: E=m...@st...,CN=Michael Ströder,O=stroeder.com
CA Name: CA_Test-Email-CA-1-2014-10
SubjectAltName: rfc...@st...
Email: mi...@st...
Type: 1
Token: USERGENERATED
Certificate profile: 1588078426
End entity profile: 1387345658
Given userdata doesn't fullfill end entity profile. : Email notification is
required.

Re: [Ejbca-develop] How Can I Have a Seperate SubCA

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

I think what you are asking for is described here.
http://ejbca.org/docs/userguide.html

For example:
http://ejbca.org/docs/userguide.html#Administrators%20issued%20by%20external%20CAs

Regards,
Tomas

On 2014-10-20 09:00, eilaf sorkatti wrote:
> Hello All,
>
>
> I'm using EJBCA. I want to know if I want to issue a subCA certificate
> from my RootCA. How can I use this SubCA certificate to issue
> certificates On a seperate PC?
> Is any SubCA that use EJBCA will work with a management-CA on behind?
>
>
>
> Regards,
> --
> Eilaf Hamad Elnil Mugbil
> University Of Khartoum
> School Of Mathematical science
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

[Ejbca-develop] How Can I Have a Seperate SubCA

[eilaf s. <eil...@gm...>]

Hello All,


I'm using EJBCA. I want to know if I want to issue a subCA certificate from
my RootCA. How can I use this SubCA certificate to issue certificates On a
seperate PC?
Is any SubCA that use EJBCA will work with a management-CA on behind?



Regards,
-- 
Eilaf Hamad Elnil Mugbil
University Of Khartoum
School Of Mathematical science

[Ejbca-develop] delegated approval with different sub CAs

[Michael S. <mi...@st...>]

HI!

What access rules do I have to define to allow an admin with cert issued by
Sub-CA-1 with EE profile#1 to approve requests sent in for Sub-CA-2 with EE
profile#2 (acting as RA admin)?

It seems I have correctly created the right admin role RA admin.
But allowing only access to Sub-CA-2 and EE profile#2 does not work:

12:21:40,077 INFO  [org.ejbca.core.ejb.approval.ApprovalSessionBean]
(http--0.0.0.0-8443-2) Error sending approval notification with id 1319887432.:
org.cesecore.authorization.AuthorizationDeniedException: Administrator not
authorized to CA -312685585 that existing user mstroeder was created with.
Admin: UID=mstroeder,SN=1234567,OU=PKI RA Admin,O=OrgName.

If I allow access to Sub-CA-1 *and* EE profile#1 (the admin account was created
with) everything works.

But that's *not* what I want!

Fiddling with view rights on Sub-CA-1 in the advanced access rules did not work
either.

BTW: Tested with 6.2.0 and SVN revision 20006

Ciao, Michael.

Re: [Ejbca-develop] PDF signatures in LibreOffice

[Andreas B. <ab...@an...>]

Am 16.10.2014 um 14:45 schrieb Branko Majic:

> Hm... Might be a good fit for the SignServer mailing list, actually .

Feel free to forward, as I'm not subscribed to this list.


cheers, h.

-- 

Andreas Bürki

ab...@an...
S/MIME certificate - SHA1 fingerprint:
ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11
GnuPG - GPG fingerprint:
5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227

Re: [Ejbca-develop] web.selfreg.certtypes.1.usernamemapping with e-mail address

[Samuel L. B. <sa...@pr...>]

Hi,

That's a bug (and it's my code!). I've created an issue for it:

https://jira.primekey.se/browse/ECA-3859


Regards,
Samuel



Den 2014-10-16 14:47, Michael Ströder skrev:
> HI!
> 
> I'm experimenting with the self-reg feature which works so far.
> And I'm successfully using CN and UID as attributes to map the username for
> some end entity profiles.
> 
> But I wonder what's the correct value for
> web.selfreg.certtypes.1.usernamemapping for using the e-mail address as
> username. I've tried the values "E", "emailAddress", "email" without sucess..
> Yes, I've added the e-mail address to the subject DN attributes in the cert
> profile which leads to certs with a cert DN like this:
> 
> E=m...@st...,CN=Michael Ströder,O=Test Company
> 
> BTW:
> 
> The order of the attributes in the end entity profile form is:
> - CN, Common name
> - emailAddress, E-mail address in DN
> - O, Organization
> 
> Why do CN and E get re-ordered?
> 
> Ciao, Michael.
> 
> 
> 
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] PDF signatures in LibreOffice

[Branko M. <br...@ma...>]

On Wed, 15 Oct 2014 13:18:12 +0200
Andreas Bürki <ab...@an...> wrote:

> Hi all
> 
> Maybe you don't know yet: Fundraising for PDF signatures in LibreOffice
> 
> http://wilhelmtux.ch/index.phtml?MID=11&CID=93&PID=93
> 
> Please, spread the word to find the last few bucks missing
> 
> 
> cheeeers, h.
> 
> 
> 

Hm... Might be a good fit for the SignServer mailing list, actually .

Best regards

-- 
Branko Majic
Jabber: br...@ma...
Please use only Free formats when sending attachments to me.

Бранко Мајић
Џабер: br...@ma...
Молим вас да додатке шаљете искључиво у слободним форматима.

Re: [Ejbca-develop] Separate trust store for SMTP/STARTTLS

[Branko M. <br...@ma...>]

On Wed, 15 Oct 2014 12:23:40 +0200
"Michael Ströder" <mi...@st...> wrote:

> HI!
> 
> Is it possible to configure a separate trust store for out-going SMTP/STARTTLS
> connections?
> 
> Ciao, Michael.
> 

One thing to emphasize - for outgoing connections the JBoss does _not_
use the truststore.jks deployed by the EJBCA build scripts, but instead
relies on the Java system truststore (some file under jvm/blah/blah).

So, you'd need to dictate via some Java property when running JBoss
what truststore to use for outgoing connections.

Of course, not sure if you can set this truststore separately for
different connections, but at least you should be able to limit the CAs
you trust for those (by default you'll trust a whole lot of them).

Best regards

-- 
Branko Majic
Jabber: br...@ma...
Please use only Free formats when sending attachments to me.

Бранко Мајић
Џабер: br...@ma...
Молим вас да додатке шаљете искључиво у слободним форматима.

[Ejbca-develop] web.selfreg.certtypes.1.usernamemapping with e-mail address

[Michael S. <mi...@st...>]

HI!

I'm experimenting with the self-reg feature which works so far.
And I'm successfully using CN and UID as attributes to map the username for
some end entity profiles.

But I wonder what's the correct value for
web.selfreg.certtypes.1.usernamemapping for using the e-mail address as
username. I've tried the values "E", "emailAddress", "email" without sucess..
Yes, I've added the e-mail address to the subject DN attributes in the cert
profile which leads to certs with a cert DN like this:

E=m...@st...,CN=Michael Ströder,O=Test Company

BTW:

The order of the attributes in the end entity profile form is:
- CN, Common name
- emailAddress, E-mail address in DN
- O, Organization

Why do CN and E get re-ordered?

Ciao, Michael.

Re: [Ejbca-develop] LDAP DN order is wrong

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> Of course EJBCA is not caring about the string representation of DNs,

Not true! (not meant as offense)

If you accept an input field or config file value with a DN (like EJBCA does
in various places) you're definitely in the business of dealing with string
representation of DNs!

Let's pick an example from your docs:

http://www.ejbca.org/docs/userguide.html#Name%20Constraints

C=SE,O=Company
    Matches against the beginning of the Subject DN. The certificates must
    not use LDAP DN order, which is enabled by default!

Can you see the confusion introduced?

> Anyhow, to summarize your suggestion it is to "uncheck" the checkbox by 
> default, and remove the option.

Yepp.

> Providing only one possible asn.1 
> encoding, which in your view is the correct one?

You simply have to preserve the RDNSequence order in whatever data structure
you keep or convert the DN at a given time. ;-)

Ciao, Michael.

Re: [Ejbca-develop] LDAP DN order is wrong

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

Hi,

Of course EJBCA is not caring about the string representation of DNs, 
but is only in the business of creating asn.1 encoded certificates. As 
such we provide the option of different encodings. There are so many 
client applications out there, and a lot of them do not process 
correctly (in fact you need to be an expert like you to do that :-)).

Anyhow, to summarize your suggestion it is to "uncheck" the checkbox by 
default, and remove the option. Providing only one possible asn.1 
encoding, which in your view is the correct one?

Is that a correct assumption?

(I think there exists an issue to change the default value of that option)

Cheers,
Tomas

On 2014-10-15 17:57, Michael Ströder wrote:
> Tomas Gustavsson wrote:
>>
>> On 2014-10-15 10:21, Michael Ströder wrote:
>>> Tomas Gustavsson wrote:
>>>>
>>>> What do you mean it is wrong?
>>>
>>> If you enable "LDAP DN order" the order is actually reversed. When displaying
>>> the certs with OpenSSL subject and issuer are *not* LDAP DN order. Please
>>> check yourself with
>>>
>>> openssl x509 -nameopt rfc2253
>>>                ^^^^^^^^^^^^^^^^
>>
>> This option does not print the "actual" asn.1 order. -nameopt rfc2253
>> converts the string into something specified, but not the actual order.
>
> RFC 4514 (which obsoletes RFC 2253) clears says:
>
>     "the output consists of the string encodings of each
>     RelativeDistinguishedName in the RDNSequence (according to Section
>     2.2), starting with the last element of the sequence and moving
>     backwards toward the first."
>
> http://tools.ietf.org/html/rfc4514#section-2.1
>
> (Note also the following section about *unordered* multi-valued RDNs!)
>
> This means the conversion is already well-defined for the RDNSequence and LDAP
> string representations of DNs are always from left-to-right to be interpreted
> as bottom-up in the Directory Information Tree (similar to concantenation of
> DNS labels to FQDNs).
>
> And: There is no difference in X.500 and LDAP "name order" because simply
> X.500 strings are not defined at all.
>
>> You can see the actual order (which is printed when not using -nameopt) by:
>> openssl asn1parse
>
> In PKIX the sequence Name is specified as RDNSequence here:
>
> http://tools.ietf.org/html/rfc5280#section-4.1.2.4
>
> So you're right that the RDNSequence in a X.509 certificate is to be
> interpreted from first-to-last as top-down in the Directory Information Tree
> (I'm too lazy to dig out a reference for the usual X.521 naming with C to CN
> etc.).
> But RFC 4514 clearly defines how to convert this into the correct DN string
> representation. Note that I'm deliberately using "first-to-last" for the
> RDNSequence items instead of left-to-right here.
>
>>> (If you don't use this -nameopt value you get some obscure OpenSSL internal
>>> string representation which is definitely *not* LDAP DN order although in
>>> recent versions separated by comma.)
>>>
>>> I'd suggest to completely drop this flawed configuration option.
>>
>> It is not flawed because it affects the actual order of the DN in the
>> generated asn.1 This is vital to be able to do this to be compatible
>> with different implementation of how x.509 certificates are used.
>> The name could be be better describing though.
>
> The configuration option is seriously flawed just because of its existence.
> Can you clearly define a real use-case?
> Which real-world problem is solved by this without introducing another issue?
>
> IMHO this option is strongly contributing to all the misunderstandings about
> DN order and DN string representations.
>
> My strong recommendation:
> If you're dealing with string representation in a user interface or
> configuration file etc. then consistently treat every DN or DN regex pattern
> etc. according to RFC 4514.
> (Bear in mind you loose UTF8String vs. PrintableString information though.)
>
> Believe me: I'm really using a lot of complicated cert-subject-DN to LDAP-DN
> identity mappings in real-world productive configs. Consistently using RFC4514
> makes things clear, everything else leads to big mess.
>
> Of course you have to correctly use the BouncyCastle or OpenSSL API to convert
> the string representation to the correct ordering in the X.509 cert when
> generating certs and vice versa.
>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] Upstream fixes

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

You can of course use the code in the public svn according to the open source license. Go ahead. 

Support for developer salaries are of course always welcome. 

Cheers, 
Tomas 

"Michael Ströder" <mi...@st...> skrev: (15 oktober 2014 17:59:48 CEST)
>Tomas Gustavsson wrote:
>> 
>> The current working is that patch releases is only Enterprise (it
>does cost
>> resources). Main releases will be Community and everything goes into
>future
>> main releases of course.
>
>Are all fixes in the public SVN repo?
>
>And do I need a Enterprise license if I use a more recent SVN snapshot
>or
>back-ported fixes?
>
>Ciao, Michael.

[Ejbca-develop] Upstream fixes

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> 
> The current working is that patch releases is only Enterprise (it does cost
> resources). Main releases will be Community and everything goes into future
> main releases of course.

Are all fixes in the public SVN repo?

And do I need a Enterprise license if I use a more recent SVN snapshot or
back-ported fixes?

Ciao, Michael.

Re: [Ejbca-develop] LDAP DN order is wrong

[Michael S. <mi...@st...>]

Tomas Gustavsson wrote:
> 
> On 2014-10-15 10:21, Michael Ströder wrote:
>> Tomas Gustavsson wrote:
>>>
>>> What do you mean it is wrong?
>>
>> If you enable "LDAP DN order" the order is actually reversed. When displaying
>> the certs with OpenSSL subject and issuer are *not* LDAP DN order. Please
>> check yourself with
>>
>> openssl x509 -nameopt rfc2253
>>               ^^^^^^^^^^^^^^^^
> 
> This option does not print the "actual" asn.1 order. -nameopt rfc2253 
> converts the string into something specified, but not the actual order.

RFC 4514 (which obsoletes RFC 2253) clears says:

   "the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to Section
   2.2), starting with the last element of the sequence and moving
   backwards toward the first."

http://tools.ietf.org/html/rfc4514#section-2.1

(Note also the following section about *unordered* multi-valued RDNs!)

This means the conversion is already well-defined for the RDNSequence and LDAP
string representations of DNs are always from left-to-right to be interpreted
as bottom-up in the Directory Information Tree (similar to concantenation of
DNS labels to FQDNs).

And: There is no difference in X.500 and LDAP "name order" because simply
X.500 strings are not defined at all.

> You can see the actual order (which is printed when not using -nameopt) by:
> openssl asn1parse

In PKIX the sequence Name is specified as RDNSequence here:

http://tools.ietf.org/html/rfc5280#section-4.1.2.4

So you're right that the RDNSequence in a X.509 certificate is to be
interpreted from first-to-last as top-down in the Directory Information Tree
(I'm too lazy to dig out a reference for the usual X.521 naming with C to CN
etc.).
But RFC 4514 clearly defines how to convert this into the correct DN string
representation. Note that I'm deliberately using "first-to-last" for the
RDNSequence items instead of left-to-right here.

>> (If you don't use this -nameopt value you get some obscure OpenSSL internal
>> string representation which is definitely *not* LDAP DN order although in
>> recent versions separated by comma.)
>>
>> I'd suggest to completely drop this flawed configuration option.
> 
> It is not flawed because it affects the actual order of the DN in the 
> generated asn.1 This is vital to be able to do this to be compatible 
> with different implementation of how x.509 certificates are used.
> The name could be be better describing though.

The configuration option is seriously flawed just because of its existence.
Can you clearly define a real use-case?
Which real-world problem is solved by this without introducing another issue?

IMHO this option is strongly contributing to all the misunderstandings about
DN order and DN string representations.

My strong recommendation:
If you're dealing with string representation in a user interface or
configuration file etc. then consistently treat every DN or DN regex pattern
etc. according to RFC 4514.
(Bear in mind you loose UTF8String vs. PrintableString information though.)

Believe me: I'm really using a lot of complicated cert-subject-DN to LDAP-DN
identity mappings in real-world productive configs. Consistently using RFC4514
makes things clear, everything else leads to big mess.

Of course you have to correctly use the BouncyCastle or OpenSSL API to convert
the string representation to the correct ordering in the X.509 cert when
generating certs and vice versa.

Ciao, Michael.

Re: [Ejbca-develop] LDAP DN order is wrong

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

I created an issue to improve the documentation/naming of this option.

https://jira.primekey.se/browse/ECA-3856

Cheers,
Tomas

On 2014-10-15 15:52, Tomas Gustavsson wrote:
>
> On 2014-10-15 10:21, Michael Ströder wrote:
>> Tomas Gustavsson wrote:
>>>
>>> What do you mean it is wrong?
>>
>> If you enable "LDAP DN order" the order is actually reversed. When displaying
>> the certs with OpenSSL subject and issuer are *not* LDAP DN order. Please
>> check yourself with
>>
>> openssl x509 -nameopt rfc2253
>>                ^^^^^^^^^^^^^^^^
>
> This option does not print the "actual" asn.1 order. -nameopt rfc2253
> converts the string into something specified, but not the actual order.
> You can see the actual order (which is printed when not using -nameopt) by:
> openssl asn1parse
>
>> (If you don't use this -nameopt value you get some obscure OpenSSL internal
>> string representation which is definitely *not* LDAP DN order although in
>> recent versions separated by comma.)
>>
>> I'd suggest to completely drop this flawed configuration option.
>
> It is not flawed because it affects the actual order of the DN in the
> generated asn.1 This is vital to be able to do this to be compatible
> with different implementation of how x.509 certificates are used.
> The name could be be better describing though.
>
>>
>>> Can you suggest some new help text?
>>
>> 1. There is no such thing as a X.500 DN string representation. The only
>> well-defined string representation for distinguished names is RFC 4514
>> (formerly RFC 2253) which defines what you call "LDAP DN order".
>> BTW: Obviously the ASN.1 string type gets lost with this representation.
>>
>> => IMO if generating strings of DNs this RFC 4514 representation should be
>> *always* used
>
> I do not agree on this. String representations of DNs are a tru mess,
> one of the biggest misstakes. Using RFC definition will usually result
> in non-understandable OIDs for many of the DN components. And the
> printed representation still will differ between different
> implementation (i.e. openssl vs bouncy castle etc).
> There simply is no good string representation.
>
>>
>> 2. And this help text is plain wrong:
>>
>> "In theory the order of the DN should not matter, because comparisons between
>> DNs should be done on the RDN level."
>>
>> It is confusing and in contradiction to
>>
>> http://tools.ietf.org/html/rfc5280#section-7.1
>>
>>      [..] Two distinguished names DN1 and DN2 match if they
>>      have the same number of RDNs, for each RDN in DN1 there is a matching
>>      RDN in DN2, and the matching RDNs appear in the same order in both
>>      DNs.
>>
>> Note the words "same order" herein.
>
> Thanks.
>
>>
>> Also in some protocols DN matching is even done by strictly comparing the DER
>> encoding of the DNs to avoid having to deal with compability issues of the
>> different ASN.1 string types.
>
> This is the only way to be sure.
>
>>
>> Ciao, Michael.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] LDAP DN order is wrong

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

On 2014-10-15 10:21, Michael Ströder wrote:
> Tomas Gustavsson wrote:
>>
>> What do you mean it is wrong?
>
> If you enable "LDAP DN order" the order is actually reversed. When displaying
> the certs with OpenSSL subject and issuer are *not* LDAP DN order. Please
> check yourself with
>
> openssl x509 -nameopt rfc2253
>               ^^^^^^^^^^^^^^^^

This option does not print the "actual" asn.1 order. -nameopt rfc2253 
converts the string into something specified, but not the actual order. 
You can see the actual order (which is printed when not using -nameopt) by:
openssl asn1parse

> (If you don't use this -nameopt value you get some obscure OpenSSL internal
> string representation which is definitely *not* LDAP DN order although in
> recent versions separated by comma.)
>
> I'd suggest to completely drop this flawed configuration option.

It is not flawed because it affects the actual order of the DN in the 
generated asn.1 This is vital to be able to do this to be compatible 
with different implementation of how x.509 certificates are used.
The name could be be better describing though.

>
>> Can you suggest some new help text?
>
> 1. There is no such thing as a X.500 DN string representation. The only
> well-defined string representation for distinguished names is RFC 4514
> (formerly RFC 2253) which defines what you call "LDAP DN order".
> BTW: Obviously the ASN.1 string type gets lost with this representation.
>
> => IMO if generating strings of DNs this RFC 4514 representation should be
> *always* used

I do not agree on this. String representations of DNs are a tru mess, 
one of the biggest misstakes. Using RFC definition will usually result 
in non-understandable OIDs for many of the DN components. And the 
printed representation still will differ between different 
implementation (i.e. openssl vs bouncy castle etc).
There simply is no good string representation.

>
> 2. And this help text is plain wrong:
>
> "In theory the order of the DN should not matter, because comparisons between
> DNs should be done on the RDN level."
>
> It is confusing and in contradiction to
>
> http://tools.ietf.org/html/rfc5280#section-7.1
>
>     [..] Two distinguished names DN1 and DN2 match if they
>     have the same number of RDNs, for each RDN in DN1 there is a matching
>     RDN in DN2, and the matching RDNs appear in the same order in both
>     DNs.
>
> Note the words "same order" herein.

Thanks.

>
> Also in some protocols DN matching is even done by strictly comparing the DER
> encoding of the DNs to avoid having to deal with compability issues of the
> different ASN.1 string types.

This is the only way to be sure.

>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] Ticket policy for security issues

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

Hi Michael,

Currently the policy is to not reveal details of the issue. Since 
upgrades of this type of software is typically slower uptake than in 
most softwares.

Cheers,
Tomas

On 2014-10-15 13:44, Michael Ströder wrote:
> HI!
>
> I can understand that tickets regarding security issues are only visible to
> certain users before they get fixed.
>
> But what happens *after* a fix was released?
> What is the EJBCA project's policy?
>
> I'm asking because I was wondering about a CLOSED security issue ticket still
> not being visible:
>
> https://jira.primekey.se/browse/ECA-3615
>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] Separate trust store for SMTP/STARTTLS

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

Hi,

In mail.properties it is not. But the EJBCA configuration just reflects 
into a JBoss mmail service configuration. In other means you will be 
able to configure JBoss any way it is possible. I do not know the 
details you are asking for though, but it should be possible to find in 
JBoss documentation/forums.

Cheers,
Tomas

On 2014-10-15 12:23, Michael Ströder wrote:
> HI!
>
> Is it possible to configure a separate trust store for out-going SMTP/STARTTLS
> connections?
>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

[Ejbca-develop] PDF signatures in LibreOffice

[Andreas B. <ab...@an...>]

Hi all

Maybe you don't know yet: Fundraising for PDF signatures in LibreOffice

http://wilhelmtux.ch/index.phtml?MID=11&CID=93&PID=93

Please, spread the word to find the last few bucks missing


cheeeers, h.



-- 

Andreas Bürki

ab...@an...
S/MIME certificate - SHA1 fingerprint:
ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11
GnuPG - GPG fingerprint:
5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227

[Ejbca-develop] Ticket policy for security issues

[Michael S. <mi...@st...>]

HI!

I can understand that tickets regarding security issues are only visible to
certain users before they get fixed.

But what happens *after* a fix was released?
What is the EJBCA project's policy?

I'm asking because I was wondering about a CLOSED security issue ticket still
not being visible:

https://jira.primekey.se/browse/ECA-3615

Ciao, Michael.

[Ejbca-develop] Separate trust store for SMTP/STARTTLS

[Michael S. <mi...@st...>]

HI!

Is it possible to configure a separate trust store for out-going SMTP/STARTTLS
connections?

Ciao, Michael.

[Ejbca-develop] EndEntity - extra information

[John M. <joh...@gm...>]

Hello,

This is a re-post in hopes someone can give a solution.

I am using the External RA service (
http://www.ejbca.org/docs/externalra.html).

I want to add extra information for an end entity, like social security
number or other private information that should not appear on the
certificates issued for the entity.

The problem is that the *EditUserRequest*(long requestId, String username,
String subjectDN, String subjectAltName, String email, String
subjectDirectoryAttributes, String endEntityProfileName, String
certificateProfileName, String cAName, String password, int status, int
type, String tokenname, String hardtokenissuername) doesn't have a field to
set the extended information. When inspecting the code for the
*EditUserRequestProcessor
-> MessageProcessr:*

   protected EndEntityInformation
>> generateEndEntityInformation(AuthenticationToken admin, ExtRARequest
>> submessage) throws ClassCastException, EjbcaException,
>> CADoesntExistsException, AuthorizationDeniedException {
>
>         String dirAttributes = submessage.getSubjectDirectoryAttributes();
>
>         ExtendedInformation ext = null;
>
>         if (dirAttributes != null) {
>
>             ext = new ExtendedInformation();
>
>             ext.setSubjectDirectoryAttributes(dirAttributes);
>
>         }
>
>            return  new EndEntityInformation(submessage.getUsername(),
>
>                    submessage.getSubjectDN(),
>
>                    getCAId(admin,submessage.getCAName()),
>
>                    submessage.getSubjectAltName(),
>
>                    submessage.getEmail(),
>
>                    EndEntityConstants.STATUS_INPROCESS,
>
>                    new EndEntityType(EndEntityTypes.ENDUSER),
>
>                    getEndEntityProfileId(admin,
>> submessage.getEndEntityProfileName()),
>
>
>>  getCertificateProfileId(submessage.getCertificateProfileName()),
>
>                    null,
>
>                    null,
>
>                    SecConst.TOKEN_SOFT_BROWSERGEN,
>
>                    0,
>
>                    ext);
>
>     }
>
>
As you can see only the subjectDirAttributes are added to the
extendedinformation.
Is there a way to save the information on the ejbca database ?

The solution I am working on right now, is to create another table on the
RA database, where the Message table is located, where I put extra
information for the UserData table in the EJBCA databasse.