Bug 448005 - AuthTokenSubjectNameDefault plugin derives SubjectName incorrectly
Summary: AuthTokenSubjectNameDefault plugin derives SubjectName incorrectly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Dogtag Certificate System
Classification: Retired
Component: Certificate Manager
Version: 1.0
Hardware: All
OS: Linux
urgent
low
Target Milestone: ---
Assignee: Ade Lee
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 443788
TreeView+ depends on / blocked
 
Reported: 2008-05-22 20:36 UTC by Aleksander Adamowski
Modified: 2015-01-04 23:32 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-05-01 20:39:53 UTC
Embargoed:


Attachments (Terms of Use)
suggested fix (needs verifying) (741 bytes, patch)
2008-05-22 20:36 UTC, Aleksander Adamowski
no flags Details | Diff
The proper patch (2.15 KB, patch)
2008-05-23 14:20 UTC, Aleksander Adamowski
no flags Details | Diff

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$

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


Note You need to log in before you can comment on or make changes to this bug.