[Freeipa-users] Certificate profiles and CA ACLs for service principals

[earsdown]

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 allowed).
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.com at 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,

~earsdown