On Tue, 22 Mar 2016, Fraser Tweedale wrote:
On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
Hi all,

Firstly, a big thank you to everyone who works on the FreeIPA project - you
guys are my heroes.

Let's talk about the new Certificate Profile and CA ACL feature and some use
cases that should be possible but I'm struggling to implement. Hopefully I'm
just missing something obvious, and if not, perhaps someone here can suggest
a workaround. I'll do my best to keep this as brief and concise as possible,
and I'm grateful for any help given.

Some background:

Our environment is composed of AWS EC2 instances running CentOS 7 (7.2.1511
+ ipa-server-4.2.0-15, fully patched afaik).
Our instances acquire three certificates during creation, which is achieved
via user-data/cloud-init. The first certificate is linked to service
principal puppet/$HOSTNAME, the second is linked to HTTP/$HOSTNAME, and the
third is the default NSS-based certificate linked to the host principal (via
ipa-client-install --request-cert).
We want our long-lived EC2 instances to acquire certificates using the
standard caIPAserviceCert profile. Examples would be database servers,
puppetmasters, etc.
We use EC2 spot instances via auto-scaling groups heavily - these are our
short-lived instances. For example, application servers, etc.
We want our short-lived instances to acquire certificates with a really
short validity (like 3 days). Read on to find out why.

Our applications login to their respective postgresql databases using mutual
SSL auth (i.e. IPA CA issued certificates). Sadly, postgresql has to be
restarted every time the CRL is updated (see section 17.9.2 of postgresql
doc). If the CRL expires, postgres stops authenticating clients via SSL.
This means we're forced to either turn off CRL checking in postgres entirely
or have really long CRL validity times - we're going to go with the latter.
It also means application servers will need to be issued with short-lived
certificates (and must not have access to the caIPAserviceCert profile)
because we can't realistically restart our production database servers every
time an application server's certificate gets revoked.

The use case:

1. Suppose we have a hostgroup called "database_servers" and a host called
"db01" that is a member.
3. Modify the default CA ACL "hosts_services_caIPAserviceCert" to restrict
access to the "database_servers" hostgroup only (i.e. no services or users
4. Attempt to request a certificate (via ipa-getcert) from the "db01" server
(which is in the "database_servers" hostgroup). The request should be linked
(via -K) to a service principal like postgres/$HOSTNAME (service to be
created beforehand).
5. This currently fails with CA_REJECTED ca-error: Server at
https://ipa.example.com/ipa/xml denied our request, giving up: 2100 (RPC
failed at server.  Insufficient access: Principal
'postgres/db01.example....@example.com' is not permitted to use CA '.' with
profile 'caIPAserviceCert' for certificate issuance.).

Is this the intended behaviour? If so, is there any way to avoid having to
add each and every individual service principal directly to the CA ACL?
After all, we have hostgroups to avoid the mess of adding individual hosts,
right? Well... each host would have several service principals...and we
don't seem to have a way of grouping them.

Thanks in advance,



This is expected behaviour.  The CA ACLs control which profiles may
be used with which subject principals, which in your use case is a
service principal.  Adding the host or hostgroup to the CA ACL does
not apply to service principals, even though the hostname may be the

For grouping services, FreeIPA currently does not have a "group"
object for service principals.  So at the moment, either every
applicable service must be added to the ACL, or you can allow all
services with the command: 'ipa caacl-mod <acl> --servicecat=all'.

I hope that explains the situation clearly.  Let me know your
follow-up questions!

To my fellow FreeIPA developers: are service groups a sensible RFE?
Is there a reason why they have not been implemented?
I don't think you need to group services this way. For managing
services, and this means being able to issue certificates/keytabs for
them, we have hosts. By default a host that a service belongs to is
capable to modify userCertificate attribute of the service already, so I
would expect it to be able to issue certificates with subject principal
corresponding to the service.

If CAACL would follow the same logic by allowing hosts that manage
services to issue certificates with subject principals corresponding to
these services, that should be enough because, after all, these host
objects already have write permissions and can upload whatever
certificates they like to the service objects.
/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to