Re: why we call it entropy
Michael Sierchio wrote: A bit stream may have 1 bit of entropy per bit of message (i.e. an entropy of 1), and therefore be incompressible -- perhaps what Schwartz thinks he means when he says "truly random" -- and be entirely predictable. In case this isn't obvious, apply Von Neumann's corrector to the fractional component of the binary representation of a transcendental number. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
why we call it entropy
Von Neumann counseled Shannon to call it entropy because "no one really knows what entropy is". ;-) I wanted to say that it's inherently problematic to use things like the "randomness" in the interarrival time of events like interrupts, etc. to "gather" "entropy" -- Ted has touched on this with his comment on solid state disk drives, etc. A bit stream may have 1 bit of entropy per bit of message (i.e. an entropy of 1), and therefore be incompressible -- perhaps what Schwartz thinks he means when he says "truly random" -- and be entirely predictable. We want nicely-distributed "random" numbers without apparent bias, with an apparent entropy of one, so that 10 bits of key material is really 10 bits of key; what makes such numbers cryptographically useful is that no amount of collected material enables us to predict bits anywhere else in the stream (past or future, if viewed temporally). I have given Herr Schwartz enough of my grossmutterlich Freundlichkeit for one day. Ppppt. - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: compiling app with separate openssl
Hi, I'm no Linux guru but this worked for me (or rather it's equivalent). To ensure that you link to your development libraries: g++ -o tls-srv main.o /home/dev/openssl-0.9.8d/lib/libssl.so.0.9.8 /home/dev/openssl-0.9.8d/lib/libcrypto.so.0.9.8 ... and then use LD_LIBRARY_PATH in your run-time to ensure that your development, rather than installed, shared libraries are used. And also remember to set LD_LIBRARY_PATH before using ldd. G. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lauer, Thomas Sent: 08 August 2008 15:22 To: openssl-users@openssl.org Subject: compiling app with separate openssl hi. i'm using ubuntu with libssl-dev (0.9.8g-4ubuntu3.3). additional i compiled openssl 0.9.8d in a separate folder (/home/dev/openssl-0.9.8d). now i'm trying to compile a tool that will link to my second openssl-lib in /home/dev... this is my g++ call: #> g++ -o tls-srv main.o -L/home/dev/openssl-0.9.8d/lib -lssl -lcrypto but ldd shows me, that tls-srv will use the ossl lib in /usr/lib/i686/cmov/ (ubuntu ossl-lib). i compiled my second ossl lib with following commands: #> ./config --prefix=/home/dev/openssl-0.9.8d -DOPENSSL_NO_COMP #> make #> make install in /home/dev/openssl-0.9.8d there are the following lib-files: drwxr-xr-x 2 root root4096 2008-08-08 15:30 engines -rw-r--r-- 1 root root 2353124 2008-08-08 15:30 libcrypto.a lrwxrwxrwx 1 root root 18 2008-08-08 15:30 libcrypto.so -> libcrypto.so.0.9.8 -r-xr-xr-x 1 root root 1510851 2008-08-08 15:30 libcrypto.so.0.9.8 -rw-r--r-- 1 root root 399534 2008-08-08 15:30 libssl.a lrwxrwxrwx 1 root root 15 2008-08-08 15:30 libssl.so -> libssl.so.0.9.8 -r-xr-xr-x 1 root root 287236 2008-08-08 15:30 libssl.so.0.9.8 drwxr-xr-x 2 root root4096 2008-08-08 15:29 pkgconfig but i wonder, that #> ldd libssl.so use libcrypto.so from /usr/lib/i686/cmov [EMAIL PROTECTED]:/home/dev/openssl-0.9.8d/lib# ldd libssl.so linux-gate.so.1 => (0xb7f32000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d9f000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d9b000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c4b000) libz.so.1 => /usr/lib/libz.so.1 (0xb7c36000) /lib/ld-linux.so.2 (0xb7f33000) perhabs anybody can help me? thanks Thomas L. PS: sorry for my bad english :) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
compiling app with separate openssl
hi. i'm using ubuntu with libssl-dev (0.9.8g-4ubuntu3.3). additional i compiled openssl 0.9.8d in a separate folder (/home/dev/openssl-0.9.8d). now i'm trying to compile a tool that will link to my second openssl-lib in /home/dev... this is my g++ call: #> g++ -o tls-srv main.o -L/home/dev/openssl-0.9.8d/lib -lssl -lcrypto but ldd shows me, that tls-srv will use the ossl lib in /usr/lib/i686/cmov/ (ubuntu ossl-lib). i compiled my second ossl lib with following commands: #> ./config --prefix=/home/dev/openssl-0.9.8d -DOPENSSL_NO_COMP #> make #> make install in /home/dev/openssl-0.9.8d there are the following lib-files: drwxr-xr-x 2 root root4096 2008-08-08 15:30 engines -rw-r--r-- 1 root root 2353124 2008-08-08 15:30 libcrypto.a lrwxrwxrwx 1 root root 18 2008-08-08 15:30 libcrypto.so -> libcrypto.so.0.9.8 -r-xr-xr-x 1 root root 1510851 2008-08-08 15:30 libcrypto.so.0.9.8 -rw-r--r-- 1 root root 399534 2008-08-08 15:30 libssl.a lrwxrwxrwx 1 root root 15 2008-08-08 15:30 libssl.so -> libssl.so.0.9.8 -r-xr-xr-x 1 root root 287236 2008-08-08 15:30 libssl.so.0.9.8 drwxr-xr-x 2 root root4096 2008-08-08 15:29 pkgconfig but i wonder, that #> ldd libssl.so use libcrypto.so from /usr/lib/i686/cmov [EMAIL PROTECTED]:/home/dev/openssl-0.9.8d/lib# ldd libssl.so linux-gate.so.1 => (0xb7f32000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d9f000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d9b000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c4b000) libz.so.1 => /usr/lib/libz.so.1 (0xb7c36000) /lib/ld-linux.so.2 (0xb7f33000) perhabs anybody can help me? thanks Thomas L. PS: sorry for my bad english :) signature.asc Description: This is a digitally signed message part
Re: Certificate creation stuck at 256 certificates
On Fri August 8 2008 05:10, Ger Hobbelt wrote: > It may not be the number itself, but the file indexing; > There may be another option, called CA_dir (or something like that). > It contains every CA certificate in a separate file and optionally > all CRLs to use. > You run c_rehash on this directory to create special links OpenSSL > can use to find CA certificates and their CRLs... > > These links contain a 8 byte hash value and a extension > to differentiate between CA files and CRL files. > This 8 byte hash is not calculated on the file, > but on the subject DN. In another ml thread. Mike > Hm... I don't have the sources for 0.9.7 around, but when I quickly > look at the 0.9.9 code, it shouldn't do this (a2i_ASN1_INTEGER() is > used to convert the hex text in the file to a BigNum and to address > the sign mentioned before: AFAICS that routine requires an ASCII '-' > to identify negative values; it does not 'sign-extend' hex digits; > besides, if it ad, we'd already been in trouble when the serial went > from '7F' to '80') > > It may be that apps/ca.c + apps/apps.c in 0.9.7a is not (yet) using > this a2i_... function or that there's a typecast to char or some such > around (your problem smells a lot like that), so the only way out for > now that I can imagine is get an OpenSSL source tree from OpenSSL.org, > dump it in a temp directory for testing and build/compile it so you > get another apps/ca binary in there; it's not hard to do, so you > should be fine. Just read the instructions for configure and make and > you should be good to go. > > Then it will probably work out okay if you copy that demoCA directory > of yours over the openssl-testdir/apps/demoCA directory, then try > running the newly compiled ca binary to produce certificate with > serial '0100'. Should work out all right, though I must state that I > haven't used ca+demoCA enough to surpass the byte boundary you've run > into. > > So not a sure solution, but a probable direction towards solving this. > > HTH, > > > Ger > > PS: and yes, generally you can replace the demoCA directory across > OpenSSL versions of apps/ca, but always test to make sure when you > migrate (just a general 'test-before-release' note, nothing particular > to OpenSSL). Done it several times myself in my dev/test environments. > > > > > On Fri, Aug 8, 2008 at 6:26 AM, David Skeen <[EMAIL PROTECTED]> wrote: > > Thanks for response! > > > > Not sure what U are referring to about illegal cert number. > > > > Here is some more info: > > [EMAIL PROTECTED] demoCA]# ls > > cacert.pem crlindex.txt.old pem serial > > certs index.txt newcerts private serial.old > > [EMAIL PROTECTED] demoCA]# cat serial > > 0100 > > [EMAIL PROTECTED] demoCA]# cat serial.old > > FF > > [EMAIL PROTECTED] demoCA]# ls newcerts > > 01.pem 1B.pem 35.pem 4F.pem 69.pem 83.pem 9D.pem B7.pem D1.pem > > EB.pem > > 02.pem 1C.pem 36.pem 50.pem 6A.pem 84.pem 9E.pem B8.pem D2.pem > > EC.pem > > 03.pem 1D.pem 37.pem 51.pem 6B.pem 85.pem 9F.pem B9.pem D3.pem > > ED.pem > > 04.pem 1E.pem 38.pem 52.pem 6C.pem 86.pem A0.pem BA.pem D4.pem > > EE.pem > > 05.pem 1F.pem 39.pem 53.pem 6D.pem 87.pem A1.pem BB.pem D5.pem > > EF.pem > > 06.pem 20.pem 3A.pem 54.pem 6E.pem 88.pem A2.pem BC.pem D6.pem > > F0.pem > > 07.pem 21.pem 3B.pem 55.pem 6F.pem 89.pem A3.pem BD.pem D7.pem > > F1.pem > > 08.pem 22.pem 3C.pem 56.pem 70.pem 8A.pem A4.pem BE.pem D8.pem > > F2.pem > > 09.pem 23.pem 3D.pem 57.pem 71.pem 8B.pem A5.pem BF.pem D9.pem > > F3.pem > > 0A.pem 24.pem 3E.pem 58.pem 72.pem 8C.pem A6.pem C0.pem DA.pem > > F4.pem > > 0B.pem 25.pem 3F.pem 59.pem 73.pem 8D.pem A7.pem C1.pem DB.pem > > F5.pem > > 0C.pem 26.pem 40.pem 5A.pem 74.pem 8E.pem A8.pem C2.pem DC.pem > > F6.pem > > 0D.pem 27.pem 41.pem 5B.pem 75.pem 8F.pem A9.pem C3.pem DD.pem > > F7.pem > > 0E.pem 28.pem 42.pem 5C.pem 76.pem 90.pem AA.pem C4.pem DE.pem > > F8.pem > > 0F.pem 29.pem 43.pem 5D.pem 77.pem 91.pem AB.pem C5.pem DF.pem > > F9.pem > > 10.pem 2A.pem 44.pem 5E.pem 78.pem 92.pem AC.pem C6.pem E0.pem > > FA.pem > > 11.pem 2B.pem 45.pem 5F.pem 79.pem 93.pem AD.pem C7.pem E1.pem > > FB.pem > > 12.pem 2C.pem 46.pem 60.pem 7A.pem 94.pem AE.pem C8.pem E2.pem > > FC.pem > > 13.pem 2D.pem 47.pem 61.pem 7B.pem 95.pem AF.pem C9.pem E3.pem > > FD.pem > > 14.pem 2E.pem 48.pem 62.pem 7C.pem 96.pem B0.pem CA.pem E4.pem > > FE.pem > > 15.pem 2F.pem 49.pem 63.pem 7D.pem 97.pem B1.pem CB.pem E5.pem > > FF.pem > > 16.pem 30.pem 4A.pem 64.pem 7E.pem 98.pem B2.pem CC.pem E6.pem > > 17.pem 31.pem 4B.pem 65.pem 7F.pem 99.pem B3.pem CD.pem E7.pem > > 18.pem 32.pem 4C.pem 66.pem 80.pem 9A.pem B4.pem CE.pem E8.pem > > 19.pem 33.pem 4D.pem 67.pem 81.pem 9B.pem B5.pem CF.pem E9.pem > > 1A.pem 34.pem 4E.pem 68.pem 82.pem 9C.pem B6.pem D0
Re: EVP_CipherInit_ex because cipher->do_cipher is NULL
On Thu, Aug 7, 2008 at 8:13 AM, Ambarish Mitra <[EMAIL PROTECTED]> wrote: > The EVP_CipherInit_ex function returned 0 - indicating failure. Upon What does OpenSSL report as error code/description? (E.g. when using ERR_print_errors() - see the documentation for how to use) Ger -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate creation stuck at 256 certificates
Hm... I don't have the sources for 0.9.7 around, but when I quickly look at the 0.9.9 code, it shouldn't do this (a2i_ASN1_INTEGER() is used to convert the hex text in the file to a BigNum and to address the sign mentioned before: AFAICS that routine requires an ASCII '-' to identify negative values; it does not 'sign-extend' hex digits; besides, if it ad, we'd already been in trouble when the serial went from '7F' to '80') It may be that apps/ca.c + apps/apps.c in 0.9.7a is not (yet) using this a2i_... function or that there's a typecast to char or some such around (your problem smells a lot like that), so the only way out for now that I can imagine is get an OpenSSL source tree from OpenSSL.org, dump it in a temp directory for testing and build/compile it so you get another apps/ca binary in there; it's not hard to do, so you should be fine. Just read the instructions for configure and make and you should be good to go. Then it will probably work out okay if you copy that demoCA directory of yours over the openssl-testdir/apps/demoCA directory, then try running the newly compiled ca binary to produce certificate with serial '0100'. Should work out all right, though I must state that I haven't used ca+demoCA enough to surpass the byte boundary you've run into. So not a sure solution, but a probable direction towards solving this. HTH, Ger PS: and yes, generally you can replace the demoCA directory across OpenSSL versions of apps/ca, but always test to make sure when you migrate (just a general 'test-before-release' note, nothing particular to OpenSSL). Done it several times myself in my dev/test environments. On Fri, Aug 8, 2008 at 6:26 AM, David Skeen <[EMAIL PROTECTED]> wrote: > Thanks for response! > > Not sure what U are referring to about illegal cert number. > > Here is some more info: > [EMAIL PROTECTED] demoCA]# ls > cacert.pem crlindex.txt.old pem serial > certs index.txt newcerts private serial.old > [EMAIL PROTECTED] demoCA]# cat serial > 0100 > [EMAIL PROTECTED] demoCA]# cat serial.old > FF > [EMAIL PROTECTED] demoCA]# ls newcerts > 01.pem 1B.pem 35.pem 4F.pem 69.pem 83.pem 9D.pem B7.pem D1.pem > EB.pem > 02.pem 1C.pem 36.pem 50.pem 6A.pem 84.pem 9E.pem B8.pem D2.pem > EC.pem > 03.pem 1D.pem 37.pem 51.pem 6B.pem 85.pem 9F.pem B9.pem D3.pem > ED.pem > 04.pem 1E.pem 38.pem 52.pem 6C.pem 86.pem A0.pem BA.pem D4.pem > EE.pem > 05.pem 1F.pem 39.pem 53.pem 6D.pem 87.pem A1.pem BB.pem D5.pem > EF.pem > 06.pem 20.pem 3A.pem 54.pem 6E.pem 88.pem A2.pem BC.pem D6.pem > F0.pem > 07.pem 21.pem 3B.pem 55.pem 6F.pem 89.pem A3.pem BD.pem D7.pem > F1.pem > 08.pem 22.pem 3C.pem 56.pem 70.pem 8A.pem A4.pem BE.pem D8.pem > F2.pem > 09.pem 23.pem 3D.pem 57.pem 71.pem 8B.pem A5.pem BF.pem D9.pem > F3.pem > 0A.pem 24.pem 3E.pem 58.pem 72.pem 8C.pem A6.pem C0.pem DA.pem > F4.pem > 0B.pem 25.pem 3F.pem 59.pem 73.pem 8D.pem A7.pem C1.pem DB.pem > F5.pem > 0C.pem 26.pem 40.pem 5A.pem 74.pem 8E.pem A8.pem C2.pem DC.pem > F6.pem > 0D.pem 27.pem 41.pem 5B.pem 75.pem 8F.pem A9.pem C3.pem DD.pem > F7.pem > 0E.pem 28.pem 42.pem 5C.pem 76.pem 90.pem AA.pem C4.pem DE.pem > F8.pem > 0F.pem 29.pem 43.pem 5D.pem 77.pem 91.pem AB.pem C5.pem DF.pem > F9.pem > 10.pem 2A.pem 44.pem 5E.pem 78.pem 92.pem AC.pem C6.pem E0.pem > FA.pem > 11.pem 2B.pem 45.pem 5F.pem 79.pem 93.pem AD.pem C7.pem E1.pem > FB.pem > 12.pem 2C.pem 46.pem 60.pem 7A.pem 94.pem AE.pem C8.pem E2.pem > FC.pem > 13.pem 2D.pem 47.pem 61.pem 7B.pem 95.pem AF.pem C9.pem E3.pem > FD.pem > 14.pem 2E.pem 48.pem 62.pem 7C.pem 96.pem B0.pem CA.pem E4.pem > FE.pem > 15.pem 2F.pem 49.pem 63.pem 7D.pem 97.pem B1.pem CB.pem E5.pem > FF.pem > 16.pem 30.pem 4A.pem 64.pem 7E.pem 98.pem B2.pem CC.pem E6.pem > 17.pem 31.pem 4B.pem 65.pem 7F.pem 99.pem B3.pem CD.pem E7.pem > 18.pem 32.pem 4C.pem 66.pem 80.pem 9A.pem B4.pem CE.pem E8.pem > 19.pem 33.pem 4D.pem 67.pem 81.pem 9B.pem B5.pem CF.pem E9.pem > 1A.pem 34.pem 4E.pem 68.pem 82.pem 9C.pem B6.pem D0.pem EA.pem > > > I am not fully comprehending the whole demoCA procedure, however it is > rather odd that things have stopped working as the serial number ticks > over to 0100 from FF. Was hoping someone might have come across this > before ... > > Also, as a potential solution, is there a method for simply copying over > a demoCA from an old server to a new server? > > David Skeen > JDS Solutions > > On Thu, 2008-08-07 at 20:19 -0700, David Schwartz wrote: >> > I have had a look around and it appears that the serial number >> > for the >> > last certificate created was FF (hex), indicating 256 >> > certificates have >> > so far been created. The next number in the serial file is 0100, >> > which >> > would seem the logical next number,
Re: problems with certificate chain
Kyle Hamilton escribió: A server is not allowed to sign certificates unless its certificate has a CA:TRUE extended attribute, and "key signing" as an extended usage field. If it doesn't have those, it's not going to chain properly, no matter how you've got it set up. Only a CA can sign end-entity certificates. -Kyle H On Fri, Aug 8, 2008 at 1:40 AM, Sergio <[EMAIL PROTECTED]> wrote: Goetz Babin-Ebell escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergio wrote: | I think so and you're right. Signing a client cert with a server cert is | inefficient and all my problems would solve itself if radius has ocsp | support. The missing support for OCSP is not your problem. Your problem is the broken certificate hierarchy. You should not sign client certificates with a server certificate. You should sign client certificates with a CA certificate. That CA certificate may or may not be identical with that CA that signed your server certificate. | If i sign all the certs with ca private key everything works ok | but people at freeradius mailing list are insisting on the fact that | default configuration works. Do I get you right: The people on the freeradius mailing list insist on client certs should be signed by the server certificate ? That is hard for me to believe. It seems here is a mayor misunderstanding. | Also, if i put a both.pem file with server | cert and ca cert and put both.pem into CA_file, works. In the CA_file you put all (CA) certificates that issue certificates you may trust. If the server certificate issues client certificates it belongs there. But as I mentioned: That is a sign of a terrible broken concept. | But because of | this, i think i'd have problems to check the crl because the hash value | of CA_file isn't ca file. Is it true? ?? CA_file (or whatever this config option is named) contains a list of all trusted CA certificates. This file is especially needed on the server if you use client authentication: It contains the list of CA names the server sends to the client to show which CAs it accepts (at least in SSL/TLS) There may be another option, called CA_dir (or something like that). It contains every CA certificate in a separate file and optionally all CRLs to use. You run c_rehash on this directory to create special links OpenSSL can use to find CA certificates and their CRLs... These links contain a 8 byte hash value and a extension to differentiate between CA files and CRL files. This 8 byte hash is not calculated on the file, but on the subject DN. So is should be quite clear that every CA file in this directory should contain only one certificate. | Last question :) | how i can to know what's my openssl.cnf file? I have | /etc/ssl/openssl.cnf, /usr/local/ssl and one more which i've forgotten. strings `which openssl` | grep openssl.cnf should show the default configuration file your openssl version. You can always overwrite this with the -config option. | During this month, i've been using -config option with "openssl ca" | command because editing above files doesn't take effect. If in doubt, set the -config option. Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPejQmnbd8iQCghmcj +JFEgQWet/KhV4IAeDFn+LU= =fpp+ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Hi Goetz, it's true, default radius pki signs client certs with server private key and radius create test certificates at the beginning in this way. The idea is good, because the work of issuing certs is divided for several servers and, on the other side, any server can authenticate any client against ca certificate (first, checking its own sign into client cert) which is the same for all elemensts in pki. But my minds should have a hole. A big hole. I wonder how many people have configured eap-tls with freeradius. Surely i'll finally issue all certs with my ca private key (again) and check the same crl in all servers. If i don't do this before is because i thought that servers must manage it's own crl (signed by it's own pruivate key) so, my question is: can anybody check the revocation of a cert with a crl or only crl issuer? For the other side, ocsp requests is much more effective because: 1.- checking the sign of cert and checking the revocation are separated, any application can use the ocsp responder to its own needs 2.-managing an ocsp responder is much more comfortable (:)) because its dynamic working (at least what i've read at this moment) i want to make my own module in freeradius to provide ocsp support by is too com
Re: problems with certificate chain
A server is not allowed to sign certificates unless its certificate has a CA:TRUE extended attribute, and "key signing" as an extended usage field. If it doesn't have those, it's not going to chain properly, no matter how you've got it set up. Only a CA can sign end-entity certificates. -Kyle H On Fri, Aug 8, 2008 at 1:40 AM, Sergio <[EMAIL PROTECTED]> wrote: > Goetz Babin-Ebell escribió: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Sergio wrote: >> >> | I think so and you're right. Signing a client cert with a server cert is >> | inefficient and all my problems would solve itself if radius has ocsp >> | support. >> The missing support for OCSP is not your problem. >> Your problem is the broken certificate hierarchy. >> You should not sign client certificates with a server certificate. >> You should sign client certificates with a CA certificate. >> That CA certificate may or may not be identical with that CA >> that signed your server certificate. >> >> | If i sign all the certs with ca private key everything works ok >> | but people at freeradius mailing list are insisting on the fact that >> | default configuration works. >> Do I get you right: >> The people on the freeradius mailing list insist on client certs >> should be signed by the server certificate ? >> That is hard for me to believe. >> It seems here is a mayor misunderstanding. >> >> | Also, if i put a both.pem file with server >> | cert and ca cert and put both.pem into CA_file, works. >> In the CA_file you put all (CA) certificates that issue >> certificates you may trust. >> If the server certificate issues client certificates >> it belongs there. >> But as I mentioned: >> That is a sign of a terrible broken concept. >> >> | But because of >> | this, i think i'd have problems to check the crl because the hash value >> | of CA_file isn't ca file. Is it true? >> >> ?? >> CA_file (or whatever this config option is named) >> contains a list of all trusted CA certificates. >> This file is especially needed on the server if you use >> client authentication: >> It contains the list of CA names the server sends to the client >> to show which CAs it accepts (at least in SSL/TLS) >> >> There may be another option, called CA_dir (or something like that). >> It contains every CA certificate in a separate file and optionally >> all CRLs to use. >> You run c_rehash on this directory to create special links OpenSSL >> can use to find CA certificates and their CRLs... >> >> These links contain a 8 byte hash value and a extension >> to differentiate between CA files and CRL files. >> This 8 byte hash is not calculated on the file, >> but on the subject DN. >> So is should be quite clear that every CA file in this >> directory should contain only one certificate. >> >> | Last question :) >> | how i can to know what's my openssl.cnf file? I have >> | /etc/ssl/openssl.cnf, /usr/local/ssl and one more which i've forgotten. >> >> strings `which openssl` | grep openssl.cnf >> should show the default configuration file your openssl version. >> You can always overwrite this with the -config option. >> >> | During this month, i've been using -config option with "openssl ca" >> | command because editing above files doesn't take effect. >> If in doubt, set the -config option. >> >> Goetz >> >> - -- >> DMCA: The greed of the few outweighs the freedom of the many >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.4-svn0 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPejQmnbd8iQCghmcj >> +JFEgQWet/KhV4IAeDFn+LU= >> =fpp+ >> -END PGP SIGNATURE- >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager [EMAIL PROTECTED] >> >> > Hi Goetz, > > it's true, default radius pki signs client certs with server private key and > radius create test certificates at the beginning in this way. The idea is > good, because the work of issuing certs is divided for several servers and, > on the other side, any server can authenticate any client against ca > certificate (first, checking its own sign into client cert) which is the > same for all elemensts in pki. But my minds should have a hole. A big hole. > I wonder how many people have configured eap-tls with freeradius. > Surely i'll finally issue all certs with my ca private key (again) and check > the same crl in all servers. If i don't do this before is because i thought > that servers must manage it's own crl (signed by it's own pruivate key) so, > my question is: can anybody check the revocation of a cert with a crl or > only crl issuer? > For the other side, ocsp requests is much more effective because: > 1.- checking the sign of cert and checking the revocation are separated, any > application can use the
Re: [openssl-users] RE: Certificate creation stuck at 256 certificates
Hodie VII Id. Aug. MMVIII est, David Schwartz scripsit: > > > I have had a look around and it appears that the serial number > > for the > > last certificate created was FF (hex), indicating 256 > > certificates have > > so far been created. The next number in the serial file is 0100, > > which > > would seem the logical next number, however the certificate > > signing > > bails out on me. > > FF is not a legal certificate number. Certificate numbers must not be > negative. (0xFF has the sign bit set and hence is negative.) "Legally" (this term has nothing to do here) a serial number *can* be negative, if you're looking at the X.509 recommendation. That's surely not the reason of the problem. Only the RFC (starting with 3280) states that the serialNumber MUST be a positive integer. -- Erwann ABALEA <[EMAIL PROTECTED]> - ``Do or do not. There is no try." Yoda __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: problems with certificate chain
Goetz Babin-Ebell escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergio wrote: | I think so and you're right. Signing a client cert with a server cert is | inefficient and all my problems would solve itself if radius has ocsp | support. The missing support for OCSP is not your problem. Your problem is the broken certificate hierarchy. You should not sign client certificates with a server certificate. You should sign client certificates with a CA certificate. That CA certificate may or may not be identical with that CA that signed your server certificate. | If i sign all the certs with ca private key everything works ok | but people at freeradius mailing list are insisting on the fact that | default configuration works. Do I get you right: The people on the freeradius mailing list insist on client certs should be signed by the server certificate ? That is hard for me to believe. It seems here is a mayor misunderstanding. | Also, if i put a both.pem file with server | cert and ca cert and put both.pem into CA_file, works. In the CA_file you put all (CA) certificates that issue certificates you may trust. If the server certificate issues client certificates it belongs there. But as I mentioned: That is a sign of a terrible broken concept. | But because of | this, i think i'd have problems to check the crl because the hash value | of CA_file isn't ca file. Is it true? ?? CA_file (or whatever this config option is named) contains a list of all trusted CA certificates. This file is especially needed on the server if you use client authentication: It contains the list of CA names the server sends to the client to show which CAs it accepts (at least in SSL/TLS) There may be another option, called CA_dir (or something like that). It contains every CA certificate in a separate file and optionally all CRLs to use. You run c_rehash on this directory to create special links OpenSSL can use to find CA certificates and their CRLs... These links contain a 8 byte hash value and a extension to differentiate between CA files and CRL files. This 8 byte hash is not calculated on the file, but on the subject DN. So is should be quite clear that every CA file in this directory should contain only one certificate. | Last question :) | how i can to know what's my openssl.cnf file? I have | /etc/ssl/openssl.cnf, /usr/local/ssl and one more which i've forgotten. strings `which openssl` | grep openssl.cnf should show the default configuration file your openssl version. You can always overwrite this with the -config option. | During this month, i've been using -config option with "openssl ca" | command because editing above files doesn't take effect. If in doubt, set the -config option. Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPejQmnbd8iQCghmcj +JFEgQWet/KhV4IAeDFn+LU= =fpp+ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Hi Goetz, it's true, default radius pki signs client certs with server private key and radius create test certificates at the beginning in this way. The idea is good, because the work of issuing certs is divided for several servers and, on the other side, any server can authenticate any client against ca certificate (first, checking its own sign into client cert) which is the same for all elemensts in pki. But my minds should have a hole. A big hole. I wonder how many people have configured eap-tls with freeradius. Surely i'll finally issue all certs with my ca private key (again) and check the same crl in all servers. If i don't do this before is because i thought that servers must manage it's own crl (signed by it's own pruivate key) so, my question is: can anybody check the revocation of a cert with a crl or only crl issuer? For the other side, ocsp requests is much more effective because: 1.- checking the sign of cert and checking the revocation are separated, any application can use the ocsp responder to its own needs 2.-managing an ocsp responder is much more comfortable (:)) because its dynamic working (at least what i've read at this moment) i want to make my own module in freeradius to provide ocsp support by is too complex programming. I'm reading openssl ocsp code and doc slowly. Thanks for your attention __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: NIST SP 800-22
This is not the place to try to get support with the rand() library of
any IAR product. You will need to check with IAR. I'm pretty sure
that the answer is "no", though, especially when used like that.
-Kyle H
On Fri, Aug 8, 2008 at 12:27 AM, abc_123_ok <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> In my program, I use rand() to generate some randsom, I use IAR compiler to
> compile my program, I want to know the rand() of IAR lib if it is according
> to NIST SP 800-22.
>
> for (count = 0; count < 32; count++)
> {
> sslContext[0].clientRandom[count] = rand();
> sslContext[0].sessionID[count] = rand();
> }
>
> Thanks & Best Regards.
>
>
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
NIST SP 800-22
Dear All,
In my program, I use rand() to generate some randsom, I use IAR compiler to
compile my program, I want to know the rand() of IAR lib if it is according to
NIST SP 800-22.
for (count = 0; count < 32; count++)
{
sslContext[0].clientRandom[count] = rand();
sslContext[0].sessionID[count] = rand();
}
Thanks & Best Regards.
