multiple Common Name fields

Hello!

I wrote about week ago about my problem with multiple common
name fields. I
tryied to make cert with two domains in CN like it is
written on vhosttask
force. No body answered???
The problem in that when i want to make cert with couple CN
it makes it as
subjectaltname filed which i don't want...
Please is there any way to do it or not....

thanks
-- 
best regards,
 Bartosz Giza

_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Hi!

>> I wrote about week ago about my problem with
multiple common name
>> fields. I tryied to make cert with two domains in
CN like it is
>> written on vhosttask force. No body answered??? The
problem in that
>> when i want to make cert with couple CN it makes it
as
>> subjectaltname filed which i don't want... Please
is there any way
>> to do it or not....
>>
>> thanks
> Hey, Bartosz.

> As far as I know the use of SubjectAltName is exactly
what the guide
> tells you will happen.
> I don't think there is a way to get around that, apart
from using one
> ip for each vhost.

I don't know that you know what i meant. I need to have
couple hosts in CN
field like it is written at this link:

http://wiki.cacert.org/w
iki/VhostTaskForce#head-661e90855b6b4285bbab272390bf7bbd639e
d5d9

It said that it is second way of doing this. I didn't find
anything about
that it will be changed to the subjectaltname.

My email client do not accept certs with subjectaltname, but
when i have
generated my own CA cert and when i have signed my MTA cert
with multiple CN
fields it works like a charm. And i actully have those hosts
in CN field.
They are not converted to the subjectaltname.
So my question cacert support that or not ?
And what is better standard for doing this. I am usig The
Bat as email
client and i can't forde this client to accept certs with
subjectaltname
fields which turns that i can't log on to my server.
I want to use cacert certs but right now i am forced to use
my own certs
because of that :(


--
Best regards,
 Bartosz Giza

_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Hi Bartosz,

> My email client do not accept certs with
subjectaltname, but when i have
> generated my own CA cert and when i have signed my MTA
cert with multiple
> CN fields it works like a charm. And i actully have
those hosts in CN
> field. They are not converted to the subjectaltname.

Yes, CAcert decided to convert multiple CNs to
SubjectAltNames automatically 
back then, since that was the best supported way.
Unfortunately, you have a specific application that indeed
does need multiple 
CN´s now, which doesn´t work with the current CAcert system.

> So my question cacert support that or not ?

I have it on our wishlist to implement support for multiple
CN´s.
Unfortunately that makes everything even a little more
complex than it is 
already, so it will take some time to realize this.


> And what is better standard for doing this.

The best solution is to use SNI, but that´s not support
everywhere yet.

> I am usig The Bat as email 
> client and i can't forde this client to accept certs
with subjectaltname
> fields which turns that i can't log on to my server.

Ok, I´ll talk to the developers of TheBat! to find a
solution with them.

> I want to use cacert certs but right now i am forced to
use my own certs
> because of that :(

Yes, I am sorry about that. Unfortunately CAcert already
grew quite large, so 
some things that look easy from outside are a lot of work to
be realized 
internally. If you know a PHP developer that would like to
help develop it, 
feel free to contact me about it.

Best regards,
Philipp Gühring

_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Philipp Gühring wrote:

> Yes, CAcert decided to convert multiple CNs to
SubjectAltNames automatically 
> back then, since that was the best supported way.
> Unfortunately, you have a specific application that
indeed does need multiple 
> CN´s now, which doesn´t work with the current CAcert
system.

Multiple CNs aren't valid in certificates based on RFCs, the
"correct"
way to do it is subjectAltNames, as these depreciated CNs
altogether,
rather then making "broken" certificates perhaps
contacting the vendor
of the application and getting them to support standards
would be a
better idea.

-- 

Best regards,
 Duane

http://www.cacert.org -
Free Security Certificates
http://www.nodedb.com -
Think globally, network locally
http://www.sydneywirele
ss.com - Telecommunications Freedom
http://e164.org - Because
e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Hi Duane!

Duane schrieb:
> Multiple CNs aren't valid in certificates based on
RFCs, the "correct"
> way to do it is subjectAltNames, as these depreciated
CNs altogether,
> rather then making "broken" certificates
perhaps contacting the vendor
> of the application and getting them to support
standards would be a
> better idea.

Yes, I want to stress, that this is what I think as well.
Using multiple
CNs will result both to become part of the SAME subject.
E.g. somethink
like the following:

C=AU, ST=Some-State, O=Internet Ltd, CN=example.com,
CN=example.net

Semantically this would mean "example.net" is part
of "example.com"
which is part of "Internet Ltd" which is part of
(is in) "Some-State"
which is part of (false subset) "AU".

AFAIK using two CNs in the same subject isn't supported by
all Clients
anyway. E.g. IMHO Firefox or Thunderbird won't accept this
subject.

I don't think that CAcert.org should support such
RFC-ignorant subjects.
It's better to use software, that follows the RFCs and uses
a
subjectAltName.


Tot kijk
    Matthias


-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

>>>>> "mw" == Matthias Wimmer
<mtthias.eu> writes:

    mw> I don't think that CAcert.org should support such
RFC-ignorant
    mw> subjects.  It's better to use software, that
follows the RFCs
    mw> and uses a subjectAltName.

1. the wiki says that the browsers don't follow the RFC
either.  I
   think we are trying to follow the browsers, not any of
the many
   RFCs that claim authority.

2. do the RFC's we're discussing really cover all SSL
including POP3
   and SMTP-relay as well as web browsing?  I suspect they
are HTTP
   only?

FWIW I would agree that the automangling is a little bit
excessive.
If you would like to avoid issuing a certificate that
experience shows
will not work, that makes sense to me, to return an error
and refuse
to issue.  But issuing certificates that don't match the
requests,
presumably to avoid questions on this list from people who
haven't
read the wiki by ``knowing better'' and trying to fix the
admin's
mistakes without him noticing, seems risky.  I would even
say it is a
cryptographic weakness of the certificate request protocol
we are
stuck with---ex., GPG will not trust any uid that is not
self-signed,
no matter how many other people sign it.  Under that model
it would be
impossible to mangle certificate requests like this because
it would
invalidate the hypothetical self-signature.

especially when no one documented the mangling rules or
remembers
exactly what they are.  I also had a problem with what seems
to be
broken mangling---subjectAltName is repeated and includes
components
that openssl can't parse.  Definitely shouldn't do mangling
if it's
going to break for requests that are actually ``correct'' to
start
with:


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6406 (0x1906)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=CAcert Inc., OU=http://www.CAcert.org,
CN=CAcert Class 3 Root
        Validity
            Not Before: Nov  8 04:47:47 2006 GMT
            Not After : Nov  7 04:47:47 2008 GMT
        Subject: CN=castrovalva.Ivy.NET
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                   
00:a4:ea:cf:6e:f9:ba:81:ee:ae:e4:7b:53:39:a0:
                   
21:a2:11:b3:b7:09:e4:ca:57:48:f7:ee:c2:69:da:
                   
24:dc:49:cc:47:85:89:f4:11:b3:15:1b:4b:fa:0a:
                   
78:44:88:89:b6:47:70:76:3d:20:a9:bb:9d:35:6a:
                   
49:bf:95:7c:55:dc:d7:4f:f6:07:37:19:09:19:b5:
                   
00:88:a4:82:b1:2e:9c:94:c2:f1:65:12:ba:1a:20:
                   
7b:82:08:d9:ea:f8:7e:63:49:48:42:07:d7:c8:7c:
                   
78:d9:75:b2:c7:82:7b:89:3c:00:ce:8a:05:75:8f:
                   
6c:28:45:8d:32:4c:16:69:20:45:6e:e6:bf:a8:62:
                   
36:a1:55:17:13:ce:56:95:e5:e2:ae:b2:e1:45:47:
                   
51:75:c7:1b:0e:8f:7a:75:d7:18:77:50:38:86:ac:
                   
c4:67:b4:ae:a4:6c:b5:de:d3:b0:61:52:c9:cd:87:
                   
08:1b:cd:ef:3a:c3:eb:9c:a1:d8:ec:74:aa:e5:aa:
                   
f2:87:ef:b5:7a:28:d8:18:e0:5e:b7:86:a7:70:3b:
                   
02:4b:05:c9:90:1b:9c:20:e2:9e:37:75:95:08:d4:
                   
02:df:45:1b:a1:61:9b:c2:10:77:af:e0:35:e8:3b:
                   
d3:7e:29:21:76:1b:fa:63:4a:96:f2:fc:a5:60:b9:
                    e0:b1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web
Server Authentication, Netscape Server Gated Crypto,
Microsoft Server Gated Crypto
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            Authority Information Access: 
                OCSP - URI:http://ocsp.cacert.org

            X509v3 Subject Alternative Name: 
                DNS:castrovalva.Ivy.NET,
othername:<unsupported>, DNS:castrovalva.Ivy.NET,
othername:<unsupported>

_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Miles Nordin wrote:

> 1. the wiki says that the browsers don't follow the RFC
either.  I
>    think we are trying to follow the browsers, not any
of the many
>    RFCs that claim authority.

There are very few browsers that don't support
subjectAltNames (mostly
ones that aren't maintained like lynx)...

> 2. do the RFC's we're discussing really cover all SSL
including POP3
>    and SMTP-relay as well as web browsing?  I suspect
they are HTTP
>    only?

The RFCs cover the information embedded in X.509v3
certificates and how
it is to be used by client software, regardless of the
protocol used,
and the RFCs in question clearly state that CN fields have
been made
obsolete and subectAltNames should *ONLY* be used.

> But issuing certificates that don't match the requests,
> presumably to avoid questions on this list from people
who haven't
> read the wiki by ``knowing better'' and trying to fix
the admin's
> mistakes without him noticing, seems risky.

To my knowledge this is the only time this issue has been
posted to this
list.

> I also had a problem with what seems to be
> broken mangling---subjectAltName is repeated and
includes components
> that openssl can't parse.

Just because openssl doesn't have human readable names for
OIDs, doesn't
invalidate them, they are covered by RFCs that utilise the
XMPP protocol.

> Definitely shouldn't do mangling if it's
> going to break for requests that are actually
``correct'' to start
> with:

But they aren't correct, we are mangling things into the
correct format,
without standards every man and his dog comes up with
something
different and we're left trying to issue certificates for 50
million
things, we must re-write subjects for certificates because
otherwise
they are ripe for people insert any information they like
and being a
potential security risk for CAcert.

To further this issue there was talk on mozilla lists about
rejecting
applications for inclusion into their root list for CAs that
issue
certificates if they include any CN records.

-- 

Best regards,
 Duane

http://www.cacert.org -
Free Security Certificates
http://www.nodedb.com -
Think globally, network locally
http://www.sydneywirele
ss.com - Telecommunications Freedom
http://e164.org - Because
e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Miles Nordin schrieb:
>             X509v3 Subject Alternative Name: 
>                 DNS:castrovalva.Ivy.NET,
othername:<unsupported>, DNS:castrovalva.Ivy.NET,
othername:<unsupported>

The othername:<unsupported> entries here should be an
id-on-xmppAddr.
OpenSSL cannot display these entries, but software using
OpenSSL to
access certificates can access these id-on-xmppAddr values
very well.

Therefore OpenSSL can parse id-on-xmppAddr very well, it
just has no
strings to display them.


Tot kijk
    Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

>>>>> "d" == Duane  <duanecacert.org> writes:

     d> There are very few browsers that don't support
subjectAltNames
     d> (mostly ones that aren't maintained like lynx)...

so we agree on point #1, we mostly want to follow the
browsers, not
necessarily the RFC.

     d> To my knowledge this is the only time this issue
has been
     d> posted to this list.

Are you saying you need to hear it from more than one person
before
looking into it more carefully?  It seems like you can just
have a
look at the cert I was issued and see for yourself.  Either
you can
explain it or you can't.  No need to suggest I'm crazy
because I'm one
person. 

     d> Just because openssl doesn't have human readable
names for
     d> OIDs, doesn't invalidate them, they are covered
by RFCs that
     d> utilise the XMPP protocol.

Right, so I have only one hostname in my request.  And I put
the one
hostname as one subjectAltName in my request.  but I have
FOUR
subjectAltNames in the issued cert.

so.. assuming for the sake of argument that XMPP somehow
goes into
subjectAltName as an unparseable, duplicated component
(seems odd), I
still wonder, why is the DNS:castrovalva.Ivy.NET
subjectAltName
repeated twice?  That seems wrong to me, but maybe I'm
missing
something?

    >> Definitely shouldn't do mangling if it's going
to break for
    >> requests that are actually ``correct'' to start
with:

     d> But they aren't correct,

I should clarify though---I'm talking about my particular
certificate
request, which included a subjectAltName in the request and
was, as
far as I can tell from your documentation, correct, because
I read the
conflicting information on the Wiki carefully.  I'm saying,
if you are
going to mangle certificates for requests you feel are
incorrect, we
can't all agree on that.  But I think we can all agree that
the
mangling shouldn't _require_ your request to be in some
common
incorrect format, and mess up when you submit an actual
correct
request like I did.

In my admittedly inexperienced opinion, you should document
how to
make correct requests rather than mangling certs, but we
disagree
there.  We would probably both agree that we should fix the
Wiki if
there is not enough documentation for a careful person to
submit a
request that you call ``correct.''  I'm willing to try to
translate
mailinglist+RFC into documentation for the wiki, but I can't
do it yet
because I can't infer what the mangling rules are based on
what I've
learned so far.  I don't understand the subjectAltName that
OpenSSL
can't parse, nor why the DNS:castrovalva.Ivy.NET
subjectAltName is
repeated twice.
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support