Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 02.10.2013 13:10, Simo Sorce wrote: - Original Message - On 1.10.2013 22:08, Rob Crittenden wrote: Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. I was thinking about using algorithm like this when SSSD receives the request: if certs in cache: if cache last update time + delta now: if certs were update on server: # lastUSN check remove certs from cache else: cache last update time = now if certs not in cache: get certs from server store certs in cache cache last update time = now return certs in cache The delta would be a configurable option, defaulting to some reasonable value (1 hour? more? less?) For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? Something in between - the module would request the certificates from SSSD when a PKCS#11 session is opened and keep them in memory until the session is closed. The point is to always have the same data between PKCS#11 object management calls. How often will this cert change, after all? Not often. Why? What would the load be like? Is it fatal if the cert can't be obtained? The module could either return an error to the user when the certs can't be obtained, or return whatever is in the cache. I'm not sure which is better, but I'm leaning towards returning whatever is in the cache, since this must work even when the client system is offline. I think the cache should just be ca.crt files though, in this case, not the ldb modules cache. As some people wipe it out for various reasons. The main issue here is a chicken-egg issue if you are using LDAP(S) to connect to the server and you ned the CA cert to validate the server cert. You do not want to lock yourself out by wiping valid ca certs. Then you can just add them to the p11-kit-trust module using the trust tool (or I could build an API for that): # trust anchor --store /path/to/ca.crt By the way, even with PKCS#11, just having the certificates in place, it's also necessary to add the appropriate trust flags and so on so that these are trusted as anchors. The above also handles callers that don't yet support PKCS#11 for accessing trusted anchors. Cheers, Stef
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 3.10.2013 09:41, Stef Walter wrote: On 02.10.2013 13:10, Simo Sorce wrote: - Original Message - On 1.10.2013 22:08, Rob Crittenden wrote: Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. I was thinking about using algorithm like this when SSSD receives the request: if certs in cache: if cache last update time + delta now: if certs were update on server: # lastUSN check remove certs from cache else: cache last update time = now if certs not in cache: get certs from server store certs in cache cache last update time = now return certs in cache The delta would be a configurable option, defaulting to some reasonable value (1 hour? more? less?) For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? Something in between - the module would request the certificates from SSSD when a PKCS#11 session is opened and keep them in memory until the session is closed. The point is to always have the same data between PKCS#11 object management calls. How often will this cert change, after all? Not often. Why? What would the load be like? Is it fatal if the cert can't be obtained? The module could either return an error to the user when the certs can't be obtained, or return whatever is in the cache. I'm not sure which is better, but I'm leaning towards returning whatever is in the cache, since this must work even when the client system is offline. I think the cache should just be ca.crt files though, in this case, not the ldb modules cache. As some people wipe it out for various reasons. The main issue here is a chicken-egg issue if you are using LDAP(S) to connect to the server and you ned the CA cert to validate the server cert. You do not want to lock yourself out by wiping valid ca certs. My plan was to synchronize the certificates from SSSD to IPA files (/etc/ipa/ca.crt, /etc/pki/nssdb, /etc/httpd/alias, /etc/dirsrv/slapd-REALM) periodically and do it only if the SSSD cache is valid, i.e. when it is not empty and a successful attempt to retrieve the certificates from server was made. This means that if the user deleted the cache, the certificates would still be there in the files. Then you can just add them to the p11-kit-trust module using the
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 1.10.2013 22:08, Rob Crittenden wrote: Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. I was thinking about using algorithm like this when SSSD receives the request: if certs in cache: if cache last update time + delta now: if certs were update on server: # lastUSN check remove certs from cache else: cache last update time = now if certs not in cache: get certs from server store certs in cache cache last update time = now return certs in cache The delta would be a configurable option, defaulting to some reasonable value (1 hour? more? less?) For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? Something in between - the module would request the certificates from SSSD when a PKCS#11 session is opened and keep them in memory until the session is closed. The point is to always have the same data between PKCS#11 object management calls. How often will this cert change, after all? Not often. Why? What would the load be like? Is it fatal if the cert can't be obtained? The module could either return an error to the user when the certs can't be obtained, or return whatever is in the cache. I'm not sure which is better, but I'm leaning towards returning whatever is in the cache, since this must work even when the client system is offline. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
- Original Message - On 1.10.2013 22:08, Rob Crittenden wrote: Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. I was thinking about using algorithm like this when SSSD receives the request: if certs in cache: if cache last update time + delta now: if certs were update on server: # lastUSN check remove certs from cache else: cache last update time = now if certs not in cache: get certs from server store certs in cache cache last update time = now return certs in cache The delta would be a configurable option, defaulting to some reasonable value (1 hour? more? less?) For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? Something in between - the module would request the certificates from SSSD when a PKCS#11 session is opened and keep them in memory until the session is closed. The point is to always have the same data between PKCS#11 object management calls. How often will this cert change, after all? Not often. Why? What would the load be like? Is it fatal if the cert can't be obtained? The module could either return an error to the user when the certs can't be obtained, or return whatever is in the cache. I'm not sure which is better, but I'm leaning towards returning whatever is in the cache, since this must work even when the client system is offline. I think the cache should just be ca.crt files though, in this case, not the ldb modules cache. As some people wipe it out for various reasons. The main issue here is a chicken-egg issue if you are using LDAP(S) to connect to the server and you ned the CA cert to validate the server cert. You do not want to lock yourself out by wiping valid ca certs. Simo. -- Simo Sorce * Red Hat, Inc. * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 01.10.2013 12:32, Jan Cholasta wrote: On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? This sounds like the right approach to me. I've written several PKCS#11 modules, and am willing to help with a starter implementation, if that's needed. Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
- Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. Simo. -- Simo Sorce * Red Hat, Inc. * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 01.10.2013 21:57, Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. I sorta imagined it would use the sssd cache, and pull the data via sssd. Is that what you guys thought? Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
Simo Sorce wrote: - Original Message - On 13.9.2013 11:05, Jan Cholasta wrote: On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? How often will this cert change, after all? What would the load be like? Is it fatal if the cert can't be obtained? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Honza So, does anyone have any strong opinions on this? -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Thu, Sep 05, 2013 at 10:28:36AM +0200, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Honza Sorry, didn't notice the sssd keyword until now. Yes, we re-check and update domains every 30 seconds and right after startup as well. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 13.9.2013 10:53, Martin Kosek wrote: On 09/13/2013 10:51 AM, Jan Cholasta wrote: On 5.9.2013 10:28, Jan Cholasta wrote: On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? Yes. Honza So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Tue, Sep 10, 2013 at 11:10:25AM -0400, Dmitri Pal wrote: Regarding SNI, it apparently is not supported in server-side NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) We need to either push for a solution to this or allow to switch to mod_ssl. Jan Pazdziora investigated us switching to mod_ssl. It is not trivial. But to achieve the basic functionality, it was not awfully hard either: https://wiki.idm.lab.bos.redhat.com/export/idmwiki/IPA/Integration/mod_nss_ssl -- 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] Multiple CA certificates in LDAP, questions
On 9.9.2013 17:54, Simo Sorce wrote: On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: Jan Cholasta wrote: On 9.9.2013 16:02, John Dennis wrote: On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. We've fielded questions from people wanting to replace the cert in the web server even while maintaining the IPA CA. Granted this was prior to the CA-less option. The impetus seems to be not requiring all users to trust the IPA CA. I think if that became easier then wanting to use another CA would be less of an issue. And I really think this would be better served with an SNI setup, where we have 2 SSL certs for the web server only (a public one and an IPA one). While everything else must use the IPA CA, esp for PKINIT. What if there is no IPA CA (CA-less)? Should we assume that the user has their own CA in control and allow only certs signed by that single CA? Regarding SNI, it apparently is not supported in server-side NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) and Python 2.x (http://bugs.python.org/issue5639). These seem like blockers to me, correct me if I'm wrong. Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Tue, 2013-09-10 at 10:30 +0200, Jan Cholasta wrote: On 9.9.2013 17:54, Simo Sorce wrote: On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: Jan Cholasta wrote: On 9.9.2013 16:02, John Dennis wrote: On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. We've fielded questions from people wanting to replace the cert in the web server even while maintaining the IPA CA. Granted this was prior to the CA-less option. The impetus seems to be not requiring all users to trust the IPA CA. I think if that became easier then wanting to use another CA would be less of an issue. And I really think this would be better served with an SNI setup, where we have 2 SSL certs for the web server only (a public one and an IPA one). While everything else must use the IPA CA, esp for PKINIT. What if there is no IPA CA (CA-less)? Should we assume that the user has their own CA in control and allow only certs signed by that single CA? Regarding SNI, it apparently is not supported in server-side NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) We need to either push for a solution to this or allow to switch to mod_ssl. and Python 2.x (http://bugs.python.org/issue5639). This issue seem for python 3.2, do we actually use python code to perform SSL connections to HTTP servers ? I am not sure we do. These seem like blockers to me, correct me if I'm wrong. Yes they are blockers, so we need to either solve them ourselves or work around. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/10/2013 08:49 AM, Simo Sorce wrote: What if there is no IPA CA (CA-less)? Should we assume that the user has their own CA in control and allow only certs signed by that single CA? Regarding SNI, it apparently is not supported in server-side NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) We need to either push for a solution to this or allow to switch to mod_ssl. Jan Pazdziora investigated us switching to mod_ssl. It is not trivial. Also I would check with Kai. Based on his last comment in the bug there might be some work happening there. -- 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] Multiple CA certificates in LDAP, questions
Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. Seem very complicated. At most I would see as sort of useful to be able to set a different CA just for HTTP (due to default browsers list of CA), but not for anything else. But for this case I would rather write instructions on how to create a frontend on a *different* server, that just proxies in all requests to FreeIPA, just for people that want to use browsers w/o distributing the FreeIPA CA cert. That will solve their problem w/o complicating ours. We could also explain how to configure SNI (easier than proxy, but depends on whether mod_nss supports it, mod_ssl does), so that people can use a public cert with a 'public' name and keep FreeIPA own certs for internal management and joins etc... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. If you've got an external CA you still effectively have one trust anchor that can be revoked because we create a sub-CA from the external CA. Or perhaps I misunderstood what you were suggesting. -- John ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 9.9.2013 15:36, Simo Sorce wrote: On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. Seem very complicated. Well, code-wise it isn't very complicated, actually it's what I have now. I'm just pondering whether to put it in the final design or not. At most I would see as sort of useful to be able to set a different CA just for HTTP (due to default browsers list of CA), but not for anything else. But for this case I would rather write instructions on how to create a frontend on a *different* server, that just proxies in all requests to FreeIPA, just for people that want to use browsers w/o distributing the FreeIPA CA cert. That will solve their problem w/o complicating ours. It seems we are talking about slightly different perspectives on the issue. Consider the following situation: User wants to install new HTTP certificate using ipa-server-certinstall. Currently, the certificate must be signed by the CA that was used for IPA install (be it IPA CA or CA-less). In https://fedorahosted.org/freeipa/ticket/3641 it was requested that the CA cert of the HTTP cert should be uploaded to LDAP (and as a result, distributed to clients). Should this be allowed? If it should, should the newly uploaded CA cert be trusted to issue only HTTP certs, or any (HTTP/LDAP/PKINIT) certs? We could also explain how to configure SNI (easier than proxy, but depends on whether mod_nss supports it, mod_ssl does), so that people can use a public cert with a 'public' name and keep FreeIPA own certs for internal management and joins etc... Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 9.9.2013 16:05, John Dennis wrote: On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. If you've got an external CA you still effectively have one trust anchor that can be revoked because we create a sub-CA from the external CA. Or perhaps I misunderstood what you were suggesting. Don't forget about CA-less, you can theoretically have more than one trust anchor in that case. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote: On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. If you've got an external CA you still effectively have one trust anchor that can be revoked because we create a sub-CA from the external CA. Or perhaps I misunderstood what you were suggesting. My main concern is that the external CA, having issued one sub CA to us, can do so again for another customer, and trusting certificates because they chain up to that CA also allows that CA's other clients to issue certificates that we'd then also automatically trust. We can't revoke such certificates (which is done by noting the combination of issuer and serial number) until we know about them, and we'll only know about one of them after someone's used it to attempt to authenticate, possibly successfully. Cheers, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/09/2013 10:24 AM, Nalin Dahyabhai wrote: On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote: On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. If you've got an external CA you still effectively have one trust anchor that can be revoked because we create a sub-CA from the external CA. Or perhaps I misunderstood what you were suggesting. My main concern is that the external CA, having issued one sub CA to us, can do so again for another customer, and trusting certificates because they chain up to that CA also allows that CA's other clients to issue certificates that we'd then also automatically trust. We can't revoke such certificates (which is done by noting the combination of issuer and serial number) until we know about them, and we'll only know about one of them after someone's used it to attempt to authenticate, possibly successfully. Good point. Isn't there an X509 extension (possibly part of PKIX?) which restricts membership in the chain path to a criteria. In other words you can require your sub-CA to be present in the chain. Sorry, but my memory is a bit fuzzy on this. -- John ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 9.9.2013 16:02, John Dennis wrote: On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
Jan Cholasta wrote: On 9.9.2013 16:02, John Dennis wrote: On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. We've fielded questions from people wanting to replace the cert in the web server even while maintaining the IPA CA. Granted this was prior to the CA-less option. The impetus seems to be not requiring all users to trust the IPA CA. I think if that became easier then wanting to use another CA would be less of an issue. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. -- John ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, 2013-09-09 at 16:19 +0200, Jan Cholasta wrote: On 9.9.2013 15:36, Simo Sorce wrote: On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. Seem very complicated. Well, code-wise it isn't very complicated, actually it's what I have now. I'm just pondering whether to put it in the final design or not. At most I would see as sort of useful to be able to set a different CA just for HTTP (due to default browsers list of CA), but not for anything else. But for this case I would rather write instructions on how to create a frontend on a *different* server, that just proxies in all requests to FreeIPA, just for people that want to use browsers w/o distributing the FreeIPA CA cert. That will solve their problem w/o complicating ours. It seems we are talking about slightly different perspectives on the issue. Consider the following situation: User wants to install new HTTP certificate using ipa-server-certinstall. Currently, the certificate must be signed by the CA that was used for IPA install (be it IPA CA or CA-less). In https://fedorahosted.org/freeipa/ticket/3641 it was requested that the CA cert of the HTTP cert should be uploaded to LDAP (and as a result, distributed to clients). Should this be allowed? If it should, should the newly uploaded CA cert be trusted to issue only HTTP certs, or any (HTTP/LDAP/PKINIT) certs? See the point below, the reason people want to use a cert is to avoid the hassle of installing a private CA on web browser for all users (that may have personal machine, tablets and whatnot. I think the solution is to change the way we tell them to do it. Instead of installing a separate set of public certs, allow SNI setup and have them create a separate name for public use. It will make for a much better/easier experience for all involved and will keep the whole solution more secure wrt Nalin concerns for example. We could also explain how to configure SNI (easier than proxy, but depends on whether mod_nss supports it, mod_ssl does), so that people can use a public cert with a 'public' name and keep FreeIPA own certs for internal management and joins etc... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: Good point. Isn't there an X509 extension (possibly part of PKIX?) which restricts membership in the chain path to a criteria. In other words you can require your sub-CA to be present in the chain. Sorry, but my memory is a bit fuzzy on this. If you're talking about Name Constraints, they seem to be geared more toward allowing a CA to limit what a sub CA that it issues can be trusted to do, and not the other way around. I don't think I know of anything that deals with this that doesn't eventually end up setting up library-specific configuration for the library that's going to be verifying the certificate. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: Jan Cholasta wrote: On 9.9.2013 16:02, John Dennis wrote: On 09/09/2013 05:17 AM, Jan Cholasta wrote: Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. We've fielded questions from people wanting to replace the cert in the web server even while maintaining the IPA CA. Granted this was prior to the CA-less option. The impetus seems to be not requiring all users to trust the IPA CA. I think if that became easier then wanting to use another CA would be less of an issue. And I really think this would be better served with an SNI setup, where we have 2 SSL certs for the web server only (a public one and an IPA one). While everything else must use the IPA CA, esp for PKINIT. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
Aren't the implementations of name constrains generally buggy, and therefore not usable in real life? On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai na...@redhat.com wrote: On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: Good point. Isn't there an X509 extension (possibly part of PKIX?) which restricts membership in the chain path to a criteria. In other words you can require your sub-CA to be present in the chain. Sorry, but my memory is a bit fuzzy on this. If you're talking about Name Constraints, they seem to be geared more toward allowing a CA to limit what a sub CA that it issues can be trusted to do, and not the other way around. I don't think I know of anything that deals with this that doesn't eventually end up setting up library-specific configuration for the library that's going to be verifying the certificate. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
I would strongly argue for a separate CA list for PKINIT (service or workstation login) vice HTTP (web browsing of semi-unknown sites). The trust models are fundamentally different. In the former case you are saying who is allowed to issue (conceivably fraudulent) client certs that allow (conceivably fraudulent) users to access local services or workstations. In my case I have PIV cards with certs issued by one of a number of US Gov organizations that mostly trace to the Federal Bridge. Allowing certs issued by a hostile foreign government is clearly a very bad idea. In the latter case you are probably dealing with the a general desire to know that there is some attestation by someone that the web site you are visiting is actually what you intended. You may be visiting the web site of an agency of a hostile foreign government, in which case that government's CA is exactly what you want to trust. You might even want a control that prohibits any friendly CA from issuing certs for that web site. Large lists of trusted CAs represent attack surface, however convenient they may make some things. Whatever the defaults are, we need tools that allow us to model our actual trust for the specific operations we are performing. In an Enterprise environment accessing local services should only be allowed if they use the corresponding local CA. On Sep 9, 2013, at 7:02 AM, Nalin Dahyabhai na...@redhat.com wrote: On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. HTH, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On Mon, Sep 09, 2013 at 01:07:09PM -0700, Henry B. Hotz wrote: On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai na...@redhat.com wrote: On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: Good point. Isn't there an X509 extension (possibly part of PKIX?) which restricts membership in the chain path to a criteria. In other words you can require your sub-CA to be present in the chain. Sorry, but my memory is a bit fuzzy on this. If you're talking about Name Constraints, they seem to be geared more toward allowing a CA to limit what a sub CA that it issues can be trusted to do, and not the other way around. Aren't the implementations of name constrains generally buggy, and therefore not usable in real life? Yes, ISTR hearing that library support for them was not as widespread as I'd have hoped. There's also the secondary problem that the standards don't specify how to express Name Constraints on AnotherName values, for example Kerberos principal names. Though it's possible I just haven't found where that was done. Cheers, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. -- 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] Multiple CA certificates in LDAP, questions
On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
