Does a root CA need two certificates?

[Joel]

Had another newbie type question --

When reading about how to set up a self-signed web server, the docs I
read indicate there is a need for two certificates -- one being a
self-signed certificate for the entity certifying the server, and the
other being the certificate the web server gives out (certified by the
self-signed certificate).

Reading the RFCs and the docs, it seems like CAs would similarly have
the certificate(s?) they operate under and the certificate they give out.
And it looks like a root CA does not give out its self-signed
certificate. (Or does it? I'm not sure where in RFC 3280 I got this idea.
The paragraph I'm reading now about pathLenConstraint makes it look like
the root CA does give out his self-signed certificate when he gives one
out -- talking about the count of non-self-signed certificates.)

Does setting up a root CA require generating a self-signed certificate,
and then generating an operating certificate signed under the
self-signed certificate, or am I thinking too hard and as confused as
usual?

--
Joel Rees <rees-fctGxyACD9F3+***@public.gmane.org>
digitcom, inc. $B3t<02q<R%G%8%3%`(B
Kobe, Japan [phone]
** <http://www.ddcom.co.jp> **

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Bernhard Froehlich]

Post by Joel
Had another newbie type question --
When reading about how to set up a self-signed web server, the docs I
read indicate there is a need for two certificates -- one being a
self-signed certificate for the entity certifying the server, and the
other being the certificate the web server gives out (certified by the
self-signed certificate).
Reading the RFCs and the docs, it seems like CAs would similarly have
the certificate(s?) they operate under and the certificate they give out.
And it looks like a root CA does not give out its self-signed
certificate. (Or does it? I'm not sure where in RFC 3280 I got this idea.
The paragraph I'm reading now about pathLenConstraint makes it look like
the root CA does give out his self-signed certificate when he gives one
out -- talking about the count of non-self-signed certificates.)
Does setting up a root CA require generating a self-signed certificate,
and then generating an operating certificate signed under the
self-signed certificate, or am I thinking too hard and as confused as
usual?

I think it may be possible to use a self-signed (or root) certificate
for a web server but it does not make much sense.
If you want to build up a CA (for Inhouse use in a company for example)
you should use the CA's key ONLY to sign certificates.
If you just want to play around with SSL it's better to simulate the
usual approach, especially since this only costs you the call of another
script.
Using a self-signed CA in an Internet-environment is almost senseless
since this leaves you open to man-in-the-middle attacks. And most people
who can listen to the wire can also redirect requests.

Hope it helps,
Ted
;)

[R. Markham]

Hi Ted,

using a self signed certificate doesn't mean your connection is less secure.
It is only people are going to use your web pages because they get a warning
that the certificate is not certified b a CA. But with openssl you can use
the same routine to generate your certificate like a CA.

Regards

Richard

-----Ursprüngliche Nachricht-----
Von: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] Im Auftrag von Bernhard Froehlich
Gesendet: Mittwoch, 19. Januar 2005 09:23
An: openssl-users-MCmKBN63+***@public.gmane.org
Betreff: Re: Does a root CA need two certificates?

Post by Joel
Had another newbie type question --
When reading about how to set up a self-signed web server, the docs I
read indicate there is a need for two certificates -- one being a
self-signed certificate for the entity certifying the server, and the
other being the certificate the web server gives out (certified by the
self-signed certificate).
Reading the RFCs and the docs, it seems like CAs would similarly have
the certificate(s?) they operate under and the certificate they give out.
And it looks like a root CA does not give out its self-signed
certificate. (Or does it? I'm not sure where in RFC 3280 I got this idea.
The paragraph I'm reading now about pathLenConstraint makes it look like
the root CA does give out his self-signed certificate when he gives one
out -- talking about the count of non-self-signed certificates.)
Does setting up a root CA require generating a self-signed certificate,
and then generating an operating certificate signed under the
self-signed certificate, or am I thinking too hard and as confused as
usual?

I think it may be possible to use a self-signed (or root) certificate
for a web server but it does not make much sense.
If you want to build up a CA (for Inhouse use in a company for example)
you should use the CA's key ONLY to sign certificates.
If you just want to play around with SSL it's better to simulate the
usual approach, especially since this only costs you the call of another
script.
Using a self-signed CA in an Internet-environment is almost senseless
since this leaves you open to man-in-the-middle attacks. And most people
who can listen to the wire can also redirect requests.

Hope it helps,
Ted
;)
--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Alok]

But how do you guarantee that the web server is "who he says he is"?
Iin theory, an ISP could, hack up a DNS to point to my local server. What
verifies that the machine I am connecting to is indeed that machine which it
claims to be?

----- Original Message -----
From: "R. Markham" <markham.r-***@public.gmane.org>
To: <openssl-users-MCmKBN63+***@public.gmane.org>
Sent: Wednesday, January 19, 2005 1:54 AM
Subject: AW: Does a root CA need two certificates?


Hi Ted,

using a self signed certificate doesn't mean your connection is less secure.
It is only people are going to use your web pages because they get a warning
that the certificate is not certified b a CA. But with openssl you can use
the same routine to generate your certificate like a CA.

Regards

Richard

-----Ursprüngliche Nachricht-----
Von: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] Im Auftrag von Bernhard Froehlich
Gesendet: Mittwoch, 19. Januar 2005 09:23
An: openssl-users-MCmKBN63+***@public.gmane.org
Betreff: Re: Does a root CA need two certificates?

Post by Joel
Had another newbie type question --
When reading about how to set up a self-signed web server, the docs I
read indicate there is a need for two certificates -- one being a
self-signed certificate for the entity certifying the server, and the
other being the certificate the web server gives out (certified by the
self-signed certificate).
Reading the RFCs and the docs, it seems like CAs would similarly have
the certificate(s?) they operate under and the certificate they give out.
And it looks like a root CA does not give out its self-signed
certificate. (Or does it? I'm not sure where in RFC 3280 I got this idea.
The paragraph I'm reading now about pathLenConstraint makes it look like
the root CA does give out his self-signed certificate when he gives one
out -- talking about the count of non-self-signed certificates.)
Does setting up a root CA require generating a self-signed certificate,
and then generating an operating certificate signed under the
self-signed certificate, or am I thinking too hard and as confused as
usual?

I think it may be possible to use a self-signed (or root) certificate
for a web server but it does not make much sense.
If you want to build up a CA (for Inhouse use in a company for example)
you should use the CA's key ONLY to sign certificates.
If you just want to play around with SSL it's better to simulate the
usual approach, especially since this only costs you the call of another
script.
Using a self-signed CA in an Internet-environment is almost senseless
since this leaves you open to man-in-the-middle attacks. And most people
who can listen to the wire can also redirect requests.

Hope it helps,
Ted
;)
--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Bernhard Froehlich]

Post by R. Markham
Hi Ted,
using a self signed certificate doesn't mean your connection is less secure.
It is only people are going to use your web pages because they get a warning
that the certificate is not certified b a CA. But with openssl you can use
the same routine to generate your certificate like a CA.
Regards
Richard

Yes, I do think (no, this time I'm really sure) it is less secure! If
you use a self signed CA in an internet setting (that is, you do not
know your users and your users typically don't know you) there is no way
für the user to be sure that s/he is talking with your website and not
with a Man-In-The-Middle proxy, since everyone can generate a self
signed certificate with the name of your site in it. And someone who can
listen to the wire (like an internet provider) usually can hijack or
redirect a connection to his own site.

It's a completely different story if your users know you and can check
the CA's fingerprint using another channel, like personal contact,
papermail or a secure Website using a trusted certificate.

You are right in the one aspect that the encryption itself is equally
strong, regardless of what certificate you use. But the best encryption
does not help you if you send its key to an untrusted target.
Using self signed certificates to make a typical internet user believe
his communication is more secure is a classical case of selling "snake oil".

Ted
;)

[R. Markham]

The data is no less secure true.. but the authentication is much easier
for someone to fake since the certificate chain doesn't go through a
trusted third party (Root CA) the person says "This is me. End of story"
and you choose whether you believe it or not.

Hi Shaun,

I don't understand why is a root CA which everybody can download from the
internet is more secure than if I use my own CA. I want to make it clear I
am not against using Certificates from an official CA. But in some cases you
can save your money as a expenses for the certificate if you use your self
signed certificate. If you want that only authenticated user can have
access, than you can use SSLVerifyClient in Apache.


Regards

Richard






______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Alok]

Hi Richard,

How else do you authenticate the "originator of the certificate"

I dont know if you really want to read it up but I found the concept in:
http://theory.lcs.mit.edu/~cis/pubs/rivest/rsapaper.ps

an explaination to the same.
It tells you why an assymetric keypair like RSA is used/needed to sign the
certificates.
One of the keys is probably what the browser has and the other is the key
used to sign the webserver's digital cert generated from the csr.


-hth
Alok


----- Original Message -----
From: "R. Markham" <markham.r-***@public.gmane.org>
To: <openssl-users-MCmKBN63+***@public.gmane.org>
Sent: Wednesday, January 19, 2005 3:28 AM
Subject: AW: Does a root CA need two certificates?

Post by R. Markham

The data is no less secure true.. but the authentication is much easier
for someone to fake since the certificate chain doesn't go through a
trusted third party (Root CA) the person says "This is me. End of story"
and you choose whether you believe it or not.

Hi Shaun,
I don't understand why is a root CA which everybody can download from the
internet is more secure than if I use my own CA. I want to make it clear I
am not against using Certificates from an official CA. But in some cases you
can save your money as a expenses for the certificate if you use your self
signed certificate. If you want that only authenticated user can have
access, than you can use SSLVerifyClient in Apache.
Regards
Richard
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Shaun Lipscombe]

Post by R. Markham
I don't understand why is a root CA which everybody can download from the
internet is more secure than if I use my own CA. I want to make it clear I
am not against using Certificates from an official CA. But in some cases you
can save your money as a expenses for the certificate if you use your self
signed certificate. If you want that only authenticated user can have
access, than you can use SSLVerifyClient in Apache.

I made the same mistake as this. Assuming that an authenticated client
is authorised. This gave me a headache since I couldn't work out why
it's secure since anyone could obtain a signed client certificate from
a root CA and if that root CA is in the list of CA's on my webserver
they can get access. However now I understand it. The root CA doesn't
grant a certificate saying "this person is allowed access to your
website" but "this person is WHO THEY SAY THEY ARE". This means it's
still up to you to decide what they should be allowed to access (their
authorization). You've just used a different way of identifying them..
a certificate instead of a username & password.

SSLCheckClientDN and SSLFakeBasicAuth allow for authenticated access in
Apache NOT SSLVerifyClient. SSLVerifyClient just makes sure they have a
valid client certificate.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Bernhard Froehlich]

Post by R. Markham

The data is no less secure true.. but the authentication is much easier
for someone to fake since the certificate chain doesn't go through a
trusted third party (Root CA) the person says "This is me. End of story"
and you choose whether you believe it or not.

Hi Shaun,
I don't understand why is a root CA which everybody can download from the
internet is more secure than if I use my own CA.

The trick is not that everyone can download it, the trick is that
(hopefully) no evil one can modify it. So Bill Gates certifies (by
including the CA-certs on his distribution CDs or digitaly signing the
new Certs for distribution via Windows Update) that those CA-certs are
good CA-certs (I personally disagree sometimes, but that's another story).
If you download a CA-bundle from somewhere else you should make sure
that the source ist trustworthy and noone has modified it, typically by
checking a digital signature or using a secure download.
Of course there are several possibilities to get your fingers in between
in this procedure, but if you just give me a certificate and say "this
is mine" I have no assurance that I'm receiving what you sent.

Post by R. Markham
I want to make it clear I am not against using Certificates from an official CA. But in some cases you
can save your money as a expenses for the certificate if you use your self
signed certificate. If you want that only authenticated user can have
access, than you can use SSLVerifyClient in Apache.

You are completely right. There are lots of cases where you can use a
self signed CA even more secure that those "official" ones. But internet
applications (in the sense of "my clients have nothing else to do with
me") usually are not among them.
It alway depends on having a "secure" (or "a bit more secure than
unauthenticated internet") channel to distribute the CA-certificates.
And of course the trust in the CAs themselves.

Post by R. Markham
Regards
Richard
[...]

BTW, there is no offense intended by my side, I'm just trying to clarify
this. ;)
Ted

[Joel]

(BFrom a newb who has way too much theory and too little practical --

Post by R. Markham

The data is no less secure true.. but the authentication is much easier
for someone to fake since the certificate chain doesn't go through a
trusted third party (Root CA) the person says "This is me. End of story"
and you choose whether you believe it or not.

Hi Shaun,
I don't understand why is a root CA which everybody can download from the
internet is more secure than if I use my own CA.

Well, the way I understand it is, verisign, the company (for example),
has not come out and said, "NO! Don't trust our certificates!!!", and
neither have a lot of other people. So we can assume their certificates
our theirs, even though we can't assume they are who they publically
claim to be.

The trust on the second question is an induced trust in our heads. Since
nobody is standing up to claim that the management of any of these
companies are fraudulent in the claims they make as to who they say they
are, the induced trust takes more effect. But that sort of trust is
outside of PKI.

Post by R. Markham
I want to make it clear I
am not against using Certificates from an official CA. But in some cases you
can save your money as a expenses for the certificate if you use your self
signed certificate. If you want that only authenticated user can have
access, than you can use SSLVerifyClient in Apache.

Well, yeah, if your head of engineering stands up in the morning meeting
and claims he signed the company's internal root CA certificate himself,
that is actually better than if he sent it off to one of the commercial
(or open) CAs, because the external chain of trust is more direct.

Also, that group in Australia that's doing peer-to-peer certification
has an approach that I think is theoretically valid in a different way
and in a different context, because it's a chain of face-to-face trust.
I haven't got a certificate from them yet, but I want to see how well
they implement things.

First I have to make sure I really understand what's going on with
openssl and the more hierarchical approach.

--
Joel Rees <rees-fctGxyACD9F3+***@public.gmane.org>
digitcom, inc. $B3t<02q<R%G%8%3%`(B
Kobe, Japan [phone]
** <http://www.ddcom.co.jp> **

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Richard Levitte - VMS Whacker]

