Bonjour Tim,
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
> On 19/05/11 13:03, Erwann ABALEA wrote:
[...]
> >SHA1 is still tolerated, but being slowly obsolete. You can still use
> >it if your serial numbers have some randomness, which is not the case
> >here. Either use one member of the SHA2 family, or generate random
> >serial numbers.
>
> Hi Erwann,
>
> 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
That way, the serial number is random for the outside, is guaranted to
be unique, and stays deterministic for you (decrypt it with your
secret key, and you'll be able to know which "number" it is, if you
need).
Using random serial numbers is interesting if the hash function is no
more collision resistant (MD5 isn't, SHA1 is still up, but not for so
long).
[...]
> >The nsCaRevocationUrl extension should be replaced by this:
> >crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl
>
> OK - cool. Should I support both do you think for backwards compatibility?
Just use crlDistributionPoints, everybody wanting to download a CRL
will do this from this extension. This "ns" (netscape) extension is of
no use.
> >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 :)
[...]
> This is one of those jobs that I assign the "want to do it right"
> flag too - I have a 100 servers that eventually need new certs
> (though I will probably be forced to use a wildcard CN on most of
> them as many do name based virtual hosting on apache - yes I know,
> the RFCs only mention wildcard CNs in the context of a few services
> and not specifically HTTPS, but what can you do...)
>
> Cheers,
>
> Tim
>
> 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.
--
Erwann ABALEA <erwann.aba...@keynectis.com>
Département R&D
KEYNECTIS
-----
If at first you don't succeed; Blame everyone else
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
