[Pki-users] Adding subject alternative name into certificate

Jindrich Dolezal jindrich.dolezal at adaptivemobile.com
Fri Jan 17 09:44:15 UTC 2014


great, that worked!
big thanks
jd

On 01/16/2014 10:54 PM, Marc Sauton wrote:
> Some more comments:
>
> In the case of user provided extension in the CSR, I would not use the 
> subjectAltNameExtDefaultImpl in the profile:
> policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl
>
> The "gname is empty, not added" happens because there is no variable 
> $request.requestor_email$ populated in the enrollment form.
>
> The problem is the profile does not know how to populate the 
> "User-Supplied Extension" 2.5.29.17 to the request.
>
> I would modify the profile to remove the blob for 
> policyset.serverCertSet.9
>
> And for example change the test profile:
>
> policyset.serverCertSet.list=...,addUserSANcsr
>
> to add a "User Supplied Key Usage Extension" definition, for the oid 
> of subjectAltNameExt, 2.5.29.17, like for example:
>
> policyset.serverCertSet.addUserSANcsr.constraint.class_id=noConstraintImpl 
>
> policyset.serverCertSet.addUserSANcsr.constraint.name=No Constraint To 
> keep it simple
> policyset.serverCertSet.addUserSANcsr.default.class_id=userExtensionDefaultImpl 
>
> policyset.serverCertSet.addUserSANcsr.default.name=User Supplied Key 
> Usage Extension
> policyset.serverCertSet.addUserSANcsr.default.params.userExtOID=2.5.29.17
>
> And try to enroll again.
>
> The debug log should list some entries about the user provided 
> extensions, like for example:
>
> [16/Jan/2014:06:10:23][http-9444-Processor24]: UserExtensionDefault: 
> populate start
> [16/Jan/2014:06:10:23][http-9444-Processor24]: UserExtensionDefault: 
> using user supplied ext for 2.5.29.17
> [16/Jan/2014:06:10:23][http-9444-Processor24]: UserExtensionDefault: 
> populate end
>
> The one problem in this example is I did not add any constraints for 
> this user provided data in the CSR.
>
> Thanks,
> Marc Sauton.
>
>
> On 01/16/2014 10:05 AM, Christina Fu wrote:
>> In general, the two easiest ways to add SAN into the cert. The 
>> following documentation should help.
>>
>> 1. The subjectAlternativeName profile configuration : (use this if 
>> your CSR does not contain SAN, but you have relevant info in the 
>> accompanying request or ldap)
>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html-single/Admin_Guide/index.html#Subject_Alternative_Name_Extension_Default 
>>
>>
>> 2. The User Supplied Extension Default : (use this if you generate 
>> your own SAN in the CSR)
>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html-single/Admin_Guide/index.html#User_Supplied_Extension_Default 
>>
>>
>> Christina
>>
>> On 01/16/2014 06:06 AM, Jindrich Dolezal wrote:
>>> hi all,
>>> im struggling in adding the subject alternative name (san) into the 
>>> generated certificate. im doing scep request. when i print the cert 
>>> req into a file and dump it, it seems that san is correctly added:
>>> $ openssl req -in certreq.csr -text -noout
>>> Certificate Request:
>>>     ...
>>>         Requested Extensions:
>>>             X509v3 Subject Alternative Name:
>>>                 email:example at example.org
>>>     Signature Algorithm: sha1WithRSAEncryption
>>> 1a:7e:d8:b7:80:a3:1f:ff:52:b5:28:be:9e:f2:53:03:22:f8:
>>>           ....
>>>
>>> the profile that is then used on ca contains:
>>> policyset.serverCertSet.9.constraint.class_id=noConstraintImpl
>>> policyset.serverCertSet.9.constraint.name=No Constraint
>>> policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl
>>> policyset.serverCertSet.9.default.name=Subject Alt Name Constraint
>>> policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false
>>> policyset.serverCertSet.9.default.params.subjAltExtType_0=RFC822Name
>>> policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.requestor_email$ 
>>>
>>> policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true
>>> policyset.serverCertSet.9.default.params.subjAltNameNumGNs=1
>>>
>>> and in the log file:
>>> [16/Jan/2014:13:49:42][http-9180-1]: Found PKCS10 extension
>>> [16/Jan/2014:13:49:42][http-9180-1]: Set extensions [ObjectId: 
>>> 2.5.29.17 Criticality=false
>>> SubjectAlternativeName [
>>> [RFC822Name: example at example.org]]
>>> ]
>>> [16/Jan/2014:13:49:42][http-9180-1]: Finish parsePKCS10 - 
>>> CN=testsubject
>>>
>>> .....
>>>
>>> [16/Jan/2014:13:49:42][http-9180-1]: SubjectAltNameExtDefault: 
>>> populate start
>>> [16/Jan/2014:13:49:42][http-9180-1]: SubjectAltNameExtDefault: 
>>> createExtension i=0
>>> [16/Jan/2014:13:49:42][http-9180-1]: gname is empty, not added
>>> [16/Jan/2014:13:49:42][http-9180-1]: count is 0
>>> [16/Jan/2014:13:49:42][http-9180-1]: SubjectAltNameExtDefault: 
>>> populate sees no extension.  get out
>>> [16/Jan/2014:13:49:42][http-9180-1]: SubjectAltNameExtDefault: 
>>> populate end
>>>
>>> and the san is not included in the certificate.
>>>
>>> i also tried other values for subjAltExtPattern_0 like 
>>> $request.email$, $request.SAN1$, etc but this only ended with state 
>>> where san was included into the certificate but has value as the 
>>> parameter, i.e. '$request.email$' which is apparently not what i 
>>> wanted.
>>>
>>> would anyone know what im doing wrong, where is the catch?
>>>
>>> thank a lot
>>>
>>> jd
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> Pki-users mailing list
> Pki-users at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users




More information about the Pki-users mailing list