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 List                    openssl-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 List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to