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