On Fri, May 11, 2018 at 01:52:57PM -0400, Rob Crittenden via FreeIPA-devel wrote: > Simo Sorce wrote: > > On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel > > wrote: > > > Hi all, > > > > > > Ticket https://pagure.io/freeipa/issue/7482 made me think about the > > > current revocation behaviour in `ipa cert-request`. For hosts and > > > services, all old certificates get revoked. > > > > > > I wrote a blog post[1] outlining the problems with the current > > > behaviour, and some suggested changes. I'd like to know others' > > > thoughts. If we go ahead it would be something for a major release, > > > not a bugfix release. The actual amount of work is pretty small. > > > > > > [1] > > > https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and-revocation.html > > > > I'd prefer no revocation by default, if people need two+ certs with the > > same name they should be able to do so easily (for example for > > clustered services that need to answer as a single machine). > > Multiple certs is fine but the convention to date has been one cert per > service so that usage can be more easily tracked. If they want that can have > a single cert and share it everywhere but then things are more opaque and > the systems harder to manage. You can't easily answer the question "What TLS > services are we running on bob?" > > I can't quite get my head around Fraser's scenario Certificate for new > purpose (non-renewal). New purpose for the same service? Do you have any > examples of that? > (Not a concrete example, but anyway...) Some service principal needs a TLS server certificate, and a client certificate to connect to some backend service, which needs a special Extended Key Usage value (or whatever).
> Beyond the fact that we'll have to come up with some other scheme to sift > the database looking for expired certs to remove from usercertificate. > We already have a ticket to add a command (or command options) for pruning expired certs: https://pagure.io/freeipa/issue/7219 We could add it to the certmonger helper to get automatic pruning for certmonger-tracked certs. > Remember that storing usercertificate in host/service entries provides > really no value whatsoever except to pin the fact that the service has a > certificate at all. So being able to store 0, 1 or more doesn't really buy > you a lot unless you are using these services to bind as clients. > Do we know what customer expectations are around this? (BTW, whether to store issued certs in principal's userCertificate attribute is a profile-specific configuration). > Even now when you display a service it provides the details for only ONE > certificate. > That's a bug IMO. > user certs are another story altogether and not covered here. > > > It also fills a CRL list for no good reasons, we should be conservative > > on CRL size, and if someone has a dynamic environment where hosts are > > created and destroyed frequently the CRL could become enormous. > > Sure, assuming they actually use the CRL or OCSP. > > I'd be ok making it a config option. > > I think I'd rather not extend the cert-request API for the revocation case > and use post-command scripts to do it instead. This is an IPA policy so it > should live within IPA. > Fair enough. I didn't feel strongly either way. Rob & Simo, thanks for your feedback! I'll write up a proper design proposal later this week. Thanks, Fraser _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
