Re: Quick eyeball requested - self generate openssl certs/CA
On 19/05/11 10:44, Tim Watts wrote: Hi folks, I'm setting up a new CA/SSL infrastructure for work - the CA is self signed and all SSL certs (mostly server certs rather than client certs) will be signed off against this CA. Thanks for all your help - I've managed something that incorporates all the corrections mentioned here, which have proven invaluable. One further question through: Is this the correct incantation for renewing a cert (ie resigning with a new end date): #revoke original openssl ca -extensions server_cert -config blah.cnf -cert certs/CA.crt -keyfile certs/CA.key -revoke certs/www.example.com.crt # sign a new cert from the *original* CSR openssl ca -extensions server_cert -config blah.cnf -cert certs/CA.crt -keyfile certs/CA.key -days 1000 -in certs/www.example.com.csr -out certs/www.example.com.crt From what I understand, I only need to put the new cert on the server in question - the corresponding key remains untouched? TIA Cheers, Tim __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Serial Number/Randomness apart; how many certificates would you expect to issue in a year? How would you deploy the cert for trust among the different browsers? You should ensure that your certificates for SSL usage specify the appropriate EKU OID, in addition to path and issuance 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 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 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 those contents as your counter (usually 8 bytes worth). Since this counter advances rapidly (GHz range today) it is unlikely you will ever have two machines, or two serial number creations, that strike at the same clock cycle since power-up. (Thats a pretty small target to hit.) Usually that will cost you one or two machine cycles to read the counter. Relatively fast way to get an 8 byte number I haven't used before. Concantinate that with 8 bytes of something else of your choice that doesn't vary with the clock cycles since power up. If truly paranoid - 'whiten' with the hash function of your choice. (or with AES as in another post here - many machines can do AES in hardware.) Mike __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Support http://www.vicsmba.com Pictures of Snake in Spring http://www.facebook.com/album.php?aid=115547id=1409661701l=1c375e1f49 Pictures of Camp Verde http://www.facebook.com/album.php?aid=12771id=1409661701l=fc0e0a2bcf Pictures of Land Cruiser in Sedona http://www.facebook.com/album.php?aid=50953id=1409661701 Pictures of Flagstaff area near our cabin http://www.facebook.com/album.php?aid=12750id=1409661701 Pictures of Cheryl in a Horse Show http://www.facebook.com/album.php?aid=32484id=1409661701 Pictures of the AZ Desert http://www.facebook.com/album.php?aid=58827id=1409661701 (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Quick eyeball requested - self generate openssl certs/CA
Hi folks, I'm setting up a new CA/SSL infrastructure for work - the CA is self signed and all SSL certs (mostly server certs rather than client certs) will be signed off against this CA. I've just made the effort to try to actually understand SSL a bit better rather than monkey churning brokens certs out - so I'd really value a quick eyeball of my config and some text dumps of sample certs if anyone has a mo. Revocation crl would be published in this example at: http://www.example.com/ssl/CA-example.com.crl 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? And is the revocation bit done correctly (assuming I actually maintain a CRL from openssl ca -gencrl at the url above? Here goes: config = We use [v3_ca] for the CA, [server_cert] for server certs, [client_cert] for clients - Sorry slight line wrap The common name varies by the cert, but the rest is constant. = [ ca ] default_ca = CA_default [ CA_default ] dir = /home/tw/WORK/Devel/SSL-Certs database = /home/tw/WORK/Devel/SSL- Certs/.data/index.txt new_certs_dir = /home/tw/WORK/Devel/SSL-Certs/.data serial = /home/tw/WORK/Devel/SSL-Certs/.data/serial RANDFILE = /home/tw/WORK/Devel/SSL-Certs/.data/.rand x509_extensions = server_cert default_days = 395 default_crl_days = 395 default_md = sha1 preserve = no policy = policy unique_subject = yes email_in_dn = no [ server_cert ] basicConstraints = CA:FALSE nsCertType = server nsComment = OpenSSL Generated Certificate nsCaRevocationUrl = http://www.example.com/ssl/CA- example.com.crl subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy subjectAltName = email:copy [ client_cert ] basicConstraints = CA:FALSE nsCertType = client, email, objsign nsComment = OpenSSL Generated Certificate nsCaRevocationUrl = http://www.example.com/ssl/example.com.crl subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy subjectAltName = email:copy keyUsage = digitalSignature, keyEncipherment [ policy ] countryName = supplied stateOrProvinceName = supplied organizationName = supplied organizationalUnitName = supplied commonName = supplied emailAddress = optional [ req ] default_bits = 4096 distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = nombstr req_extensions = v3_req [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = GB countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = London localityName = Locality Name (eg, city) localityName_default = Trafalger Square 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Exampel Widgets Inc organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = Systems Group commonName = Common Name commonName_default = example.com commonName_max = 64 emailAddress = Email Address emailAddress_default = syst...@example.com emailAddress_max = 40 [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true nsCertType = sslCA, emailCA issuerAltName = issuer:copy nsComment = OpenSSL Generated Certificate nsCaRevocationUrl = http://www.example.com/ssl/CA- example.com.crl subjectAltName = email:copy keyUsage = critical, keyCertSign, cRLSign [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ req_attributes ] [ crl_ext ] authorityKeyIdentifier = keyid:always,issuer:always End config == == Sample CA text dump === generated with: openssl req -new -batch -keyform PEM -outform PEM -config .temp/sslconfig.cnf -out .temp/CA-example.com.csr -keyout .temp/CA- example.com.key -extensions v3_ca -sha1 and openssl ca -config .temp/sslconfig.cnf -create_serial -out .temp/CA- example.com.crt -days 3660 -batch -keyfile .temp/CA-example.com.key - selfsign -extensions v3_ca -in .temp/CA-example.com.csr == % openssl x509 -in certs/CA-example.com.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: 1048576 (0x10) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group, CN=example.com/emailAddress=syst...@example.com Validity Not Before: May 19 08:43:17 2011 GMT Not After : May 26 08:43:17 2021 GMT Subject: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group, CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): snip hex Exponent:
Re: Quick eyeball requested - self generate openssl certs/CA
On Thu, May 19, 2011 at 5:44 AM, Tim Watts t...@dionic.net wrote: Hi folks, I'm setting up a new CA/SSL infrastructure for work - the CA is self signed and all SSL certs (mostly server certs rather than client certs) will be signed off against this CA. I've just made the effort to try to actually understand SSL a bit better rather than monkey churning brokens certs out - so I'd really value a quick eyeball of my config and some text dumps of sample certs if anyone has a mo. Revocation crl would be published in this example at: http://www.example.com/ssl/CA-example.com.crl 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? And is the revocation bit done correctly (assuming I actually maintain a CRL from openssl ca -gencrl at the url above? [SNIP] I'm setting up a new CA/SSL infrastructure for work ... and whether it meets the requirements of a v3 SSL cert (I think it does). Is 4096 bit key and sha1 a good choice? SHA-1 is not a good choice here. You are exceeding 128 bits of security with the 4096 key, but only offering ~50 bits of security for authentication (SHA has an ideal level of 80 bits, but it has been reduced). You would probably want to use SHA-256. As an attacker, would you try to factor the modulus (which should take over 2^128 work, or swap in a key and sign it as the CA (at a cost of 2^50)? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Quick eyeball requested - self generate openssl certs/CA
On 19/05/11 11:53, Jeffrey Walton wrote: I'm setting up a new CA/SSL infrastructure for work ... and whether it meets the requirements of a v3 SSL cert (I think it does). Is 4096 bit key and sha1 a good choice? SHA-1 is not a good choice here. You are exceeding 128 bits of security with the 4096 key, but only offering ~50 bits of security for authentication (SHA has an ideal level of 80 bits, but it has been reduced). You would probably want to use SHA-256. As an attacker, would you try to factor the modulus (which should take over 2^128 work, or swap in a key and sign it as the CA (at a cost of 2^50)? Jeff Hi Jeff, Thank you for that - I'm a sysadmin, but I am not managing to keep up with encryption theory/practise recently. That is a very valuable tip - I'll swap it over to SHA-256. [Rest of query still stands for anyone kind enough to be able to comment on other aspects]. All the best, Tim __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 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. And is the revocation bit done correctly (assuming I actually maintain a CRL from openssl ca -gencrl at the url above? All the ns* extensions are deprecated, and shouldn't be used anymore. The nsCaRevocationUrl extension should be replaced by this: crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl You don't need to place a CRLDP extension in the root CA certificate (a root can't really revoke itself). You forgot to place the keyUsage extension in your server certificates. The issuerAltName extension is useless as stated (I'd say it's also useless in general, but I won't argue). I'd set the critical flag for the basicConstraints extension (both CA and end-users (server+user)). -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Your mouse has moved. Please reboot to continue. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 4096 bit key and sha1 a good choice? 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. And is the revocation bit done correctly (assuming I actually maintain a CRL from openssl ca -gencrl at the url above? All the ns* extensions are deprecated, and shouldn't be used anymore. I had a bad feeling about those, but when I searched on google for CRL revocation URL I didn't find anything else. Again, thanks - exactly the advice I am after :) 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? [1] See point below You don't need to place a CRLDP extension in the root CA certificate (a root can't really revoke itself). OK. Wasn't sure about that... You forgot to place the keyUsage extension in your server certificates. Oops. Ta. 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? I'd set the critical flag for the basicConstraints extension (both CA and end-users (server+user)). OK -will do :) Many many thanks for all this :) 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 [1] 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). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 -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 RD KEYNECTIS - If at first you don't succeed; Blame everyone else __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 intoCAdir/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 -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 intoCAdir/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 -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 RD KEYNECTIS - ``It's nice to be important, but it's important to be nice.'' Anon. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 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 of the process number, any other method to ensure uniqueness within a second may be used. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 problem. 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 of the process number, any other method to ensure uniqueness within a second may be used. Ah yes - that would guarantee a non repeating unpredictable sequence. I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?). Cheers Tim __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 of the process number, any other method to ensure uniqueness within a second may be used. Ah yes - that would guarantee a non repeating unpredictable sequence. I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?). 20 bytes max, for the RFC5280. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - If you never try anything new, you'll miss out on many of life's great disappointments. Demotivators, 2002 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 indicating the id of the machine. instead of the process number, any other method to ensure uniqueness within a second may be used. Ah yes - that would guarantee a non repeating unpredictable sequence. I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?). 20 bytes max, for the RFC5280. OK - wow. 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. I understand the merits of random TCP sequence numbers though - but the reason for those is a little more obvious. That's not a request for a detailed explanation, BTW - I'm happy to take it on trust from you experts :) Thanks! Tim __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 those contents as your counter (usually 8 bytes worth). Since this counter advances rapidly (GHz range today) it is unlikely you will ever have two machines, or two serial number creations, that strike at the same clock cycle since power-up. (Thats a pretty small target to hit.) Usually that will cost you one or two machine cycles to read the counter. Relatively fast way to get an 8 byte number I haven't used before. Concantinate that with 8 bytes of something else of your choice that doesn't vary with the clock cycles since power up. If truly paranoid - 'whiten' with the hash function of your choice. (or with AES as in another post here - many machines can do AES in hardware.) Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 the set of scripts I use), that's not a problem. 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 of the process number, any other method to ensure uniqueness within a second may be used. Ah yes - that would guarantee a non repeating unpredictable sequence. well, I was reminded that the number of forks may be predictable, but one can add some random or do some random process generation, so that you would have a large unpredictable part. I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?). 160 bits, let's say 159 you would take 39 for the date, and add a few bits of local uniqueness eg, a microsecond which is already difficult to predict, and then you still have about 100 possible random bits. Cheers Tim __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
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 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 those contents as your counter (usually 8 bytes worth). Since this counter advances rapidly (GHz range today) it is unlikely you will ever have two machines, or two serial number creations, that strike at the same clock cycle since power-up. (Thats a pretty small target to hit.) Usually that will cost you one or two machine cycles to read the counter. Relatively fast way to get an 8 byte number I haven't used before. Concantinate that with 8 bytes of something else of your choice that doesn't vary with the clock cycles since power up. If truly paranoid - 'whiten' with the hash function of your choice. (or with AES as in another post here - many machines can do AES in hardware.) Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Supporthttp://www.vicsmba.com Pictures of Snake in Spring http://www.facebook.com/album.php?aid=115547id=1409661701l=1c375e1f49 Pictures of Camp Verde http://www.facebook.com/album.php?aid=12771id=1409661701l=fc0e0a2bcf Pictures of Land Cruiser in Sedona http://www.facebook.com/album.php?aid=50953id=1409661701 Pictures of Flagstaff area near our cabin http://www.facebook.com/album.php?aid=12750id=1409661701 Pictures of Cheryl in a Horse Show http://www.facebook.com/album.php?aid=32484id=1409661701 Pictures of the AZ Desert http://www.facebook.com/album.php?aid=58827id=1409661701 (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
