Add Subject Alternate Names to Cert Request

Sep 2, 2013 at 9:36 AM
Dear experts,

is it possible in the Submit-Request Function via the Parameter -Attribute to add anyhow Subject Alternate Names? If yes how is the Syntax?

I know Vadims blog http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=11 but we have the auto-approval feature turned on at the CA, so this approach would not work.

Thank you in advance for your hints.
Regards Andreas
Coordinator
Sep 2, 2013 at 10:12 AM
Consider to include SAN as extension and not as attribute: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=20
When passing SANs as an attribute, it may lead to a security risk, because SAN attribute requires special flag on CA.

When enabling this flag, any requster can pass any SAN which will be automatically added to certificate without previous approval (and even if subject is constructed automatically). Therefore I would recommend to premoderate all certificate templates that accept subject from request. And, of course, include SAN in the extension section. If you are using INF file to generate request, the syntax of the INF file would contain:
[Extensions]  
2.5.29.17 = "{text}" 
_continue_ = "dns=www01.fabrikam.com&"
_continue_ = "dns=www02.fabrikam.com&"
Sep 2, 2013 at 10:31 AM
Camelot wrote:
Consider to include SAN as extension and not as attribute: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=20
When passing SANs as an attribute, it may lead to a security risk, because SAN attribute requires special flag on CA.
Yes we are aware of this risk, BUT we have also NON-Microsoft/Microsoft (like Lync) applications which cannot handle SANS on request level. So this "disliked" feature is still required.
When enabling this flag, any requster can pass any SAN which will be automatically added to certificate without previous approval (and even if subject is constructed automatically). Therefore I would recommend to premoderate all certificate templates that accept subject from request. And, of course, include SAN in the extension section. If you are using INF file to generate request, the syntax of the INF file would contain:
[Extensions]  
2.5.29.17 = "{text}" 
_continue_ = "dns=www01.fabrikam.com&"
_continue_ = "dns=www02.fabrikam.com&"
So at the end my question still remains, if I can add the SANs for a certificate request via the -Attribute Parameter of Submit-CertificateRequest?

Thanks Andreas
Coordinator
Sep 2, 2013 at 10:58 AM
Ok, if you are aware about these risks, then the following syntax must be used:
Submit-CertificateRequest <parameters> -Attribute "san:dns=www.example.com&dns=sip.example.com"
Sep 2, 2013 at 12:49 PM
Camelot wrote:
Ok, if you are aware about these risks, then the following syntax must be used:
Submit-CertificateRequest <parameters> -Attribute "san:dns=www.example.com&dns=sip.example.com"
We did the following tests:
  1. Submit-CertificateRequest -Path d:\temp\acertRequest.cer -CertificateAuthority $myCA -Attribute 'CertificateTemplate:TestServerInternalStandard','san:dns=testname1.infineon.com&dns=testname2.infineon.com'
In this case only the required by the CA Template was taken.
  1. Submit-CertificateRequest -Path d:\temp\acertRequest.cer -CertificateAuthority $myCA -Attribute 'san:dns=testname1.infineon.com&dns=testname2.infineon.com','CertificateTemplate:TestServerInternalStandard'
In this case only the Sans were taken and not the Template which resulted in an "Requeststatus denied" as our CA requires a Templatename.

Do you have an idea what we got wrong? Our CA is hosted on an Win2008 R2 Server.

Thanks Andreas
Coordinator
Sep 2, 2013 at 12:57 PM
can you provide exact error message why the request is failed?
Sep 2, 2013 at 1:10 PM
Camelot wrote:
can you provide exact error message why the request is failed?
The EventID in the errorlog was 53 (with Qualifiers 3370, don't know the exact meaning of this number)

The error messages was: Active Directory Certificate Services denied request 782 because The requested certificate template is not supported by this CA, 0x80094800 (-214875392). The request was for CN=testportal.infineon.com,OU....... Additional information: Denied by Policy Module.

What we further detected was, that it was tried to attach part of the SAN Value to the Templatename which of course leads to a Templatename which is not known and thus rejected by the CA. The wrong Templatename contained the Patterns TemplateName\nsan:SANValues

It looks like the Submit-Certificaterequest function concatenates all Strings specified in the -Attribute Parameter

Regards Andreas
Coordinator
Sep 2, 2013 at 1:19 PM
Ok, let's try this approach. Open Submit-CertificateRequest.ps1 file and find the following lines:
foreach ($attrib in $Attribute) {
[Void]$SB.Append($attrib + "\n")
}
and replace "\n" with "`n", so the resulted expression will be:
foreach ($attrib in $Attribute) {
[Void]$SB.Append($attrib + "`n")
}
and let me know if it works. I smell a bug here.
Sep 2, 2013 at 1:42 PM
Camelot wrote:
Ok, let's try this approach. Open Submit-CertificateRequest.ps1 file and find the following lines:
foreach ($attrib in $Attribute) {
[Void]$SB.Append($attrib + "\n")
}
and replace "\n" with "`n", so the resulted expression will be:
foreach ($attrib in $Attribute) {
[Void]$SB.Append($attrib + "`n")
}
and let me know if it works. I smell a bug here.
I feel we come closer to the solution. I adapted the line according your instruction and noticed that additionally the line

$strAttribute = $strAttribute.Substring(0,$strAttribute.Length - 2)

has to be replaced by

$strAttribute = $strAttribute.Substring(0,$strAttribute.Length - 1) otherwise the last character from the domain name was cut away.

We now can submit the san attribute with the request and we see the value in the downloaded Request-Object BUT the SANS do not appear in the final certificate.
Could it be the case that we have to use another name than "san" in the -attribute Parameter for it e.g. "SubjectAlternateNames:....."?
Coordinator
Sep 2, 2013 at 1:59 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Sep 2, 2013 at 2:13 PM
Ok, this was indeed a bug. Now, regarding missing SANs. By default CA server do not accept alternative names as an attribute. You need to configure your ca to allow SAN from attriutes (ok, you are aware about the issue).
$myCA | Get-PolicyModuleFlag | Enable-PolicyModuleFlag -Flag AttributeSubjectAlternativeName -RestartCA
and when not needed:
$myCA | Get-PolicyModuleFlag | Disable-PolicyModuleFlag -Flag AttributeSubjectAlternativeName -RestartCA