example profile where the username is not extracted
caECDualCert.cfg

To reproduce in Firefox 39:

1. Hit dogtag, complete user cert request (https://dogtag:8443/ca/ee/ca/profileSelect?profileId=caECDirUserCert)

2. authenticate and import resulting certificate

3. In Firefox, go to Preferences -> Advanced -> Certificates -> View Certificates

4. When the cert window pops up, select 'Your Certificates', find the cert that has the Certificate Name: 's ${orgname} ID

5. Click 'Backup...' and export the cert

6. Find the resulting .p12 file on the filesystem and run 'pk12util -l ${certname}.p12

In the output you'll notice it has a the friendly name mangled, the same as in step 4.

Per meeting of 07/31/2015: 10.2.7

Per CS/DS Meeting of 08/03/2015: Raising priority to "critical".

While investigating this , cfu stated that she had a modified profile that give us better results. Will post the delta in case this solution would be usable.

Make the following additions/change to the two profiles in question:

policyset.userCertSet.list=20,10,2,3,4,5,6,7,8,9
policyset.userCertSet.20.constraint.class_id=noConstraintImpl
policyset.userCertSet.20.constraint.name=No Constraint
policyset.userCertSet.20.default.class_id=subjectNameDefaultImpl
policyset.userCertSet.20.default.name=Subject Name Default
policyset.userCertSet.20.default.params.name=CN=$request.auth_token.cn[0]$,e=$request.auth_token.mail[0]$,O=redhat.com

Note the stock profile has this:

policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9

We have replaced 1 with 20 and added the entries for 20.

Using this change the cert nickname will show up as the cn, I believe.

This like I"m sure can be tweaked for tuning the value output.

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

The profile changes you suggest work, but it looks like FriendlyName==CN. We'd like to be able to set the FriendlyName == UID. Is that possible?

Yes I believe, you can use the suggested change from #1521 and change it to this:

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

This requires of course enabling the "Subject Name" input. I will try it out myself to double check though.

OK, after further investigation this is the conclusion.

There is nothing the cert data on the server that has this nickname information. All indications point to the fact that the Mozilla cert importation code in Cert Manager is doing this.

It appears to be taking the value of CN= when displaying the cert in the cert list.

If you do a full view of the cert, you will also see the issuer's O= value involved.

The following bug for mozilla kind of confirms this theory:

https://bugzilla.mozilla.org/show_bug.cgi?id=667200

With my previous comment, we could make the CN value be that of what the UID is, but they will of course be the same for a given cert.

The conclusion is though, that we have done what can do from the server's perspective for this issue.

Thanks for the update and explanation.

When playing with this stuff yesterday, after believing that FN=CN, I did determine that I could make the FN=UID by setting CN=UID.

We will now have to determine if we want people certs to show up as First Last in Mozilla Cert store and have correct UID and CN info, or if we want improper CN in the cert so that the Mozilla Cert store will show the uid.

Confirmed that this is a FF thing and not a RHCS thing. Feel free to close this ticket.

Closing as suggested.

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/2079

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.