Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
Rob Crittenden wrote: Jan Pazdziora wrote: On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: The problem is that if you pass IPA certificates issued by CA2 and point it to CA1 at the same time, it does not work (despite having the complete trust chain). But why would you do so? What would be the reason and business case? Why not to point to CA2? Could the business case be an IPA server in DMZ which does not have access to CA2 but it can get to (public) CA1? A client does need to be able to contact a CA in order to trust it. Of course I meant that a client does NOT need to contact a CA. It just needs the CA cert. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
Jan Pazdziora wrote: On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: The problem is that if you pass IPA certificates issued by CA2 and point it to CA1 at the same time, it does not work (despite having the complete trust chain). But why would you do so? What would be the reason and business case? Why not to point to CA2? Could the business case be an IPA server in DMZ which does not have access to CA2 but it can get to (public) CA1? A client does need to be able to contact a CA in order to trust it. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: > > > > The problem is that if you pass IPA certificates issued by CA2 and > > point it to CA1 at the same time, it does not work (despite having the > > complete trust chain). > > But why would you do so? What would be the reason and business case? Why > not to point to CA2? Could the business case be an IPA server in DMZ which does not have access to CA2 but it can get to (public) CA1? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
Dmitri Pal wrote: On 06/10/2013 12:13 PM, Petr Viktorin wrote: On 06/10/2013 05:34 PM, Dmitri Pal wrote: On 06/10/2013 09:56 AM, Petr Viktorin wrote: On 06/10/2013 03:35 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 06/10/2013 05:54 AM, Jan Cholasta wrote: On 7.6.2013 15:36, John Dennis wrote: On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. Well, that's not a necessary requirement. A tester did have a bit of trouble creating a PKCS#12 file with both the server cert and the CA cert, but the trouble is comparable to having to create a PEM file. 2. Because previous attempts to figure out the nickname of the signing CA was problematic. This is the main reason. It could be done, but I believe we should avoid any guessing to determine the root of trust. I am not sure I get it. So we inspect the certificate PKCS#12 file and there can be ambiguity about the root of trust. How? This part is not clear to me. Sorry for being slow here. Can someone explain it in more details? A PKCS#12 file can contain any number of arbitrary certificates (or other objects). There is already some ambiguity in determining which cert to use for the server. Here we error out if we don't find exactly one cert with appropriate usage flags. The root CA cert can be the one that signed the server cert (the only scenario that works now), or it can be any one along the chain. If you have an intermediate CA signed by a well-known authority, you would probably not want to trust *everything* signed by that authority; you'd want to trust "your" root CA which can be anywhere along the chain. If we exclude scenarios with Intermediate CAs (which don't currently work), the situation is much simpler, but we don't want to limit the CLI to that. Note that users can't usually carefully control what's inside the PKCS#12 file: the tools will typically allow generating a file with either only one cert, or with the entire chain. Regardless... If something can't be reliably determined then we should probably do following: If we have any issues with determining the root of trust we should fail and request the caller to run the command again with additional command line option that would explicitly provide the the name of the root CA. Will that help? That would be any time there's more than one CA in the trust chain. Is it worth special-casing this? Are there real-world deployments that only use one CA? Note that in this case you can just use a single-cert PKCS#12 plus a PEM file for the CA, which is simple enough IMO. So my point is that why we can't say that we support only a single-cert PKCS#12 file plus a PEM file case and have a clear set of instructions on how to produce these files? The problem is that the user has very little control over what gets pulled in and doing so would probably require a whole lot of additional steps that may just make them throw up their hands altogether. Take the NSS case. It will automatically pull in any needed CA certificates that are also in the database. So you'd have to go about deleting those certs prior to creating the PKCS#12 file or you'd have to create the PKCS#12 file, import it into a temporary NSS database, delete the unwanted certs, then re
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/10/2013 12:13 PM, Petr Viktorin wrote: > On 06/10/2013 05:34 PM, Dmitri Pal wrote: >> On 06/10/2013 09:56 AM, Petr Viktorin wrote: >>> On 06/10/2013 03:35 PM, Rob Crittenden wrote: Dmitri Pal wrote: > On 06/10/2013 05:54 AM, Jan Cholasta wrote: >> On 7.6.2013 15:36, John Dennis wrote: >>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: > On 06/07/2013 08:57 AM, Jan Cholasta wrote: >> Yes, this is correct. The DS certificate must be directly signed >> by the >> CA trusted by IPA (specified by --root-ca-cert in >> ipa-server-install), >> there may be no intermediate CAs, because ldapsearch and >> friends and >> python-ldap don't like them. > > That doesn't sound right. Do we understand why a chain length > > 1 is > failing? > LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). >>> >>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto >>> provider). >>> Have we filed a bug? Let's file the bug here in the Red Hat >>> bugzilla, >>> not upstream, we're the maintainers of MozLDAP and upstream is >>> already >>> frustrated with it. >>> >> >> I have just tested with libldap compiled with OpenSSL on my Arch >> Linux >> box, it does not work as well: >> >> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >> Manager' -W >> -b '' -s base >> ldap_start_tls: Connect error (-11) >> additional info: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> (invalid CA certificate) >> >> For the record, this is what happens with NSS on Fedora: >> >> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >> Manager' -W >> -b '' -s base >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8179:Peer's Certificate issuer >> is not >> recognized. >> >> Honza >> > If the options does not work we should hide it for now and clearly > state > in the docs and man pages that the case when certs come from > different > CA is not supported for the time being. > IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. >>> >>> Well, that's not a necessary requirement. A tester did have a bit of >>> trouble creating a PKCS#12 file with both the server cert and the CA >>> cert, but the trouble is comparable to having to create a PEM file. >>> 2. Because previous attempts to figure out the nickname of the signing CA was problematic. >>> >>> This is the main reason. It could be done, but I believe we should >>> avoid any guessing to determine the root of trust. >>> >> >> I am not sure I get it. >> So we inspect the certificate PKCS#12 file and there can be ambiguity >> about the root of trust. How? This part is not clear to me. >> Sorry for being slow here. Can someone explain it in more details? > > A PKCS#12 file can contain any number of arbitrary certificates (or > other objects). > There is already some ambiguity in determining which cert to use for > the server. Here we error out if we don't find exactly one cert with > appropriate usage flags. > The root CA cert can be the one that signed the server cert (the only > scenario that works now), or it can be any one along the chain. > If you have an intermediate CA signed by a well-known authority, you > would probably not want to trust *everything* signed by that > authority; you'd want to trust "your" root CA which can be anywhere > along the chain. > > If we exclude scenarios with Intermediate CAs (which don't currently > work), the situation is much simpler, but we don't want to limit the > CLI to that. > > Note that users can't usually carefully control what's inside the > PKCS#12 file: the tools will typically allow generating a file with > either only one cert, or with the entire chain. > >> Regardless... >> If something can't be reliably determined then we should probably do >> following: >> If we have any issues with determining the root of trust we should fail >> and request the caller to run the command again with additional command >> line option that would explicitly provide the the name of the root CA. >> >> Will that help? > > That would be any time there's more than one CA in the trust chain. > Is it worth special-casing this? Are there real-world deployments that > only use one CA? Note that in this case you can just use a single-cert > PKCS#12 plus a PEM file for the CA, which is simple enough IMO. > So my point is that why we can't say that we support only a single-cert PKCS#12 file plus a
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/10/2013 05:34 PM, Dmitri Pal wrote: On 06/10/2013 09:56 AM, Petr Viktorin wrote: On 06/10/2013 03:35 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 06/10/2013 05:54 AM, Jan Cholasta wrote: On 7.6.2013 15:36, John Dennis wrote: On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. Well, that's not a necessary requirement. A tester did have a bit of trouble creating a PKCS#12 file with both the server cert and the CA cert, but the trouble is comparable to having to create a PEM file. 2. Because previous attempts to figure out the nickname of the signing CA was problematic. This is the main reason. It could be done, but I believe we should avoid any guessing to determine the root of trust. I am not sure I get it. So we inspect the certificate PKCS#12 file and there can be ambiguity about the root of trust. How? This part is not clear to me. Sorry for being slow here. Can someone explain it in more details? A PKCS#12 file can contain any number of arbitrary certificates (or other objects). There is already some ambiguity in determining which cert to use for the server. Here we error out if we don't find exactly one cert with appropriate usage flags. The root CA cert can be the one that signed the server cert (the only scenario that works now), or it can be any one along the chain. If you have an intermediate CA signed by a well-known authority, you would probably not want to trust *everything* signed by that authority; you'd want to trust "your" root CA which can be anywhere along the chain. If we exclude scenarios with Intermediate CAs (which don't currently work), the situation is much simpler, but we don't want to limit the CLI to that. Note that users can't usually carefully control what's inside the PKCS#12 file: the tools will typically allow generating a file with either only one cert, or with the entire chain. Regardless... If something can't be reliably determined then we should probably do following: If we have any issues with determining the root of trust we should fail and request the caller to run the command again with additional command line option that would explicitly provide the the name of the root CA. Will that help? That would be any time there's more than one CA in the trust chain. Is it worth special-casing this? Are there real-world deployments that only use one CA? Note that in this case you can just use a single-cert PKCS#12 plus a PEM file for the CA, which is simple enough IMO. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/10/2013 09:56 AM, Petr Viktorin wrote: > On 06/10/2013 03:35 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 06/10/2013 05:54 AM, Jan Cholasta wrote: On 7.6.2013 15:36, John Dennis wrote: > On 06/07/2013 09:26 AM, Jan Cholasta wrote: >> On 7.6.2013 15:17, John Dennis wrote: >>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. >>> >>> That doesn't sound right. Do we understand why a chain length > >>> 1 is >>> failing? >>> >> >> LDAP utilities and python-ldap only trust certificates directly >> issued >> by CAs you point them to (at least on Fedora 18). > > This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto > provider). > Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, > not upstream, we're the maintainers of MozLDAP and upstream is > already > frustrated with it. > I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza >>> If the options does not work we should hide it for now and clearly >>> state >>> in the docs and man pages that the case when certs come from different >>> CA is not supported for the time being. >>> >> >> IIRC it was added for two reasons: >> >> 1. Because the CA is not required to be included in the PKCS#12 file. > > Well, that's not a necessary requirement. A tester did have a bit of > trouble creating a PKCS#12 file with both the server cert and the CA > cert, but the trouble is comparable to having to create a PEM file. > >> 2. Because previous attempts to figure out the nickname of the signing >> CA was problematic. > > This is the main reason. It could be done, but I believe we should > avoid any guessing to determine the root of trust. > I am not sure I get it. So we inspect the certificate PKCS#12 file and there can be ambiguity about the root of trust. How? This part is not clear to me. Sorry for being slow here. Can someone explain it in more details? Regardless... If something can't be reliably determined then we should probably do following: If we have any issues with determining the root of trust we should fail and request the caller to run the command again with additional command line option that would explicitly provide the the name of the root CA. Will that help? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/10/2013 03:35 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 06/10/2013 05:54 AM, Jan Cholasta wrote: On 7.6.2013 15:36, John Dennis wrote: On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. Well, that's not a necessary requirement. A tester did have a bit of trouble creating a PKCS#12 file with both the server cert and the CA cert, but the trouble is comparable to having to create a PEM file. 2. Because previous attempts to figure out the nickname of the signing CA was problematic. This is the main reason. It could be done, but I believe we should avoid any guessing to determine the root of trust. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
Dmitri Pal wrote: On 06/10/2013 05:54 AM, Jan Cholasta wrote: On 7.6.2013 15:36, John Dennis wrote: On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. 2. Because previous attempts to figure out the nickname of the signing CA was problematic. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/10/2013 05:54 AM, Jan Cholasta wrote: > On 7.6.2013 15:36, John Dennis wrote: >> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>> On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: > Yes, this is correct. The DS certificate must be directly signed > by the > CA trusted by IPA (specified by --root-ca-cert in > ipa-server-install), > there may be no intermediate CAs, because ldapsearch and friends and > python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? >>> >>> LDAP utilities and python-ldap only trust certificates directly issued >>> by CAs you point them to (at least on Fedora 18). >> >> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). >> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >> not upstream, we're the maintainers of MozLDAP and upstream is already >> frustrated with it. >> > > I have just tested with libldap compiled with OpenSSL on my Arch Linux > box, it does not work as well: > > $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H > ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W > -b '' -s base > ldap_start_tls: Connect error (-11) > additional info: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > (invalid CA certificate) > > For the record, this is what happens with NSS on Fedora: > > $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H > ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W > -b '' -s base > ldap_start_tls: Connect error (-11) > additional info: TLS error -8179:Peer's Certificate issuer is not > recognized. > > Honza > If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 7.6.2013 15:36, John Dennis wrote: On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 7.6.2013 15:23, Dmitri Pal wrote: On 06/07/2013 09:08 AM, Jan Cholasta wrote: On 7.6.2013 14:54, Dmitri Pal wrote: On 06/07/2013 08:26 AM, Martin Kosek wrote: On 06/07/2013 02:04 PM, Dmitri Pal wrote: On 06/07/2013 03:47 AM, freeipa wrote: #3668: CA-less install fails when intermediate CA is used -+- Reporter: jcholast | Owner: jcholast Type: defect |Status: assigned Priority: major | Milestone: 2013 Month 06 - Component: | June (3.2.x bug fixing) Installation | Version: Resolution: | Keywords: Blocked By: | Blocking: Tests Updated: 0 | Affects DOC: 0 Patch posted for review: 0 | Red Hat Bugzilla: Source: | Effort Type: Targeted feature: | Design link: Design review: 0 | Fedora test page: Chosen: | Needs UI design: -+- Release Notes: -+- Changes (by mkosek): * rhbz: 0 => Comment: We not support intermediate CAs for external CA install or CA-less install. Thus, this ticket cannot be easily solved extensive changes to the installer. Related to #3274 (Pilsner milestone). Moving back to triage to decide what to do about this ticket. So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA passed to IPA and the actual certs. My question is what prevents you to give IPA the certs from the direct parent. What is the use case or real world scenario where the parent certs are not available? Just trying to wrap my head. I have CA 1 and CA 2. CA 2 is a sub CA of 1. I have certs from CA 1 If I pass them to IPA but point to CA2 it would not work. OK The example can be that CA1 is a public CA and CA2 is my CA. But what prevents me from giving IPA the certs from CA2? Why would I try to give IPA certs from CA1? Do I understand the scenario correctly? Nothing is preventing you to give IPA certs from CA2, this works fine. The problem is that if you pass IPA certificates issued by CA2 and point it to CA1 at the same time, it does not work (despite having the complete trust chain). Honza But why would you do so? What would be the reason and business case? Why not to point to CA2? I'm not sure, but this is apparently why --root-ca-cert was added to ipa-server-install. If the CA that issued the server certificates should always be used as root CA in IPA, then --root-ca-cert is redundant. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 09:26 AM, Jan Cholasta wrote: On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 7.6.2013 15:17, John Dennis wrote: On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 09:08 AM, Jan Cholasta wrote: > On 7.6.2013 14:54, Dmitri Pal wrote: >> On 06/07/2013 08:26 AM, Martin Kosek wrote: >>> On 06/07/2013 02:04 PM, Dmitri Pal wrote: On 06/07/2013 03:47 AM, freeipa wrote: > #3668: CA-less install fails when intermediate CA is used > -+- > > Reporter: jcholast | Owner: jcholast > Type: defect |Status: assigned > Priority: major | Milestone: 2013 > Month 06 - >Component: | June (3.2.x bug fixing) >Installation | Version: > Resolution: | Keywords: > Blocked By: | Blocking: >Tests Updated: 0 | Affects DOC: 0 > Patch posted for review: 0 | Red Hat Bugzilla: > Source: | Effort Type: > Targeted feature: | Design link: >Design review: 0 | Fedora test page: > Chosen: | Needs UI design: > -+- > > Release Notes: > > > -+- > > Changes (by mkosek): > > * rhbz: 0 => > > > Comment: > > We not support intermediate CAs for external CA install or CA-less > install. Thus, this ticket cannot be easily solved extensive > changes to > the installer. Related to #3274 (Pilsner milestone). > > Moving back to triage to decide what to do about this ticket. > So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? >>> No, this is a case when a CA you pass for FreeIPA is not a direct >>> "parent" of >>> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between >>> the CA >>> passed to IPA and the actual certs. >> >> My question is what prevents you to give IPA the certs from the direct >> parent. What is the use case or real world scenario where the parent >> certs are not available? >> Just trying to wrap my head. >> >> I have CA 1 and CA 2. CA 2 is a sub CA of 1. >> I have certs from CA 1 >> If I pass them to IPA but point to CA2 it would not work. OK >> The example can be that CA1 is a public CA and CA2 is my CA. But what >> prevents me from giving IPA the certs from CA2? Why would I try to give >> IPA certs from CA1? >> >> Do I understand the scenario correctly? >> > > Nothing is preventing you to give IPA certs from CA2, this works fine. > > The problem is that if you pass IPA certificates issued by CA2 and > point it to CA1 at the same time, it does not work (despite having the > complete trust chain). > > Honza > But why would you do so? What would be the reason and business case? Why not to point to CA2? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 08:57 AM, Jan Cholasta wrote: Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? John ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 7.6.2013 14:54, Dmitri Pal wrote: On 06/07/2013 08:26 AM, Martin Kosek wrote: On 06/07/2013 02:04 PM, Dmitri Pal wrote: On 06/07/2013 03:47 AM, freeipa wrote: #3668: CA-less install fails when intermediate CA is used -+- Reporter: jcholast | Owner: jcholast Type: defect |Status: assigned Priority: major | Milestone: 2013 Month 06 - Component: | June (3.2.x bug fixing) Installation | Version: Resolution: | Keywords: Blocked By: | Blocking: Tests Updated: 0 | Affects DOC: 0 Patch posted for review: 0 | Red Hat Bugzilla: Source: | Effort Type: Targeted feature: | Design link: Design review: 0 | Fedora test page: Chosen: | Needs UI design: -+- Release Notes: -+- Changes (by mkosek): * rhbz: 0 => Comment: We not support intermediate CAs for external CA install or CA-less install. Thus, this ticket cannot be easily solved extensive changes to the installer. Related to #3274 (Pilsner milestone). Moving back to triage to decide what to do about this ticket. So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA passed to IPA and the actual certs. My question is what prevents you to give IPA the certs from the direct parent. What is the use case or real world scenario where the parent certs are not available? Just trying to wrap my head. I have CA 1 and CA 2. CA 2 is a sub CA of 1. I have certs from CA 1 If I pass them to IPA but point to CA2 it would not work. OK The example can be that CA1 is a public CA and CA2 is my CA. But what prevents me from giving IPA the certs from CA2? Why would I try to give IPA certs from CA1? Do I understand the scenario correctly? Nothing is preventing you to give IPA certs from CA2, this works fine. The problem is that if you pass IPA certificates issued by CA2 and point it to CA1 at the same time, it does not work (despite having the complete trust chain). Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 7.6.2013 14:26, Martin Kosek wrote: On 06/07/2013 02:04 PM, Dmitri Pal wrote: On 06/07/2013 03:47 AM, freeipa wrote: #3668: CA-less install fails when intermediate CA is used -+- Reporter: jcholast | Owner: jcholast Type: defect |Status: assigned Priority: major | Milestone: 2013 Month 06 - Component: | June (3.2.x bug fixing) Installation | Version: Resolution: | Keywords: Blocked By: | Blocking: Tests Updated: 0 | Affects DOC: 0 Patch posted for review: 0 | Red Hat Bugzilla: Source: | Effort Type: Targeted feature: | Design link: Design review: 0 | Fedora test page: Chosen: | Needs UI design: -+- Release Notes: -+- Changes (by mkosek): * rhbz: 0 => Comment: We not support intermediate CAs for external CA install or CA-less install. Thus, this ticket cannot be easily solved extensive changes to the installer. Related to #3274 (Pilsner milestone). Moving back to triage to decide what to do about this ticket. So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA passed to IPA and the actual certs. It should not mean that the root CA you pass to IPA must be necessarily a root CA of the entire chain. Jan, is this correct? Can you elaborate? Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 08:26 AM, Martin Kosek wrote: > On 06/07/2013 02:04 PM, Dmitri Pal wrote: >> On 06/07/2013 03:47 AM, freeipa wrote: >>> #3668: CA-less install fails when intermediate CA is used >>> -+- >>>Reporter: jcholast | Owner: jcholast >>>Type: defect |Status: assigned >>>Priority: major | Milestone: 2013 Month 06 - >>> Component: | June (3.2.x bug fixing) >>> Installation | Version: >>> Resolution: | Keywords: >>> Blocked By: | Blocking: >>> Tests Updated: 0 | Affects DOC: 0 >>> Patch posted for review: 0 | Red Hat Bugzilla: >>> Source: | Effort Type: >>>Targeted feature: | Design link: >>> Design review: 0 | Fedora test page: >>> Chosen: | Needs UI design: >>> -+- >>> Release Notes: >>> >>> >>> -+- >>> Changes (by mkosek): >>> >>> * rhbz: 0 => >>> >>> >>> Comment: >>> >>> We not support intermediate CAs for external CA install or CA-less >>> install. Thus, this ticket cannot be easily solved extensive changes to >>> the installer. Related to #3274 (Pilsner milestone). >>> >>> Moving back to triage to decide what to do about this ticket. >>> >> So you are saying that CA we chain to or get the certs from should >> always be a root CA? >> Why does it matter for our code whether the CA we deal with a Root CA or >> not? > No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of > HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA > passed to IPA and the actual certs. My question is what prevents you to give IPA the certs from the direct parent. What is the use case or real world scenario where the parent certs are not available? Just trying to wrap my head. I have CA 1 and CA 2. CA 2 is a sub CA of 1. I have certs from CA 1 If I pass them to IPA but point to CA2 it would not work. OK The example can be that CA1 is a public CA and CA2 is my CA. But what prevents me from giving IPA the certs from CA2? Why would I try to give IPA certs from CA1? Do I understand the scenario correctly? > > It should not mean that the root CA you pass to IPA must be necessarily a root > CA of the entire chain. Jan, is this correct? Can you elaborate? > >> If we are trying to say that we do not follow the chains of trust I can >> understand that. So the limitation is that we should always be given the >> certs from the same CA we chain to and not its sub CA's, right? That >> makes sense. >> >> Can someone describe a use case where in real life the certs would come >> from one CA in the chain but we would be told to chain or use a sub CA >> of that CA. That seems strange. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 02:04 PM, Dmitri Pal wrote: > On 06/07/2013 03:47 AM, freeipa wrote: >> #3668: CA-less install fails when intermediate CA is used >> -+- >>Reporter: jcholast | Owner: jcholast >>Type: defect |Status: assigned >>Priority: major | Milestone: 2013 Month 06 - >> Component: | June (3.2.x bug fixing) >> Installation | Version: >> Resolution: | Keywords: >> Blocked By: | Blocking: >> Tests Updated: 0 | Affects DOC: 0 >> Patch posted for review: 0 | Red Hat Bugzilla: >> Source: | Effort Type: >>Targeted feature: | Design link: >> Design review: 0 | Fedora test page: >> Chosen: | Needs UI design: >> -+- >> Release Notes: >> >> >> -+- >> Changes (by mkosek): >> >> * rhbz: 0 => >> >> >> Comment: >> >> We not support intermediate CAs for external CA install or CA-less >> install. Thus, this ticket cannot be easily solved extensive changes to >> the installer. Related to #3274 (Pilsner milestone). >> >> Moving back to triage to decide what to do about this ticket. >> > So you are saying that CA we chain to or get the certs from should > always be a root CA? > Why does it matter for our code whether the CA we deal with a Root CA or > not? No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA passed to IPA and the actual certs. It should not mean that the root CA you pass to IPA must be necessarily a root CA of the entire chain. Jan, is this correct? Can you elaborate? > If we are trying to say that we do not follow the chains of trust I can > understand that. So the limitation is that we should always be given the > certs from the same CA we chain to and not its sub CA's, right? That > makes sense. > > Can someone describe a use case where in real life the certs would come > from one CA in the chain but we would be told to chain or use a sub CA > of that CA. That seems strange. What am I missing? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used
On 06/07/2013 03:47 AM, freeipa wrote: > #3668: CA-less install fails when intermediate CA is used > -+- >Reporter: jcholast | Owner: jcholast >Type: defect |Status: assigned >Priority: major | Milestone: 2013 Month 06 - > Component: | June (3.2.x bug fixing) > Installation | Version: > Resolution: | Keywords: > Blocked By: | Blocking: > Tests Updated: 0 | Affects DOC: 0 > Patch posted for review: 0 | Red Hat Bugzilla: > Source: | Effort Type: >Targeted feature: | Design link: > Design review: 0 | Fedora test page: > Chosen: | Needs UI design: > -+- > Release Notes: > > > -+- > Changes (by mkosek): > > * rhbz: 0 => > > > Comment: > > We not support intermediate CAs for external CA install or CA-less > install. Thus, this ticket cannot be easily solved extensive changes to > the installer. Related to #3274 (Pilsner milestone). > > Moving back to triage to decide what to do about this ticket. > So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? If we are trying to say that we do not follow the chains of trust I can understand that. So the limitation is that we should always be given the certs from the same CA we chain to and not its sub CA's, right? That makes sense. Can someone describe a use case where in real life the certs would come from one CA in the chain but we would be told to chain or use a sub CA of that CA. That seems strange. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
