Per CS/DS Meeting of 08/03/2015: 10.2.7 (critical)

The following is a proposed method to get the desired behavior by changing the profile in question.
The mods suggested here will be on top of the mods detailed in ticket #1520.

Add the following change to the profile:

input.list=i1,i2
input.i1.class_id=keyGenInputImpl
input.i2.class_id=subjectNameInputImpl

Here just add the subjectNameInput to the form displayed to the user.

This allows the user to type in a bunch of field, of only the CN field will be used for now.

Make this mod on top of one suggested in ticket #5120

policyset.userCertSet.20.default.params.name=CN=$request.sn_cn$,e=$request.auth_token.mail[0]$,O=redhat.com

Note here we simply set the CN field to the CN typed in by the user. This string can be customized further to use more of the new fields the user is allowed to enter.

When I tried this, the nickname displayed in the Firefox cert viewer was the name typed in for the CN field during enrollment.

The case of directory authenticated users (where this feature is necessary), CN is being pulled from LDAP and that is what ends up as the NSS Friendly Name. Is there another field that can be used for Friendly Name?

In the line I suggested here:

policyset.userCertSet.20.default.params.name=CN=$request.sn_cn$

This piece here "CN=$request.sn_cn$" should be grabbing the name from the CN portion of the request.
As asked about in 1520, we can also get it from other fields in the request like "uid", but I will run a test to make sure.

The suggested profile change for this ticket should make the user be able to choose the value. See update to ticket #1520 for more info on this.

The issue here is one of profile flexibility and human ability to keep track of things.

If we put the suggested policyset.userCertSet.20.default.params.name=CN=$request.sn_cn$,e=$request.auth_token.mail[0]$,O=redhat.com in caECDirUserCert.cfg, it will work. But since CN is pulled from LDAP, every cert issued from this profile will appear the same to the user both in the Subject of the cert itself and in the FF cert store friendly name field.

People may want to create one cert for mobile, one cert for desktop, etc. This minimizes pain if they say loose their phone and we need to revoke a cert. I suppose we could make multiple profiles and tack on things like "default.params.name=CN=$request.sn_cn$ 's mobile cert" to accomplish what we want, but I think we were hoping for a generic situation where the end user appended stuff to the CN of DirAuth certs so they could create their own use cases instead of us narrowly defining a few.

Hi dminnich :

I totally understand your point there about not wanting it to get the value from ldap.

The line I showed above:

policyset.userCertSet.20.default.params.name=CN=$request.sn_cn$

Means that the value is taken from the "input" "Subject Name", which is typed in by the user, thus can be customized by the person using the form.

Previously the CN value was taken from the "auth token", which is derived from LDAP.
I tried it myself with a couple of custom values and it seemed to work, unless I was a little too sleepy at the time :)

Hope this helps,
thanks,
jack

Thanks Jack.

A mixture of the two bugs and some other stuff will get us what we need.

policyset.userCertSet.20.default.params.name=CN=$request.auth_token.cn[0]$ $request.sn_cn$,e=$request.auth_token.mail[0]$,UID=$request.auth_token.uid[0]$,OU=users,DC=redhat,DC=com

Will get the CN from LDAP and append the CN field from the form after it. I'll be looking into how to create a custom input form so we can remove the other fields and rename the CN one.

Feel free to close this ticket.

As discussed in the meeting, we have a solution for custom input.

The following sample I just tried worked fine, it can be changed:

Add a generic input plugin in place of the proposed Subject Name plugin:

input.i1.class_id=keyGenInputImpl
input.i2.class_id=genericInputImpl
input.i2.params.gi_display_name0=Certificate Friendly Name
input.i2.params.gi_num=1
input.i2.params.gi_param_enable0=true
input.i2.params.gi_param_name0=sn_cert_name
input.list=i1,i2

.....

policyset.userCertSet.20.default.params.name=CN=$request.sn_cert_name$,e=$request.auth_token.mail[0]$,O=redhat.com

The result is when the page renders it will give a bold label of "Generic Input" not sure that can be changed.

Then one field will show up titled "Certificate Friendly Name".
Type that in and the CN of the subject will have that value within.
The id of "sn_cert_name" will be inserted into the subject name's CN field.

Since this will most probably do the trick, closing the ticket as suggested. It can of course be re-opened if desired no problem.

Required no code changes in 10.2.6-5.

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2080

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.