In message <20050119114725.GB17730-987bfp+7ej6qI+E0KzgamFpr/1R2p/***@public.gmane.org> on Wed, 19 Jan 2005 11:47:25 +0000, Shaun Lipscombe <shaun.lipscombe-8Ra8l+***@public.gmane.org> said:

shaun.lipscombe> At least with SSL you have a single entity at the top,
shaun.lipscombe> in OpenPGP etc you have a "web of trust" and "key
shaun.lipscombe> signing parties" and lots of other stuff which really
shaun.lipscombe> makes key validity a touch n go subject and people
shaun.lipscombe> being who they say they are gets a bit of an iffy
shaun.lipscombe> subject.

OK, time to call bullshit whan I see it :-)

OpenPGP has a different trust model than X.509/PKIX, it's entirely
true. Making that something inherently bad is what I call BS.

The trust model for OpenPGP is direct, personal validation of
identity. I won't sign another person's PGP key unless I either know
this person personally, or can validate his/her identity through some
kind of identity paper, for example a passport together with a
business card where his/her email address is clearly shown together
with the same name as on the passport. The validation chain is a
chain of such checkups, basically, coupled with trust settings (they
can be viewed as policy settings are viewed in the X.509/PKIX world).

The trust model for X.509/PKIX is to trust a higher authority, but can
also be set up as a personal web of trust if you set up your own CA
and use policy extensions properly.

shaun.lipscombe> Just search any keyserver for "Superman" and I'm sure
shaun.lipscombe> you'll find someone that claims to be Superman for
shaun.lipscombe> example.

Claims it in what way? You mean as part of the real name or as part
of the email address? Either way, what stops anyone claiming the same
in the X.509/PKIX world? That's not the point either way, the point
is if you trust the claim, or if you trust someone who would trust
that claim. That kind of trust can be handled, both in the OpenPGP
world and the X.509/PKIX one.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte richard-***@public.gmane.org
http://richard.levitte.org/

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Mark H. Wood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[snip]

Post by Richard Levitte - VMS Whacker
shaun.lipscombe> Just search any keyserver for "Superman" and I'm sure
shaun.lipscombe> you'll find someone that claims to be Superman for
shaun.lipscombe> example.
Claims it in what way? You mean as part of the real name or as part
of the email address? Either way, what stops anyone claiming the same
in the X.509/PKIX world? That's not the point either way, the point
is if you trust the claim, or if you trust someone who would trust
that claim. That kind of trust can be handled, both in the OpenPGP
world and the X.509/PKIX one.

"Claims it in what way?" is in fact an extremely important question. I
have little doubt that someone could find a judge willing to allow him to
change his legal name to "Superman". After that it would say "Superman"
on his business cards, bank accounts, utility bills, etc. and it would be
reasonable to say that "that person's name is Superman," or, "here, let me
give you a copy of Superman's email certificate."

None of that says anything about whether the individual in question is the
comic-book hero, able to fly, crush charcoal into diamonds in his hand,
reflect bullets with his unprotected flesh, a native of Krypton, etc.
It's necessary to think about what "his name is Superman" means, and
whether that meaning is of any use in determining the kind of identity you
want to prove. The same is true of X.509 or OpenPGP certificates, or
really any other identifier. It's always necessary to decide what it is
you want to know, before accepting something as identification.

- --
Mark H. Wood, Lead System Programmer mwood-ZBTkGdjEb46HXe+***@public.gmane.org
Open-source executable: $0.00. Source: $0.00 Control: priceless!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFB7qOps/NR4JuTKG8RAhbbAJ9qLXT7lvUg9/OyzIkeCkqHoa+PsACgiPGc
C1TKEFXfny4Pqvg6mkBr01Y=
=rFTN
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Joel]

Sorry, I wasn't clear in my question. (I'm confused, I know.)

(And thanks for trying to help a confused newb. ;-)

On Wed, 19 Jan 2005 16:27:10 +0900

Post by Joel
Had another newbie type question --
When reading about how to set up a self-signed web server, the docs I
read indicate there is a need for two certificates -- one being a
self-signed certificate for the entity certifying the server, and the
other being the certificate the web server gives out (certified by the
self-signed certificate).

That was from when I was playing with mod_ssl and apache. Got it working,
more or less, and, no, I did not use the self-signed certificate for
mod_ssl, I used the certificate signed with the self-signed certificate.

Post by Joel
Reading the RFCs and the docs, it seems like CAs would similarly have
the certificate(s?) they operate under and the certificate they give out.
And it looks like a root CA does not give out its self-signed
certificate. (Or does it? I'm not sure where in RFC 3280 I got this idea.
The paragraph I'm reading now about pathLenConstraint makes it look like
the root CA does give out his self-signed certificate when he gives one
out -- talking about the count of non-self-signed certificates.)
Does setting up a root CA require generating a self-signed certificate,
and then generating an operating certificate signed under the
self-signed certificate, or am I thinking too hard and as confused as
usual?

This is for an internal application, in which it really doesn't make
sense to have an externally trusted entity sign the CA certificate. We
aren't asking our customers to trust our self-signed certificate, we are
just trying to make sure the person who handed us the floppy with the
certificate is on the other end of the line, so to speak.

(You could say our man in the middle is always "known" to be a "trusted"
employee, in the sense that PKI allows us to talk about mechanized trust.
8-/ )

What I'm trying to ask, if I can get it right this time, is whether a
root CA will be passing its own self-signed certificate out.

I think I've figured it out, by the way. In the case of the web server,
the self-signed certificate is not intended for certifying the web site,
but for certifying the certificate(s) of (a) web site(s), which is why
two are necessary.

But in the case of a CA, the certificate is for signing certificates for
other CAs and won't be given out otherwise. But it would be given out
with the signed certificates for the subordinate CAs.

But if the root CA machine is also signing server certificates (which it
should not, but that's another story), it should have a separate
certificate for signing certificates for servers. Should also have a
separate piece of the directory tree to do it in.

Am I getting warm?

--
Joel Rees <rees-fctGxyACD9F3+***@public.gmane.org>
digitcom, inc. $B3t<02q<R%G%8%3%`(B
Kobe, Japan [phone]
** <http://www.ddcom.co.jp> **

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Bernhard Froehlich]

Post by Joel
Sorry, I wasn't clear in my question. (I'm confused, I know.)
(And thanks for trying to help a confused newb. ;-)
[...]
What I'm trying to ask, if I can get it right this time, is whether a
root CA will be passing its own self-signed certificate out.

Ahh, now I think we get nearer to the mark. ;)
Yes, the root CA has to distribute its self signed certificate (NOT its
private key, just the cert. There seem to be misunderstandings about
that elsewhere) to those who have to trust it. For example if your
employees have to make sure they are on a company website you have to
give them a disk (this is the secure channel here) containing the CA's
certificate and they have to import it into their browsers.

N.B.: Just make sure that your CA certificate is not used to sign fake
certificates, since if your employees trust your CA this also implies
(at least with current browser implementations) that they trust every
certificate signed by your CA, even if you hand out certificates for
www.bigbank.com or www.ebay.com...

Post by Joel
I think I've figured it out, by the way. In the case of the web server,
the self-signed certificate is not intended for certifying the web site,
but for certifying the certificate(s) of (a) web site(s), which is why
two are necessary.

Yes, that sounds correct.

Post by Joel
But in the case of a CA, the certificate is for signing certificates for
other CAs and won't be given out otherwise. But it would be given out
with the signed certificates for the subordinate CAs.
But if the root CA machine is also signing server certificates (which it
should not, but that's another story), it should have a separate
certificate for signing certificates for servers. Should also have a
separate piece of the directory tree to do it in.

Though a CA can sign other CAs and thereby build longer CA-chains it is
more common in Inhouse-CAs to directly sign end-user (or "end-server")
certificates. And as explained above the self signed certificate of the
root CA has to be distributed.

The approach described by you is a more secure but less practical way.
You typically do this if you are Thawte or Verisign and your root
certificate has to have a very late expiery date, like 25 years from
now. Then it is better to keep the root CA's private(!) keys very very
secure in a bank vault and only use it once a year to sign certificates
for some sub-CAs, which expire in a year or so and are then used to sign
end-user certificates. Now if one of the sub-CAs compromises its private
key, only the certificates singed by this particular sub-CA are void,
and not possibly those of ten or twenty years of work.
But still the root CA's certificate (which apart from management
information primarily contains its signed public(!) key part) has to be
distributed, in the case of Thawte etc. to Bill, the Mozilla project and
people like that.

Post by Joel
Am I getting warm?

I think you are already rather close.

Ted
;)

[Richard Levitte - VMS Whacker]

Joel,

you seem to be a bit confused about PKI matters, and among others
what's considered private and what's considered public.

Let me start with the private vs. public part: private keys are
designed to be kept private by the owner. Certificates (which contain
the public key) are designed to be public and to be given out to
anyone who needs it or is interested.

Also, a small detail: CA certificates aren't used to sign with, the
private keys are. You use CA certificates to validate a signature in
any certificate issued by that CA (this puts it simply, since there
are other data that are checked between certificates, but the
signature check is still the most important thing).

Now, the way things work with a X.509/PKIX flavor of PKI, you validate
a certificate (any kind of certificate, be it a user certificate, a
server certificate or whatever kind of certificate we're able to
invent) by checking it against an issuing cerificate (a CA
certificate), among others by checking that the signature in the
current certificate can be verified using the public key in the
issuing certificate. This is done all the way to the top (the root
certificate).

To be able to do a proper certificate validation, you therefore need
all the certificates in the chain, from the certificate you want to
validate to the root certificate that starts (or ends, depending on
your point of view) the chain. This holds true for anyone who needs
to validate your server certificate as well as any certificate your
server needs to validate.

So, to directly answer your questions:

rees> What I'm trying to ask, if I can get it right this time, is
rees> whether a root CA will be passing its own self-signed
rees> certificate out.

Yes, in one form or another.

rees> I think I've figured it out, by the way. In the case of the web
rees> server, the self-signed certificate is not intended for
rees> certifying the web site, but for certifying the certificate(s)
rees> of (a) web site(s), which is why two are necessary.

That's correct. Those aren't two CA certificates, though. The root
certificate is the CA certificate, while the server certificate is a
EE (End Entity) certificate. You confused the matter for yourself
earlier by talking about "two CA certificates".

rees> But in the case of a CA, the certificate is for signing
rees> certificates for other CAs and won't be given out otherwise. But
rees> it would be given out with the signed certificates for the
rees> subordinate CAs.

This is confusing. Either you're publishing a certificate or you
aren't. It doesn't matter if it's bundled with subordinate
certificates or not. And either way, if you want others to be able to
validate a certificate issued by the subordinate CAs, you need to
publish the root CA certificate as well.

rees> But if the root CA machine is also signing server certificates
rees> (which it should not, but that's another story), it should have
rees> a separate certificate for signing certificates for servers.
rees> Should also have a separate piece of the directory tree to do it
rees> in.

You are confusing the matter. It seems like you're saying the CA
should split in two, one that signs subordinate CAs and one that signs
your server certificate. Now, the question is, when you split that CA
in two, are you actually creating an entirely different CA that uses
the same key, or are you in fact creating another subordinate CA
(using the same key?)?

You might want to draw a tree that shows how the root CA, subordinate
CAs and other entities are related to each other. A picture does say
more than a thousand words, and I've already spent a few hundred of
them :-).

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte richard-***@public.gmane.org
http://richard.levitte.org/

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Joel]

Thanks, Ted and Richard, especially for going to the effort of
deciphering my English.

(One of these days I'll learn how to type fast and be lucid at the same
time.)

On the question of using certificates to sign vs. using keys to sign,
could I ask for one more clarification --

If, for the sake of argument, I made a key for CA use, signed
certificates for servers with it, and then made the CA's certificate,
are the certificates signed when only the key existed going to be valid?
And are they going to be identical to certificates signed afterwards,
other than entropy?

I don't want to do this, it's just the quickest way I can think of to
ask about the mechanical interdependencies.

--
Joel Rees <rees-fctGxyACD9F3+***@public.gmane.org>
digitcom, inc. $B3t<02q<R%G%8%3%`(B
Kobe, Japan [phone]
** <http://www.ddcom.co.jp> **

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Richard Levitte - VMS Whacker]

In message <20050119222021.3525.REES-fctGxyACD9F3+***@public.gmane.org> on Wed, 19 Jan 2005 22:35:46 +0900, Joel <rees-fctGxyACD9F3+***@public.gmane.org> said:

rees> On the question of using certificates to sign vs. using keys to
rees> sign, could I ask for one more clarification --
rees>
rees> If, for the sake of argument, I made a key for CA use, signed
rees> certificates for servers with it, and then made the CA's
rees> certificate, are the certificates signed when only the key
rees> existed going to be valid? And are they going to be identical to
rees> certificates signed afterwards, other than entropy?

It's really a matter of interpretation for those doing the validation,
and as long as things look OK at the time you publish any certificate,
there should really be no problems.

There are a few things to keep track of, though:

- it would look quite suspicious of the notValidBefore field of the
CA certificate is later than the noValidBefore field of any
certificate it has issued.
- there are extensions that get data from the issuing certificate, so
creating certificates using only a key may not be very productive.
- the openssl utility won't allow it, because it will need the issuer
certificate to be able to fill in the issuer field, at the very
least.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte richard-***@public.gmane.org
http://richard.levitte.org/

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org