On 19/05/11 14:48, Erwann ABALEA wrote:
Bonjour Tim,
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
Thanks for that. I'm not sure how to do random serials (I let
openssl manage those) but it interesting to know it makes a
difference.
This how I do this:
- in the setup phase, after having generated the CA private key,
generate a secret key (16 random bytes taken from /dev/urandom will
suffice), and place this key into<CAdir>/private/secretkey; I also
create a file named "counter", in the same directory as the
"serial" one, and init it with an "echo 1> ..../counter"
- when I want to sign a certificate, do this:
SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr
'a-f' 'A-F'`
COUNTER=`cat DIRECTORY/counter`
echo `expr $COUNTER + 1`> DIRECTORY/counter
SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv
00000000000000000000000000000000 -aes-128-cbc | od -t x1 -A n | sed 's/ //g' |
tr 'a-f' 'A-F'`
SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l`
and then either:
- use "-set_serial $SERIAL" if you produce a self-signed
certificate with the "openssl req" command
- do "echo $SERIAL> DIRECTORY/serial", and run the "openssl ca"
command as usual
Hi Erwann,
I presume there is a slight possibility of a serial number clash with
that? Not that it's a problem, but it would be wise to check index.txt
to see if the number has been used before?
The issuerAltName extension is useless as stated (I'd say it's also
useless in general, but I won't argue).
What should it be in this context?
Don't use this extension, unless you want to name your CA with another
name as the one given in its issuerName :)
Yes - I understand now - ta!
I read an interesting blog by a google employee on the issue of CRLs
and avoiding the whole issue by setting up automatic distribution of
very short time-to-live certs:
http://www.imperialviolet.org/2011/03/18/revocation.html
(Adam is an ex-student of the uni I used to work at - a very sharp
fellow indeed).
That's an interesting point. The author could have given more detailed
information, as some browsers use the native OS crypto API (for
example IE, Chrome or Safari), or use NSS when nothing is provided by the
OS (Chrome on Linux), or use their own crypto API (NSS for Firefox,
something else for Opera). The revocation validation is generally
performed by the used crypto API. To simplify it a little more, EV
behaviour is not imposed by this API, and is proprietary to the
browser.
You can surely deliver short-lived certificates, but you'll have to
renew them more often, and deploy them, etc. That's a lot of work :)
This solution has also be mentioned in the Mozilla CA Policy group.
I have a masterplan for that :) I have, out of necessity, a very secure
"gold server" that has access to everything else (it will become the
master Kerberos server one day and also needs to auto distribute
kerberos keys when that happens). It is extremely well protected - which
means the issue of caching the CA passphrase on it is moot (if anyone
hacks that server, they own everything anyway - SSL will be the least of
our problems - a point that is generally true of any master
authentication or config management server even without the additional
abilities this one has).
The infrastructure I envisage is one where a database will have a record
of all SSL enabled services and cert/key file locations plus CN
information - which makes it practical to run and distribute by itself -
which then makes Adam's idea viable.
Not that our infrastructure actually needs bomb proof SSL (we are not a
big target and we don't have any financial information to protect) - but
it is interesting academically.
Cheers,
Tim
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
