Re: [openssl-users] CA
Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: On 05/18/2011 11:17 AM, Erwann ABALEA wrote: Bonjour, Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: Hi ! It’s possible to renew a Certificate Autority or extend the date validity ? These 2 options are possible. Recertify (i.e. sign the same certificate, but change the serial number and validity dates) is the least problematic solution, as the same public key will be used to validate the certificates and CRLs. Renew (i.e. create a entirely new certificate, strictly keeping the same exact subject DN, changing the key, validity dates, and potentially the extensions) is covered by the X.509 standard (a CA is a name, not a certificate). Sadly, you can't be sure it's correctly dealt with by verifiers. The new objects (certificates and CRLs) will be signed by the new CA key, the CRLs will cover both old and new certificates (by old, I mean those signed by the old CA certificate). If your CA is a root, and you want RFC5280 compliance, you MUST produce one CRL for each root CA certificate (and adapt the crlDistributionPoints). There seems to be a problem with this if you have AKID and SKID in place. Certificates signed with the old Root Certificate will be bound to the old Root Certificate serial number. You can verify this with the output of openssl x509 at the X509v3 extensions section. old end-user certificates can only be verified by the old CA certificate, of course (in case the CA is renewed, with its key changed, etc). The only way I found was to give the new Root Certificate the same serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. openssl req -new -x509 -days 1000 -key cakey.pem \ -set_serial old id in decimal -out new_cacert.pem After that, verification of already signed certificates is working fine with the old and new Root Certificate. Did you change the private key of the CA? If not, then: - the SKI of the new CA certificate will be the same as the old certificate (it's a *Key* identifier, and is generally constructed from the public key) - you don't need to have the same serial number (remember, it's forbidden by X.509 standard) - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). If you were in this situation, and only were able to verify end-user certificates if the new CA certificate had the same serial number as the old one, then I'm sure you made a mistake in your tests. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Press Control-Alt-$ to appease spirits. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-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: Can openssl support EAP-TLS?
That is correct, and what I was trying to get accross. bio pairs are your friend. From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Neo Liu [diablo...@gmail.com] Sent: Wednesday, May 18, 2011 3:54 AM To: openssl-users@openssl.org Subject: Re: Can openssl support EAP-TLS? I found an answer on the StackOverFlow. http://stackoverflow.com/questions/2512026/x-509-certificate-based-authentication-with-openssl-without-using-sockets It may work and I am trying on it. On Wed, May 18, 2011 at 3:35 PM, Neo Liu diablo...@gmail.commailto:diablo...@gmail.com wrote: Thanks for your advice. I have another question. If I don't use socket, how could I make TLS handshake happen? For example: incoming data TLS engine outgoing data My application get the incoming data from the client, and I feed it to the TLS engine, and then TLS engine give me the outgoing data which the application will send to the client. It seems like that my application is an agent of the client for both TLS handshake and TLS data transmission. How could I do it? On Wed, May 18, 2011 at 11:53 AM, Rene Hollan rene.hol...@watchguard.commailto:rene.hol...@watchguard.com wrote: You CAN use openssl as an engine, with bio pairs. Look here: http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html: Using BIOs for SSL Data Transmission (Optional) Instead of using SSL_write() and SSL_read(), you can transmit data by calling BIO_puts() and BIO_gets(), and BIO_write() and BIO_read(), provided that a buffer BIO is created and set up as follows: BIO*buf_io, *ssl_bio; char rbuf[READBUF_SIZE]; charwbuf[WRITEBUF_SIZE] buf_io = BIO_new(BIO_f_buffer()); /* create a buffer BIO */ ssl_bio = BIO_new(BIO_f_ssl()); /* create an ssl BIO */ BIO_set_ssl(ssl_bio, ssl, BIO_CLOSE); /* assign the ssl BIO to SSL */ BIO_push(buf_io, ssl_bio); /* add ssl_bio to buf_io */ ret = BIO_puts(buf_io, wbuf); /* Write contents of wbuf[] into buf_io */ ret = BIO_write(buf_io, wbuf, wlen); /* Write wlen-byte contents of wbuf[] into buf_io */ ret = BIO_gets(buf_io, rbuf, READBUF_SIZE); /* Read data from buf_io and store in rbuf[] */ ret = BIO_read(buf_io, rbuf, rlen); /* Read rlen-byte data from buf_io and store rbuf[] */ And also here: http://www.openssl.org/docs/crypto/BIO_new_bio_pair.html: The BIO pair can be used to have full control over the network access of an application. The application can call select() on the socket as required without having to go through the SSL-interface. The idea is that you have SSL use a bio that is one half of a bio pair: SSL will read and write from one bio of the pair, and this will automagically appear in the other bio of the bio pair (what's written on one side is read from the other, and vice-versa). You can also wrap the SSL-application side in a bio as first mentioned. It's a little tricky if you want to do this asynchronously: writing to the BIO fronting the SSL engine can result in output on the BIO of the BIO pair backing the SSL engine and/or output on the other side of the BIO fronting the SSL engine, and vice versa. This is because the SSL handshake takes place independently of the transfer of the data. Of course, it does no good to block on a BIO read that is stuck waiting a write on the same BIO (or the one on the other side of the SSL engine). I'm sure others might be able to explain it better, but it's a technique I've used in cases where I can't have SSL front a traditional socket. From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org] on behalf of Neo Liu [diablo...@gmail.commailto:diablo...@gmail.com] Sent: Tuesday, May 17, 2011 7:33 PM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: Can openssl support EAP-TLS? On Thu, May 12, 2011 at 10:18 AM, Rene Hollan rene.hol...@watchguard.commailto:rene.hol...@watchguard.com wrote: If you're looking to do authentication, freeradius will do EAP, and talk to openssl for the TLS part (and an LDAP server for the actual authentication and authorization). FreeRADIUS is too big for me. I just want to utilize OpenSSL to implement a EAP-TLS server. I want to openssl to handle the tls handshake and data encrypting and decryption, but I encapsulate the eap packet in my application. Can I use something like BIO pair or BIO mem to meet my need? Thanks for your great help.
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
RE: [openssl-users] CA
From: owner-openssl-us...@openssl.org On Behalf Of Erwann ABALEA Sent: Thursday, 19 May, 2011 04:20 Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: snip: renew CA The only way I found was to give the new Root Certificate the same serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. There are (at least) two kinds of AuthorityKeyIdentifier. AKI=SKI identifies only the parent (CA) key (by hash), and is ambiguous if CA gets new cert for same key. AKI=issuerSerial *does* use parent (CA) serial. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl.exe has stopped working.
When I run these two commands, the program prompts me for my password
twice, and then I get a popup which says, openssl.exe has stopped
working... A problem caused the program to stop working... (I am using
Windows 7)
C:\OpenSSL openssl pkcs12 -export -out cff_auth.pfx -name HRB Web
Service -inkey CFF_auth.key -in CFF_auth.pem
C:\OpenSSL openssl pkcs12 -export -out cff_soap.pfx -name HRB SOAP Web
Service -inkey cff_soap.key -in CFF_soap.pem
After I get the error, the .pfx files are still created, but I think
they might be corrupted because they cause a run time,
CryptographicException was unhandled dialog, with an
Unspecified error in my C# program. See code below.
I don't know if, or how, I might need to install OpenSSL. I just
unzipped it and I running it in the directory where I unzipped it with
my .pem's and .key's in that same directory.
n Error on highlighted line:
using ADPTest.com.adp.hrbws;
using System.Security.Cryptography.X509Certificates;
using Microsoft.Web.Services3.Security;
using Microsoft.Web.Services3.Security.Tokens;
using Microsoft.Web.Services3.Security.Cryptography;
namespace ADPTest
{
class Program
{
static void Main(string[] args)
{
// Create the web service proxy.
HrbService proxy = new HrbService();
// Add the Username token.
UsernameToken usernameToken = new UsernameToken(user@org,
);
proxy.RequestSoapContext.Security.Tokens.Add(usernameToken);
// Add the certificate for mutual SSL.
X509Certificate2 mutualCert = new
X509Certificate2(I:\\MyDocs\\ADP\\CFF_auth.pfx, OpenSSL_Pswd);
proxy.ClientCertificates.Add(mutualCert);
Rick Kushner
Sr Database Engineer
Cystic Fibrosis Foundation
301-907-2684 - office
317-758-7463 - cell
