On Mon, May 14, 2018 at 4:47 AM, Fraser Tweedale <ftweedal(a)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...
> >
> > 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