[Pki-users] DogTag 1.3 and Subject Alternate Name

Gaiseric Vandal gaiseric.vandal at gmail.com
Tue Aug 31 19:54:59 UTC 2010


Hi

I am having trouble with server certs, rather than user certs.  My guess 
was that that when I go to the "Certificate System RA Services Page" and 
request a server cert, it is using the following profile


/var/lib/pki-ca/profiles/ca/caServerCert.cfg


This file includes the lines:

policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=.*CN=.*


Which I take to mean that the subject must include a CN attribute 
somewhere.   I also noticed that this policy file does not include 
options for e-mail (mail) or Subject Alternative Name, although the 
caDualRAuserCert.cfg does/

On the "Certificate System CA Services Page"  
(https://myserver:9443/ca/services) I see I have access to a full set of 
profiles.  When I choose the serverCert request it seems OK with CSR's 
that include e-mail and SAN.


This makes me suspect that the PKI RA is NOT using the profiles 
available to the CA.    I also noticed during installation that the RA 
creates a  sqlite database, and is not using the LDAP backend for 
requests that the CA uses.



Thanks


On 08/31/2010 03:13 PM, Marc Sauton wrote:
> On 08/31/2010 11:43 AM, Gaiseric Vandal wrote:
>>
>> I have installed DogTag 1.3 Certificate Server (CA and RA) components 
>> on Fedora Core 11.
>>
>> I want to configure a server certificate with a Subject Alternate Name.
>>
>>
>> I used openssl to create a private key and a certificate signing 
>> request on the server in question.
>>
>>     openssl genrsa -out server1.key -des3 1024
>>     openssl req -new -key server1.key -out server.csr
>>
>>
>> I am prompted along the way to include an e-mail address and subject 
>> alternate name.  Both are permitted but optional in my openssl.cnf file.
>>
>> I can look at the csr with
>>     openssl req -in server.csr -text
>>
>>
>>
>>
>> By default, openssl by default recreates a req with the following line
>>
>> Subject: C=US, ST=California, L=MyCity, O=MyCompany, OU=IT, 
>> CN=server.company.com/subjectAltName=www.company.com/emailAddress=mymail at company.com 
>>
>>
>>
>>
>> You can see that e-mail and SAN are part of the CN attribute.
>>
>> I went to the "Certificate System RA Services Page" 
>> (https://myserver:12890) - > SSL End Users Services -> Server 
>> Enrollment -> Request Submission.   I pasted the contents of the csr 
>> file into the web page.   The administrator (i.e. me) gets e-mail 
>> notification  of a certificate request, and follows the link to 
>> approve it.  However if I have included either e-mail or SAN the 
>> request will fail because the subject name doesn't match.
>>
>> CA: Request Rejected - Subject Name Not Matched
>> E=mymail at company.com,CN=server.company.com,OU=IT,O=My 
>> Company,L=MyCity,ST=California,C=US
>>
>>
>>
>>
>> If I compare the dogtag error message to the original csr file I can 
>> see that dogtag expects a different syntax for e-mail.    Dogtag 
>> expects it as a separate "E" attribute (It still seems to have 
>> translated the attributes  appropriately but then complains the 
>> subject doesn't match.)     I can work around this by either omitting 
>> e-mail in the csr altogether or explicitly setting the subject 
>> attribute with the "openssl req -subj"
>>
>> -> openssl req -new -key server.key -out server.csr -subj 
>> "/E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company 
>> Name,L=MyCity,ST=California,C=US"
>> Enter pass phrase for server.key:
>> Subject Attribute E has no known NID, skipped
>> ->
>>
>>
>> However, I can't figure out how to make this work for the Subject 
>> Alternate Name.
>>
>> DogTag rejects the certificate with
>>
>> CA: Request Rejected - Subject Name Not Matched E=mymail at company.com 
>> ,2.5.29.17=www.company.com,CN=server....
>>
> For this error, if you enroll for a user cert, see the CA profile 
> /var/lib/pki-ca/profiles/ca/caDualRAuserCert.cfg
> and change the default configuration for
> policyset.userCertSet.1.constraint.params.pattern=.*UID=.*
> to match your needs
>
>>
>> Is there a "NID" parameter than dogtag expects for SAN?
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pki-users mailing list
>> Pki-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-users
>>    
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-users/attachments/20100831/8104d84f/attachment.htm>


More information about the Pki-users mailing list