problems with certificate chain - Openssl

This is a discussion on problems with certificate chain - Openssl ; Hi people, i have a problem with certificate chain. I'm configuring freeradius and wpa_supplicant using eap-tls protocol. client.pem are signed by server.pem, and server.pem are signed by ca.pem. I've tried to install (using ln -s and hash value of cert) ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: problems with certificate chain

  1. problems with certificate chain

    Hi people,

    i have a problem with certificate chain. I'm configuring freeradius and
    wpa_supplicant using eap-tls protocol. client.pem are signed by
    server.pem, and server.pem are signed by ca.pem. I've tried to install
    (using ln -s and hash value of cert) ca.pem and server.pem into
    /etc/ssl/certs and also in /usr/local/ssl (where my compiled version of
    openssl is). I've checked this actions executing "openssl verify" and
    all is ok, but when the user is going to be authenticated, radius always
    show the same error:
    unable to get local issuer. I'm using default configuration in
    freeradius and should be an error of my openssl usage. My brain is being
    hurted because i bring this error with me about one month. I know there
    are many post about this error in this mailing list and i've read it
    with no results. I think probably is my english usage (jeje). Can
    somebody help me?

    Thanks
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: problems with certificate chain

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Sergio wrote:
    | Hi people,
    Hello Sergio,

    | client.pem are signed by
    | server.pem, and server.pem are signed by ca.pem.

    It is a bad bad idea to sign a client certificate with
    a server certificate.
    Usually server certificates don't have the extensions
    to sign certificates but have extensions explicitly
    signaling that they are not to be used to sign certificates.

    Try to sign the client certs with the ca certificate.

    Then check the freeradius configuration that the CA used
    to verify client certificates is the CA certificate.

    If you insist on an intermediate certificate between the
    CA and the client certificates you must either configure
    the server to also use the intermediate CA as a CA
    or you must configure the clients to send the intermediate
    back to the server.

    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

    iD8DBQFImiXp2iGqZUF3qPYRAtZWAJ94AfIAI3FVrIpgBCmloW l7ea4RFgCfRgV+
    DwRAYGxBD//EitviXnMdAhA=
    =NyUw
    -----END PGP SIGNATURE-----
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: problems with certificate chain

    Goetz Babin-Ebell escribió:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Sergio wrote:
    > | Hi people,
    > Hello Sergio,
    >
    > | client.pem are signed by
    > | server.pem, and server.pem are signed by ca.pem.
    >
    > It is a bad bad idea to sign a client certificate with
    > a server certificate.
    > Usually server certificates don't have the extensions
    > to sign certificates but have extensions explicitly
    > signaling that they are not to be used to sign certificates.
    >
    > Try to sign the client certs with the ca certificate.
    >
    > Then check the freeradius configuration that the CA used
    > to verify client certificates is the CA certificate.
    >
    > If you insist on an intermediate certificate between the
    > CA and the client certificates you must either configure
    > the server to also use the intermediate CA as a CA
    > or you must configure the clients to send the intermediate
    > back to the server.
    >
    > 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
    >
    > iD8DBQFImiXp2iGqZUF3qPYRAtZWAJ94AfIAI3FVrIpgBCmloW l7ea4RFgCfRgV+
    > DwRAYGxBD//EitviXnMdAhA=
    > =NyUw
    > -----END PGP SIGNATURE-----
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >
    >

    Hi Goetz,

    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. 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. Also, if i put a both.pem file with server
    cert and ca cert and put both.pem into CA_file, works. 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?

    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.
    During this month, i've been using -config option with "openssl ca"
    command because editing above files doesn't take effect.

    Thank you very much
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: problems with certificate chain

    -----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

    iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPej Qmnbd8iQCghmcj
    +JFEgQWet/KhV4IAeDFn+LU=
    =fpp+
    -----END PGP SIGNATURE-----
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  5. 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
    >
    > iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPej Qmnbd8iQCghmcj
    > +JFEgQWet/KhV4IAeDFn+LU=
    > =fpp+
    > -----END PGP SIGNATURE-----
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >
    >

    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 majordomo@openssl.org


  6. 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 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
    >>>
    >>> iD8DBQFIm4L32iGqZUF3qPYRAnQcAJ4wySVZVOEWH1lFbZIPej Qmnbd8iQCghmcj
    >>> +JFEgQWet/KhV4IAeDFn+LU=
    >>> =fpp+
    >>> -----END PGP SIGNATURE-----
    >>> __________________________________________________ ____________________
    >>> OpenSSL Project http://www.openssl.org
    >>> User Support Mailing List openssl-users@openssl.org
    >>> Automated List Manager majordomo@openssl.org
    >>>
    >>>
    >>>

    >> 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 majordomo@openssl.org
    >>
    >>

    Thanks for your response. I've signed client cert with ca private key
    and all works ok. I can manage the CRL and authenticate users.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread