Bonjour Tim,
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
> On 19/05/11 14:48, Erwann ABALEA wrote:
> >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
>
> 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?
Really, no. A counter is encrypted, and the result of the encryption
is the serial number.
If you imagine a collision in this serial number generation scheme,
then it means that a ciphertext (serial number) can be decrypted into
2 different plaintexts (counter). That's impossible if the secret key
is constant.
The problem with this scheme is that it doesn't deal well with
parallel certificate signatures. You have one shared information that
must be incremented in an atomic way. But for a "Junk CA" (that's how
I call the set of scripts I use), that's not a problem.
You could have used another scheme:
- generate 16 random bytes
- place them in the serialNumber
With such a scheme, yes, a collision could occur, and you should check
the index.txt file first.
Beware of the "ca" command line tool if you have a large population. I
wanted to use it for a massive certificate generation (in order to
fill an LDAP directory), and the time taken to generate a certificate
goes larger with the number of generated certificates (it must load
the file into memory, check if the given name either doesn't exist or
exists only with revoked or expired certificates, extend the list, and
finally write it again onto disk).
[...]
> >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.
Then this deployment server will be your SPOF :)
--
Erwann ABALEA <erwann.aba...@keynectis.com>
Département R&D
KEYNECTIS
-----
``It's nice to be important, but it's important to be nice.''
Anon.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
