Don't worry about the newb questions, and I can help you answer them.
I will reply inline, and I'm going to clear the background information
so that the answers I give you will be more readable. (I am, however,
going to take the background information into account.)
On 2/21/06, Jeff Wiegley <[EMAIL PROTECTED]> wrote:
> I'm cheap, I don't want to pay veri$ign to get a verisign
> signed certificate (let alone half a dozen of them.) and
> cacert.org seems overkill since I'm the only one that really
> needs to use my own machines (except for web/mail) so I
> don't care if the certs end in a self signed certificate that
> I have to install as a CA. (If I've got an wrong assumptions
> in there forgive me, I already know I can't figure out what
> the heck I'm trying to do or talk about.
>From a software point of view, a CA is a certificate that has an
extension ("CA:true") embedded in it. A CA is not automatically
trusted when it is encountered; it is only trusted if explicit trust
is placed in it (by either the vendor of the software or the user), or
if trust is inherited from an explicitly trusted certificate.
A "root CA" is a self-signed certificate with the "CA:true" extension.
This is called the "trust anchor", as it is where all trust should be
placed in a given X.509 hierarchy.
> I want to point my mail program at imap.mydomain.com and
> smtp.mydomain.com. I want people to point their browser at
> www.mydomain.com and I want my roadwarriors to point their
> VPN clients at vpn.mydomain.com. So that when I have to
> change the actual machine the services are made available
> from I don't have to bother all my users/clients.
This is perfectly acceptable, though it is possible to have one
certificate that identifies multiple names (through the
"subjectAltName" extension). There is no reason you can't issue
individual certificates with individual keypairs, though.
> First major question:
> What is the difference between a CA, CA certificate and a
> CA root certificate???
A "CA" is a "Certifying Authority". It is a non-electronic entity
which verifies the authenticity of the credentials being requested,
and then issues those credentials. (Think of something like the DMV,
issuing an ID card -- a CA is essentially like that, except that
instead of a physical card being the credential, the logical
certificate structure is the credential, no matter if it's stored in
software, on a smart card, or whathaveyou..)
As I mentioned above, a "CA certificate" is a certificate that has the
"CA:true" extension embedded in it.
A "CA root certificate" is a CA certificate that is signed by the
private key that corresponds to the public key in its certificate --
i.e., it is "self-signed". The CA root certificate corresponds with
the Certifying Authority in whom all trust is placed.
> My guess is that I make CA, then I make a CA certificate,
> then I install the CA certificate in /etc/ssl/certs on all my
> servers/clients. Then I can use that CA cert to sign any other
> certs I want for individual services or client authentication.
>
> Is that correct?
Basically, yes. There are some caveats, however.
The certificates you issue from your CAs (be they root CAs or
'chained' CAs, which are signed by another CA) must adhere to a
standard format, and the certificate extensions must match what the
software they are going to be interacting with expect. In addition,
EVERY CERTIFICATE MUST HAVE A UNIQUE, POSITIVE SERIAL NUMBER. This is
very important, because that serial number is the primary way that a
certificate is identified by any software that uses it.
> Questions:
> 1) Is it possible to make my own CA thing (I use "thing" because
> I can't for the life of me figure out if I mean CA, CA certificate,
> root certificate or master certificate, all of which I have seen
> used seemingly arbitrarily on several dozen information sites
> today.) Should I install this "thing" as a trusted CA on my
> servers? I think so, but I'm totally confused. I mean could it
> possible to get more conflicting advice...
If you are attempting to create a CA, then you are a CA.
Congratulations -- you now have the responsibility for individually
issuing credentials to make use of your network. Getting the software
set up, though, is a bit trickier. (I'll address the
"interoperability software" issue first: yes, you install your CA root
certificate, which you will generate, as a trusted certificate in
every device and software that is going to be relying on your CA's
signatures. Otherwise, how could they know that the CA that signed it
is really the CA that is supposed to have signed it?)
> Here's what several sites have told me:
>
> site 1:
> openssl genrsa -des3 -out ca.key 1024
> openssl req -new -x509 -days 1001 -key ca.key -out ca.cer
There's a MUCH easier front-end to this, though you will need to get a
CVS snapshot in order to make use of it. It's called CA.pl or
CA.sh... either one of which will do what you need it to. There is
documentation for it on the openssl.org website, as well as in the man
pages included in the distribution.
The command above is very unlikely to result in a workable CA, because
it does not embed the "CA:true" attribute in the certificate it
generates. (And I would recommend at least a 2048 bit RSA key,
instead of 1024, but that's because I'm paranoid of the advances in
computing that are being made.)
> And then no information as to where or how to install
> this in my servers. Seems like /etc/ssl/certs would be a
> good place except *nothing* else there ends in .cer so
> I'm figuring this either created the wrong type of certificate
> or there is some other magical command I have to run to
> to convert to pem format.
What software are you using, that points to /etc/ssl/certs? Is it a
particular Linux distribution, or is that where you have chosen to put
your trusted certificate store?
>
> Also no information on how I sign something with this.
>
well, actually, the second command is basically what you use to sign
it -- use '-req' instead of '-x509' -- but again, I recommend using
the CA.sh or CA.pl wrappers to make it easier.
> site 2: http://sial.org/howto/openssl/ca/
> This site has "it" wrapped up in some sort of obfuscating
> make file.
>
> And again, no instructions how or where to install it so
> that certificates signed by this CA.
>
> This is possibly the worst site I came across in being
> thuroughly vacuous in it's tutorial abilities.
It's also not run by OpenSSL, so nothing can be done about it by us. ;)
> site 3: http://www.openssl.org/docs/apps/CA.pl.html
> Yeah! another wrapper. Software convenience wrappers are a
> lot like condoms in my opinion. Just messy. I'd like to
> understand the process instead of guessing or relying on a
> wrapper to make magical, incorrect guesses for me. But at least
> this seems to be a defacto standard interface. Instead of a
> wrapper the openssl tool/system should either be intuitive to
> use or have exceptional documentation on how to use it with
> lots of concrete, useful examples.
The wrapper is important because of the detail that it hides behind
the scenes. In a followup message to this one, I'll explain the
process of certificate creation and verification in fairly
excruciating detail -- however, for information on the formats that it
creates (and why certain things have to be done the way they are) you
will need to read the ITU recommendation X.509 [you can get up to 3
documents per year from the ITU free of charge], as well as all of the
IETF/IESG documents (RFCs) that relate to the term 'X.509' -- at this
writing, there are 31 of them. It would also help if you read the
'Secure Sockets Layer' and 'Transport Layer Security' RFCs, as well as
possibly the IPSEC RFCs. [This is going to take you at least a week
to read, and probably another month to cross-reference and get a
working understanding of.]
The OpenSSL tools do, for those who have read the above documents,
have exceptional documentation. It is NOT the place of OpenSSL to
provide a complete primer on exactly why it does what it does (that
honor is left for "Securing Networks with OpenSSL", a book published
by O'Reilly and Associates, information on which can be found at
http://www.oreilly.com/catalog/openssl/index.html ).
If you want better documentation, with lots of useful examples for
someone in your frame of mind, you (or someone with as little
knowledge as you) are going to have to be the one to write it. Those
of us who have been dealing with cryptography for at least a decade
don't have the necessary detachment to be able to do it, as our very
thought patterns have been warped by understanding it.
>
> So now I've got lots of easy, abstract options to choose from:
> -newcert: Yeah! I can make a self signed cert. Do I need a
> self signed cert for what I described? Do I need just
> a cert or do I need a CA cert or do I need a CA root
> cert?
You need a CA certificate. That's what the -newcert option does, it
creates a self-signed root CA certificate.
> -newreq: What in the world is a certificate request?
> wouldn't that be something you sent verisign in
> order to obtain a certificate? I doubt it, but
> how else is one suppose to interpret "creates a new
> certificate request?" If it really is a request for
> a certificate then who do I send this request to once
> I create to obtain my desired cert?
Actually, the 'request' is something you send to ANY CA, not just
Verisign. Once you have generated the request (which should be
generated under an account other than the one you use to run the CA
software, but that's 'separation of duty best practice'), you have a
private key and a public key. The request contains the public key
that you (the CA) are being asked to certify.
> -newca: creates a new CA heirarchy. This sounds good to me.
> But it doesn't create a CA cert? do I need both a
> CA heirarchy and a CA cert? which do I create first?
> Does one need the other?
This is the initialization of the CA directory hierarchy, which
contains the certificates that have been issued by the CA with the CA
certificate, the CRLs that have been issued by that CA certificate, an
index file specifying what the next serial number in series is, and
probably a couple of other things that I'm forgetting. It defaults to
creating a CA directory hierarchy rooted by a directory titled
'demoCA' in the current directory.
>
> -sign
> -signca
> -signcert ugh. ok these seem to sign things. I know my service
> certs need to be signed. I know that ssl/tls just
> walks back up the signature/cert chain until a trusted
> cert is found or a self signed cert is encountered.
> I actually do know that my CA cert needs to be
> self-signed (if I need a CA cert at all) and needs to
> installed in such a way that it is trusted. But I
> can't figure that how.
Your service certificates need to be signed, yes. There are different
ways that a certificate request can be signed, and here's the
difference:
-sign takes a certificate request located in the file 'newreq.pem',
which is in PEM format, and signs it according to the default policy.
It puts the output into 'newcert.pem'.
-signcert takes a self-signed X.509 certificate and re-signs it with
the current CA certificate.
-signCA takes a newreq.pem and signs it with a different
configuration, so that it becomes a valid 'chained' CA.
-xsign takes a certificate request located in the file 'newreq.pem',
which is in PEM format, and signs it according to the default policy.
It writes its output to stdout, so you can redirect it into a filename
of your choosing.
> Oh good... I especially liked this part for -signca...
> "This is useful when creating intermediate CA from a root CA."
> Have I just learned that I also need an intermediate CA in addition
> to my root CA??? is a root CA the same as a root CA certificate
> or does it mean a root CA heirarchy??
An 'intermediate CA' is a CA that you delegate trust to. Generally it
has a shorter validity period than the root CA, and is used to sign
certificate requests for a limited time. It may also be operated by
someone other than the main CA. In your instance, you do not appear
to need this functionality; however, if you end up having multiple
sites, you can create delegated CAs for them and have someone there
use THAT CA to sign certificates valid under your CA's trust.
>
> 2) Once I have the CA item figured out how do I create new certs for
> services that are signed by this CA thing?
>
To generate new certs for services, the easiest way is to take their
current certificates, copy them one by one into the 'newreq.pem' file,
and then use CA.pl -signcert . This will eliminate the need to
generate new keys or a new request for each service. (Note that after
you run that command, you will have a file called 'newcert.pem', which
must be copied back to the location that you got the original
certificate for that service from.)
> Please forgive me for being rude. I'm tired, I'm hungry, Got a huge
> headache, can't get my sewing machine parts back together into anything
> that resembles a sewing machine and I've spent several hours today just
> trying to understand the nomenclature of this stuff again.
Oh, hey. Forgive me for being rude -- I have an infected compromised
root canal, am on massive loads of antibiotics and prescription
painkillers which aren't doing a thing to help with the pain, and I'm
tired and hungry because it's keeping me from sleeping and chewing
anything makes the entire side of my head feel like it's on fire. I
also can't find my leatherworking tools, and am trying to figure out
how to pay this coming month's rent on my disability check. and I
/wish/ I had sewing machine parts to try to assemble into a sewing
machine.
Politeness doesn't cost a thing, even if you're in discomfort. (And
just my saying this makes me feel like I'm being rude, because I feel
like I'm lecturing when it's unwarranted.)
The nomenclature of this stuff IS COMPLICATED. There is no way around
that, because the ITU decided that they knew best, and the IETF has
been trying to work with the ISO standards that the ITU
recommendations became. Our hands are tied, here -- and I'm very,
very sorry that it's difficult to write any kind of documentation that
works. (I might try to write something to include into the "extra
contributed docs" section, though.)
> I have spent
> probably a hundred or more hours over the past few years trying to
> understand this exact same thing and never succeeded, forced to give up
> everytime.
This is why the wrapper exists, honestly. The OpenSSL team does do
its best to make it as easy as possible, but there's simply too much
complexity underneath to fully hide.
>
> Summary:
>
> Would somebody tell me the exact, complete steps, using only the
> openssl program, on unix/linux how to make yourself capable of being an
> authority and signing additional certificates for use with individual
> services?
CA.pl -newcert # create a new keypair and self-signed certificate,
located where the next command wants them
CA.pl -newca # Creates the CA directory hierarchy, making the
self-signed certificate into a CA, and putting the files it needs
[such as the private key file] where the -sign, -xsign, -
CA.pl -newreq # (for each service that you want to generate a new
request for). The private key will be located in the newreq.pem file,
along with the certificate request.
CA.pl -xsign > service.pem # This will take the newreq.pem file and
sign it, WITHOUT PUTTING THE PRIVATE KEY INTO THE .PEM FILE. You need
to have both the newreq.pem and the service.pem files copied to a
place specifically for that service, before you do the -newreq again.
The CA program will request information, including something called
"Distinguished Name", or DN. This is.. complicated to explain, but
I'll do my best.
The DN of an individual is supposed to be in the format
C=/O=/OU=/[OU=/...]/CN=<user's name>/E=<user's email address>. This
is a holdover from when the ITU honestly thought that there would be a
single worldwide root CA that would issue certificates to governments,
which would then issue them to companies, and the companies would
issue them to individuals. (It's the X.500 naming schema, and it's
also how LDAP sees things.) HOWEVER... CN=<user's name> works just as
well without all the overhead. (This is how OpenCA does it.)
(If you're curious, C=Country, O=Organization, OU=Organizational Unit,
CN=Common Name, E=Email.)
For servers, there should be only one entry in the DN field, and that
is "DN=server.name.company.com". However, you may have multiple DNs
in the same certificate (or a 'wildcard' "DN='*.company.com", which
will match any server under the company.com domain, and
DN=company.com, which will match if the user doesn't type 'www' or
'imap' or 'mail' or whathaveyou).
>
> The answer should include
> A) A list of openssl commands.
> B) For each command brief description of the purpose of the command
> C) A description of how to install the result as an authoritative
> certificate so that clients automatically accept certificates
> signed by the result.
Because the procedure varies from client software to client software
and server software to server software, doing part C is impossible. I
can give you the general procedure, though the specifics depend on the
software you're using:
The cacert.pem file must be placed into the 'trusted root
certificates' directory for the software you're using. (You may wish
to run:
openssl x509 -inform PEM -outform PEM -in cacert.pem -out
cacerttrust.pem -trustout
if you are using any other software that uses openssl; I'm not sure at
what point trust is checked, so it's probably better to be safe than
sorry.) If you are using a directory for CA certificates, and it's
used by anything that uses openssl, you need to copy the trusted
certificate into the directory and then run the c_rehash script in
that directory.
For software other than anything using OpenSSL, you need to check the
docs for that software... but ALL SOFTWARE - SERVER AND CLIENT - MUST
HAVE THE NEW CA IN ITS TRUSTED LIST. If that is not done, the
certificates issued by your CA will not be trusted by that software.
Once that is done, your server software config needs to be modified to
ask for certificates from your CA's name, for client authentication
purposes.
>
> The only thing I can offer is that if you help me then I will attempt
> to write a very detailed and accurate description of the process so
> that newbs like me don't have such a difficult time adopting this
> system in the future.
How's this: You write, I go over for technical accuracy, and then we
submit it? :)
>
> Thanks,
>
> - Jeff
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
