none
How to include the Subject Alternative Name (SAN) parameter through the MMC Certificate Enrollment. RRS feed

  • Question

  • Hi,

    I need to publish my site system to provide software distribution, software updates and fallback status point to Internet Clients. The intranet name is different from the internet name. To make this work I need to use a certificate with SAN parameter. I created a template where the Subject Name should be supplied in the request. When I request a WebServer certificate for the site system, in the subject name a use the Type:Full DN and Value:server.domain.com. My question is: In the Alternative Name what TYPE should I use? In the VALUE field what is the right way to fill up with internet name and intranet name? Initially, I used DNS as a TYPE and Name=san:dns=internalName.com&dns=internetName.com as a VALUE.

    Thanks in advance,
    Giancarlo.
    • Edited by Giancarlo S. _ Monday, June 1, 2009 2:03 AM Add more information
    Monday, June 1, 2009 1:59 AM

Answers

  • It wasn't confirmed whether you had run the certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 command (and then stop/restart the service), as described in the article http://support.microsoft.com/default.aspx/kb/931351/en-us.  If you don't, you get the symptoms you describe - no errors when requesting the certificate but the SAN value is just not in the certificate.  I know the article says "By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension" but I'm pretty sure the same applies to a Win2008 CA.  When I want to use custom SANs with Win2008 CA, I always run this command before requesting the certificates.  I wish they would update this article for Win2008 CA - if you agree, please send them this feedback (bottom of the article).

    Even if you've run the command, try running it again, make sure the CA service is stopped/restarted, and then request your certificate again.  Your .inf file for Certreq.exe looks fine to me.


    - Carol

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Sunday, June 7, 2009 4:27 PM
  • Then you should be able to use the following command

    Certreq -submit MyCert.req -attrib "SAN:dns=internalName.com&dns=internetName.com"

    See if this works?  Pull the SAN out of your cert and place inline with the command.  It can't hurt. 
    http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com
    Sunday, June 7, 2009 12:35 PM
    Moderator
  • Great - just to confirm, you've reconfigured IIS to use this new certificate with the SAN entries?  Leaving the old certificate in place shouldn't be problem, although it wouldn't hurt to just delete it if it's not needed.

    Because of the last two lines in the log, I think this is actually OK - it's going through to find a client certificate that can be used to monitor the health of the management point.  If it hadn't succeeded (it's checking multiple certificates in the store) it wouldn't end with "Call to HttpSendRequestSync succeeded for port 443 with status code 200."  And as we've post many times before, the CryptVerifyCertificateSignatureEx returned error 0x80090006 is actually a "good" error and does not indicate a problem (see http://blogs.technet.com/configmgrteam/archive/2009/01/20/cryptverifycertificatesignatureex-returned-error-0x80090006-what-does-this-mean.aspx).

    At this point, simply check to see whether the clients are receiving policy - first the clients on the intranet and then clients that display either "Always Internet" or Currently Internet" as their ConfigMgr Connection Type in the client properties, General tab.  There are different ways to do this but I always use the easy test of changing one of the client agents (eg software metering) as a site setting from enabled to disabled or vice versa, initiating policy retrieval on the client, and then after a few minutes confirm the status change using the Components tab on the client.  Other methods include sending a test advertisement to the client (such as a script that loads the command prompt), and using Policy Spy from the Configuration Manager 2007 toolkit where you can actually see the policy downloaded to the client.

    For testing purposes, you might also find the following blog post useful:
    http://blogs.technet.com/configmgrteam/archive/2009/03/03/tips-and-tricks-using-internet-only-client-management-on-the-intranet.aspx


    - Carol

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Tuesday, June 9, 2009 4:36 AM

All replies

  • Hi:
     As you can read on this article: http://technet.microsoft.com/en-us/library/bb633078(printer).aspx, it explians how to deploy the web server certificate, but before it shows how to configure the IIS, say this: "For information about how to specify more than one fully qualified domain name (FQDN) in the certificate Subject Alternative Name field (for example, if the site system supports intranet and Internet client connections, or is a network load balancing site system), see the following article about how to add a subject alternative name to a secure LDAP certificate: http://go.microsoft.com/fwlink/?LinkId=93692 [ http://go.microsoft.com/fwlink/?LinkId=93692 ] ."
     In that case about to secure LDAP, but is useful for SCCM.
     I hope this help you.
    Regards,
    Monday, June 1, 2009 2:54 AM
  • Hi Felipe,

    According to the links that you sent before I tried to request a new ConfigMgr Web Server Certificate using the Certreq.exe utility. My Request.inf file has the following content:

    [NewRequest]
    Subject = "CN = internalName.com"
    [RequestAttributes]
    CertificateTemplate = ConfigMgrWebServerCertificate
    SAN="dns=internalName.com&dns=internetName.com"

    I did all steps described there and the certificate was enrolled successfully. However, when I open the certificate through the MMC the Subject Alternative Name field is missing. What needs to be changed to make it works?

    Thanks,
    Giancarlo.
    Wednesday, June 3, 2009 12:43 AM
  • Is this a 2008 or 2003 CA?

    If 2003 you can check the "CERTUTIL -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME" 
    then restart the CA service

    or maybe you can try this..
    certreq -attrib "SAN:dns=internalName.com&dns=internetName.com" -submit xxxxxxxx

    I am not a CA expert but you could give it a try.





    http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com
    Wednesday, June 3, 2009 2:16 AM
    Moderator
  • Hi:
     Like Matthew, i'm not a pki expert. I'm only sure what SCCM documentation says and my personal experience had teached me.
     Yo can try the last recommendations or ask in a PKI related forum.
    Regards,
    Wednesday, June 3, 2009 3:08 AM
  • Hi Matthew,

    BTW, I'm running an 2008 CA.
    Sunday, June 7, 2009 6:25 AM
  • Then you should be able to use the following command

    Certreq -submit MyCert.req -attrib "SAN:dns=internalName.com&dns=internetName.com"

    See if this works?  Pull the SAN out of your cert and place inline with the command.  It can't hurt. 
    http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com
    Sunday, June 7, 2009 12:35 PM
    Moderator
  • It wasn't confirmed whether you had run the certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 command (and then stop/restart the service), as described in the article http://support.microsoft.com/default.aspx/kb/931351/en-us.  If you don't, you get the symptoms you describe - no errors when requesting the certificate but the SAN value is just not in the certificate.  I know the article says "By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension" but I'm pretty sure the same applies to a Win2008 CA.  When I want to use custom SANs with Win2008 CA, I always run this command before requesting the certificates.  I wish they would update this article for Win2008 CA - if you agree, please send them this feedback (bottom of the article).

    Even if you've run the command, try running it again, make sure the CA service is stopped/restarted, and then request your certificate again.  Your .inf file for Certreq.exe looks fine to me.


    - Carol

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Sunday, June 7, 2009 4:27 PM
  • Hi Carol,

    I ran the command on the CA Server and looks like it adds a new parameter. See the command output:


    Old Value:
      EditFlags REG_DWORD = 11014e (1114446)
        EDITF_REQUESTEXTENSIONLIST -- 2
        EDITF_DISABLEEXTENSIONLIST -- 4
        EDITF_ADDOLDKEYUSAGE -- 8
        EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
        EDITF_ENABLEAKIKEYID -- 100 (256)
        EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
        EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

    New Value:
      EditFlags REG_DWORD = 15014e (1376590)
        EDITF_REQUESTEXTENSIONLIST -- 2
        EDITF_DISABLEEXTENSIONLIST -- 4
        EDITF_ADDOLDKEYUSAGE -- 8
        EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
        EDITF_ENABLEAKIKEYID -- 100 (256)
        EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
        EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
        EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
    CertUtil: -setreg command completed successfully.
    The CertSvc service may need to be restarted for changes to take effect.

    Now I will try to request a new certificate a see if accepts the SAN value. I will post the results.

    Monday, June 8, 2009 8:48 AM
  • After restart the server, I requested a new certificate modifying the template previously created including the option to export the private key and Subject Name supply in the request. I could see some changes on the SAN attribute. Now is showing like this when I open the certificate:

    DNS Name = InternalName.com
    DNS Name = InternetName.com

    I think the problem was solved, but I looked at the mpcontrol.log and found some errors:

    Successfully performed Management Point availability check against local computer. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Machine name is 'Internal.com'. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    CryptVerifyCertificateSignatureEx returned error 0x80090006. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate doesn't have "SSL Client Authentication" capabilities. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Skipping certificate that is not valid for ConfigMgr usage. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    CryptVerifyCertificateSignatureEx returned error 0x80090006. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate doesn't have "SSL Client Authentication" capabilities. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Skipping certificate that is not valid for ConfigMgr usage. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    There are no certificate(s) that meet the criteria. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Performing machine FQDN to SAN2 search. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate doesn't have SAN2 extension. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    CryptVerifyCertificateSignatureEx returned error 0x80090006. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate has "SSL Client Authentication" capability. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    CryptVerifyCertificateSignatureEx returned error 0x80090006. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate doesn't have "SSL Client Authentication" capabilities. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Certificate doesn't have SAN2 extension. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:45 AM 1784 (0x06F8)
    Call to HttpSendRequestSync succeeded for port 443 with status code 200, text: OK SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:46 AM 1784 (0x06F8)
    Http test request succeeded. SMS_MP_CONTROL_MANAGER 9/06/2009 10:32:46 AM 1784 (0x06F8)

    What needs to be changed now? I left the old certificate on the same place. Should I remove the old certificate? How can I test to see if the new certificate is working for the internet clients?

    Thanks,
    Giancarlo Soares

    Tuesday, June 9, 2009 12:45 AM
  • Great - just to confirm, you've reconfigured IIS to use this new certificate with the SAN entries?  Leaving the old certificate in place shouldn't be problem, although it wouldn't hurt to just delete it if it's not needed.

    Because of the last two lines in the log, I think this is actually OK - it's going through to find a client certificate that can be used to monitor the health of the management point.  If it hadn't succeeded (it's checking multiple certificates in the store) it wouldn't end with "Call to HttpSendRequestSync succeeded for port 443 with status code 200."  And as we've post many times before, the CryptVerifyCertificateSignatureEx returned error 0x80090006 is actually a "good" error and does not indicate a problem (see http://blogs.technet.com/configmgrteam/archive/2009/01/20/cryptverifycertificatesignatureex-returned-error-0x80090006-what-does-this-mean.aspx).

    At this point, simply check to see whether the clients are receiving policy - first the clients on the intranet and then clients that display either "Always Internet" or Currently Internet" as their ConfigMgr Connection Type in the client properties, General tab.  There are different ways to do this but I always use the easy test of changing one of the client agents (eg software metering) as a site setting from enabled to disabled or vice versa, initiating policy retrieval on the client, and then after a few minutes confirm the status change using the Components tab on the client.  Other methods include sending a test advertisement to the client (such as a script that loads the command prompt), and using Policy Spy from the Configuration Manager 2007 toolkit where you can actually see the policy downloaded to the client.

    For testing purposes, you might also find the following blog post useful:
    http://blogs.technet.com/configmgrteam/archive/2009/03/03/tips-and-tricks-using-internet-only-client-management-on-the-intranet.aspx


    - Carol

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Tuesday, June 9, 2009 4:36 AM