Might be deferred even further.

I think it would be a good feature to have though...

An idea for easily supporting user profiles without changing any arguments is to look at the principal and determine what type of object it is. If it is a user object use a user profile, otherwise use the IPA server profile.

Changing 3.2 priority

Fraser works on this one.

Some postgresql requirements:

Postgres reads user name from CN field, so it must be possible to
have a client cert profile that can be used from IPA and puts identity
information there. (I have asked what datum is best - username, uid,
email, Kerberos principal, etc).

Hi Frasier/all,

When we generate service requests, we use certmonger, so the value we want to use will probably be in the CSR. I'm guessing dogtag can get the results from there.

So, please consider respecting the template specified in certmonger -T option.

My main need is to be able to distinguish one service's certificate from another's. Even if the services are on the same machine.

Currently, the subject is CN=$hostname,O=$realm. Which works well as a service, but not so well as a client. It would be nice if the service request had the kerberos principal or ldap fqdn or something programatic in it.

I'd prefer to use something that is a little unique. so something like $service@$realm or $service/$host@$realm vs $service.
Just let me know. I am calling certmonger with -K, I can also add -E. Did not look into accessing those variables from dogtag, but I did notice $email was used by some profiles.

It will take some time to extend postgres to be able to read a field other than CN from the certificate's subject. So in the shorter term, I would need to use username, uid, email, fqdn, or kerberos principal in the CN field.

But I think that is just trivial tweaking dogtag profiles from here.

EDIT: since the CN for the client certificate is potentially non-standard, we may want to generate a different csr/certificate for use as a client and for use as a service. CN=$principal for the client and CN=$hostname for the service.

Thanks

CloudForms use case:

• Multiple services exist on a host, and communicate with other services on other hosts.
• IPA can issue a server certificate to each service (existing capability).
• Each service also needs a client certificate for communicating with other services.
• The client certificate must contain information identify the service for which it was issued.
• FreeIPA must be updated to respect the -T <profileName> parameter sent by certmonger in
  order to be able to issue multiple certificates with different profiles for a single
  service principal.
• The ipa cert-request CLI command should be updated with an argument to select a
  profile (presumably the currently-hardcoded "caIPAserviceCert" would be preserved as a
  default)

Several updates to the web UI will be needed for full support of multiple profiles:

• The New Certificate dialog should include a field for specifying the profile (perhaps
  a drop-down selector of known/valid profiles)
• A way to view the different certificates issued for a principal (currently, View Certificate
  just shows the single service certificate issued for the principal).

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1200694

The CSR currently doesn't include the requested profile. I'm not sure there's a standard way of representing that information. The only method I've come across is the szOID_ENROLL_CERTTYPE_EXTENSION (a BMP String) that we'll sometimes see in certificates issued by an Active Directory CA, and while certmonger does read that for curiosity's sake, it currently doesn't add it as a requested extension value in CSRs.

If the intention on the server is to start retrieving the information from a request (either using this extension, or another one that's specific to IPA or Dogtag), certmonger can start adding it. If the intention is that a client should supply it as a parameter in the RPC call (as for the principal name), it can start supplying it. Any or all of the above, really, so long as whatever the new information is doesn't confuse older servers.

I'd like some guidance on what the server expectation is going to be, so that we can get started on providing something for you to test with.

master:

• 3d15f29 Add schema for certificate profiles
• 273a297 ipa-pki-proxy: provide access to profiles REST API
• 35af0d6 Add ACL to allow CA agent to modify profiles
• 300b74f Add certprofile plugin
• 4cf2bfc Add profile_id parameter to 'request_certificate'
• a931d3e Update cert-request to support user certs and profiles

master:

• bc0c606 Add CA ACL plugin
• 947af1a Enforce CA ACLs in cert-request command

The functionality is there. From now on, the feature is in bugfixing mode.

Tests:

master:

• 30f0a03 ipatests: add fuzzy instances for CA ACL DN and RDN
• 36f7074 ipatests: Add initial CAACLTracker implementation
• 897c9c9 tests: add test to check the default ACL
• 8d64485 ipatests: CA ACL - added config templates
• d2ff5e4 ipatests: added unlock_principal_password and change_principal
• 5ab0fca ipatests: CA ACL and cert profile functional test

ipa-4-2:

• 5aba3c7 ipatests: add fuzzy instances for CA ACL DN and RDN
• 438a29f ipatests: Add initial CAACLTracker implementation
• 127b109 tests: add test to check the default ACL
• b6193e8 ipatests: CA ACL - added config templates
• f1414fe ipatests: added unlock_principal_password and change_principal
• 21fed03 ipatests: CA ACL and cert profile functional test