[Pki-users] DogTag 1.3 and Subject Alternate Name

Tue Aug 31 20:23:01 UTC 2010

On 08/31/2010 12:54 PM, Gaiseric Vandal wrote:
> 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
>
/var/lib/pki-ca/profiles/ca/caRAserverCert.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=.*
and similar subject name constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=.*
to customize and first verify with enrollment success, and then do the 
subj alt names part for the next troubleshooting
>
>
> 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
>>>    
>>
>
>
> _______________________________________________
> 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/001f92e0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6642 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/pki-users/attachments/20100831/001f92e0/attachment.p7s>