Bug 448005

Summary: AuthTokenSubjectNameDefault plugin derives SubjectName incorrectly
Product: [Retired] Dogtag Certificate System Reporter: Aleksander Adamowski <bugs-redhat>
Component: Certificate ManagerAssignee: Ade Lee <alee>
Status: CLOSED NOTABUG QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: urgent    
Version: 1.0CC: benl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-01 20:39:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 443788    
Attachments:
Description Flags
suggested fix (needs verifying)
none
The proper patch none

Description Aleksander Adamowski 2008-05-22 20:36:41 UTC 
I've noticed that with out LDAP directory, using the caDirUserCert profile, we
get incorrect SubjectNames - they aren't populated with requesting users'
commonName (cn) or e-mail (LDAP "mail" -> x.509 "E").

After closer inspection and brief analysis of Dogtag Certificate System's source
code I've identified that the authTokenSubjectNameDefaultImpl plugin is
responsible for this task and its implementation is in the
AuthTokenSubjectNameDefault class
(https://pki.fedoraproject.org/svn/pki/trunk/pki/base/common/src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java).

The problem seems to be in this code fragment (line 134):

X500Name name = new X500Name(
 request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME));

The plug-in uses the $request.authenticatedname$ value from the request, which
contains the authenticated user's DN. If the DN doesn't contain the cn and mail
attribute, those attributed won't be propagated to resulting certificate's
subject name.

I think this plugin should use the $request.auth_token.tokencertsubject$ value.
After all, the UidPwdDiraAuth plugin's documentation
(http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf) implies
that this value will be used to formulate the certificate's subject name:

"dnpattern:     Specifies a string representing a subject name pattern to
formulate from the
directory attributes and entry DN."

So the code should probably be change to something like this:

Index: src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java
===================================================================
--- src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java  
(revision 47)
+++ src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java   (working
copy)
@@ -131,7 +131,7 @@
        // to the certinfo
        try {
            X500Name name = new X500Name(
-                   
request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME));
+                    request.getExtDataInAuthToken(AuthToken.TOKEN_CERT_SUBJECT));

            info.set(X509CertInfo.SUBJECT, new CertificateSubjectName(name));
        } catch (Exception e) {


(note: I didn't test whether it works, I'd have to check out the whole >130MB
SVN repository and set up the complex Dogtag build infrastructure for this...)
Comment 1 Aleksander Adamowski 2008-05-22 20:36:41 UTC 
Created attachment 306421 [details]
suggested fix (needs verifying)
Comment 2 Aleksander Adamowski 2008-05-23 14:20:23 UTC 
Created attachment 306502 [details]
The proper patch

OK, so I've figured out how to build Dogtag sources and made some tests.

Obviously my patch was wrong (it was purely speculative guesswork anyway).

So I've made a patch that actually works, has been tested in a real
environment, and I'm attaching it.

Note that since the subjectName generation started working properly, now 
you'll have to customise the LDAP-based certificate profiles to accomodate this
(they were assuming the old incorrect DNs) - notably the "Subject Name
Constraint".

Dogtag's default profile has the following subject name constraint pattern:

UID=.*

While the subjectName generated by UidPwdDirAuth plugin look more like this by
default: "E=$attr.mail, CN=$attr.cn, O=$dn.o, C=$dn.c" so they won't ever match
the constraint's pattern since they cannot possibly begin with "UID=".

In my configuration, I've changed the pattern to this and the new LDAP-based
subject names got accepted:

.*CN=.*


So in short, my caDirUserCert.cfg has the following now:

...
policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.userCertSet.1.constraint.name=Subject Name Constraint
policyset.userCertSet.1.constraint.params.pattern=.*CN=.*
policyset.userCertSet.1.constraint.params.accept=true
...

instead of:

...
policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.userCertSet.1.constraint.name=Subject Name Constraint
policyset.userCertSet.1.constraint.params.pattern=UID=.*
policyset.userCertSet.1.constraint.params.accept=true
...
Comment 3 Aleksander Adamowski 2008-08-01 15:01:42 UTC 
BTW, I'm a member of the cla_done group (see
https://bugzilla.redhat.com/show_bug.cgi?id=442228#c6 for confirmation by rmeggins).

If you find this patch to be correct, please commit it. It has certainly fixed
the problem for us.
Comment 5 Ade Lee 2009-05-01 20:39:53 UTC 
This is not a bug.

Please refer to the following section in the CS 7.3 Admin Guide

http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/index.html


******************
Section 13.7.20 (Subject Name Default)

If you need to get a certificate subject name that uses the DNPATTERN value
from the UidPwdDirAuth plugin, then configure the profile to use the Subject
Name Default plugin and substitute the Name parameter with the "Subject Name"
from the AuthToken as shown below.

policyset.userCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.userCertSet.1.default.name=Subject Name Default
policyset.userCertSet.1.default.params.name=$request.auth_token.tokenCertSubject$

******************