On Mon, May 14, 2018 at 4:47 AM, Fraser Tweedale <ftwee...@redhat.com> wrote: > 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.
And only partly correct. Web UI shows all certificates. CLI, though, shows all certificates as a blob and details(issuer, serial number, ...) only for one certificate. Otherwise, management of multiple certs is in IPA since 4.2. https://www.freeipa.org/page/V4/User_Certificates - this was also the reason for the changed revocation behavior. For adding non-FreeIPA issued certs, there is: {host,service,user}-add-cert For removal: {host,service,user}-host-remove-cert Which for hosts and services also calls cert-revoke for certs with IPA CA or Sub-CA. This (revoke removed IPA issued cert) revocation behavior is also in {host,service}-mod. For displaying details of arbitrary cert, there is: $ ipa cert-find --certificate=CERTIFICATE (Which IMO should have been a separate command, but that is another discussion). > >> 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 -- Petr Vobornik _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
