We currently support a single certificate profile, for issuing server certs. If we are going to need to issue certificates for other profiles (e.g. tickets #53, 55) then we need to add the plumbing for that.
Profiles will be stored in Dogtag. A small amount of metadata will be stored in FreeIPA's directory to track these profiles, store their current state (enabled, disabled) and mapping to groups that are allowed to use the profile.
IPA must be modified to respect the profile parameter in requests from Certmonger (currently ignored).
Rich profile management (use of a command-line tool or Web UI to build new profiles for use with FreeIPA, rather than the presuppose the existence of a profile) can be implemented on top of the basic profiles support, if there is demand. At a minimum, there should be tutorials and improved documentation in Dogtag for how to define certificate profiles.
Related: #4002, #4752, #2915
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).
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.
CloudForms use case:
Several updates to the web UI will be needed for full support of multiple profiles:
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.
The functionality is there. From now on, the feature is in bugfixing mode.
Metadata Update from @rcritten:
- Issue assigned to ftweedal
- Issue set to the milestone: FreeIPA 4.2
to comment on this ticket.