[clue-admin] Cert for TLS.

[David L. Anselmi]

Jed S. Baer wrote:
[...]
> The part of it I'd like some input on is dealing with the passphrase
> protection of the private key. I'll play with this a bit here at home, but
> the last thing I want to have is for a reboot to get stuck because Apache
> is waiting for someone to input the passphrase. My guess is that most
> people don't use a passphrase-protected key, and just protect the private
> key as best they can. Otherwise re-booting a shared-hosting server would
> be a nightmare.

Exactly, don't bother with a passphrase.

The first time I did this we had a passphrase, and a script or something 
that decrypted the key when apache started.  So in addition to file 
system permissions we had some obfuscation, but I doubt that it was 
worth it.

If a server's key is stolen it allows the bad guys to impersonate the 
server.  But for that to be perfect they need to steal your IP or DNS 
record as well.  Both are possible in various ways, as well as a less 
than perfect look-alike type of attack (say they use cludenver.org). 
But none of that really matters to us, I think.

> Can you elaborate on the difference between generating a (regular) RSA
> keypair and a "CA" key-pair?

The keys are the same, except perhaps you'll use a longer one for a CA 
(you expect to use it longer and extra processing doesn't matter since 
it's used only when signing certs).

A certificate is created by concatenating various bits of identity data 
with a public key and then signing the result.  This states that the 
signer (person with the CA private key) believes that the ID data is 
true for the holder of the private key that matches the public key in 
the cert.

A CA cert is the cert belonging to someone who signs other certs.  The 
CA's name goes in the issuer field of the certs they sign.  There can be 
a hierarchy to CAs, so at the root there is always a self-signed 
certificate where the subject and issuer fields are the same.

A CA cert may have other differences than a regular server cert.  It may 
contain an X509v3 Basic Constraints field that says CA:TRUE.  It also 
probably has a longer validity period.  And since browsers et. al. 
usually accept anything signed by a CA they trust, the private key has 
to be well protected.

Server certs will have basic constraints that say CA:FALSE, perhaps a 
Netscape Cert Type:SSL Server (that's for openvpn), or extensions that 
say they are allowed to sign or encrypt keys (since that's what servers 
do).  Extensions and constraints are a way for the issuer to define what 
a key should be used for but I don't think apps (browsers) pay much 
attention to them.

It looks like using openssl req with -x509 is the way to get a self 
signed cert.  Without that it will create (besides the key) a CSR 
(certificate signing request) which is the unsigned cert.  For the 
paranoid only the owner should ever have access to the private key so 
the CSR is the thing sent to the CA and the private key never leaves the 
owner's possesion.

There is more to say, especially about the openssl.cnf file, which is 
pretty arcane.  I don't think you can get by without one (being prompted 
for everything might be easier in our case).  But it can prevent you 
from doing what you want if it isn't correct.

So, what else can I answer?

Dave