restrictions.
- SSL/TLS Web Server Authentication serverAuth 1.3.6.1.5.5.7.3.1
-Eduardo
Date: Thu, 19 May 2011 11:28:30 -0700
To: openssl-users@openssl.org
From: fl...@vicsmba.com
Subject: Re: [openssl-users] Quick eyeball requested - self generate openssl
certs/CA
A very simple one -- tax
Bonjour,
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
I do apologise - it's a long post. I'm just not totally sure if I
have the correct attributes and extensions - and whether it meets
the requirements of a v3 SSL cert (I think it does). Is 4096 bit key
and sha1 a good choice?
SHA1 is
Bonjour :)
On 19/05/11 13:03, Erwann ABALEA wrote:
Bonjour,
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
I do apologise - it's a long post. I'm just not totally sure if I
have the correct attributes and extensions - and whether it meets
the requirements of a v3 SSL cert (I think it does). Is
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,
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
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
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.
another approach is to take the
On 19/05/11 16:46, Peter Sylvester wrote:
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
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
On 19/05/11 16:46, Peter Sylvester wrote:
another approach is to take the value of 'time' (the current second)
and append to it the current process number, and, in case of
several machines, some number indicating the id of the machine.
instead
On 19/05/11 17:38, Erwann ABALEA wrote:
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
On 19/05/11 16:46, Peter Sylvester wrote:
another approach is to take the value of 'time' (the current second)
and append to it the current process number, and, in case of
several machines, some number
On Thu May 19 2011, Tim Watts wrote:
I think I might add some randomness into mine - seems easy enough. I
won't pretend I fully understand why - mostly because I wasn't clear why
the serial is important.
If your CPU has a 'time stamp register' (cycle counts since power-up) -
You can grab
On 05/19/2011 06:20 PM, Tim Watts wrote:
On 19/05/11 16:46, Peter Sylvester wrote:
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
A very simple one -- tax the time stamp register or the 4 byte cycles
since 1970, and concatenate the process id (which is unique for a
long time). The same process id cannot get either of those two
numbers in two calls to be the same. Eric
At 10:24 AM 5/19/2011, you wrote:
On Thu May 19
13 matches
Mail list logo
