Hello, For questions related to PKI, ask them here: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads For IIS questions, ask them here: http://forums.iis.net/ This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. Microsoft Student Partner 2010 / 2011 Microsoft Certified Professional Microsoft Certified Systems Administrator: Security Microsoft Certified Systems Engineer: Security Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows 7, Configuring Microsoft Certified Technology Specialist: Designing and Providing Volume Licensing Solutions to Large Organizations Microsoft Certified IT Professional: Enterprise Administrator Microsoft Certified IT Professional: Server Administrator Microsoft Certified Trainer

I have a PKI with standalone root CA and enterprise issuing CA. The issuing CA is based on 2003 and the root CA was migrated to 2008 (R2 I think). Auto-enrolled certs which users have been getting successfully for years are able to automatically login to test web pages in IIS 5 which either require or accept the auto-enrolled certs. I have added a new enterprise issuing CA based in 2008 R2 and am testing the auto-enrolled certs for a few users. I created a template for this so I could limit the users. Test users get the auto-enrolled certs ok but when going to the same IIS 5 test web pages, no login happens. I get HTTP 403 error. Why? Comparing the issued certs (both issuing CAs are running), I see some differences in signature, hash. I am wondering if the SHA256 encryption (new CA cert) is too new for the IIS 5 web authentication to handle. Or am I going in the wrong direction?

You can create a new thread there if you want or wait for a moderator to move the thread. This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. Microsoft Student Partner 2010 / 2011 Microsoft Certified Professional Microsoft Certified Systems Administrator: Security Microsoft Certified Systems Engineer: Security Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows 7, Configuring Microsoft Certified Technology Specialist: Designing and Providing Volume Licensing Solutions to Large Organizations Microsoft Certified IT Professional: Enterprise Administrator Microsoft Certified IT Professional: Server Administrator Microsoft Certified Trainer

Link to the new thread: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/68591a0a-cddb-4621-9eb2-cbd6f874bab3/#68591a0a-cddb-4621-9eb2-cbd6f874bab3 This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. Microsoft Student Partner 2010 / 2011 Microsoft Certified Professional Microsoft Certified Systems Administrator: Security Microsoft Certified Systems Engineer: Security Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows 7, Configuring Microsoft Certified Technology Specialist: Designing and Providing Volume Licensing Solutions to Large Organizations Microsoft Certified IT Professional: Enterprise Administrator Microsoft Certified IT Professional: Server Administrator Microsoft Certified Trainer

I believe that SHA256 signatures are not supported by domain controllers. Only Windows Server 2008 R2-based domain controllers supports them (though, requires additional configuration). You should reconfigure your templates to use RSA keys and SHA1 signatures.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

I'm not sure why you brought domain controllers into the discussion. Am I naive? I tried reconfiguring the template for SHA1 and reducing the key length to 1024 bits but the signature algorithm still comes up with SHA256RSA and the signature hash algorithm still is SHA256. The public key is RSA (1024 bits) and the thumbprint algorithm is SHA1. The SHA256 appears to come from the issuing CA configuration, not from the template configuration. The only change I achieved by changing the template is the key length, changed from 2048 bits to 1024 bits. In summary, I believe the IIS 5 web server is not capable of handling the cert from this issuing CA. I would really like to know if this is correct. Or am I barking up the wrong tree. Rebuilding the issuing CA at this time is still possible.

> I'm not sure why you brought domain controllers into the discussion. this is because by default IIS forwards clients certificates to domain controllers. > still comes up with SHA256RSA and the signature hash algorithm still is SHA256 this is because your CA is configured to sign all requests with SHA256 algorithm. To change this behavior you can run the following command: certutil -setreg ca\csp\hashalgorithm 0x8004 net stop certsvc && net start certsvc also, make sure if you are using version 2 (Windows Server 2003 Enterprise) templates. My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Thanks for your reply. I changed the hashalgorithm as you detailed in my test network. The certs issued still show SHA256. The properties page of the CA still shows SHA256. Looking at the other CSP registry keys and searching on CNGHashAlgorithm (which is SHA256) I found the following (in italics) for an inquiry which is essentially the same as my question: If your output from the command: certutil -getreg ca\csp\Provider returns "Providerype REG_SZ=Microsoft Software Key Storage Provider" then you must modify the setreg command as follows: certutil -setreg ca\csp\CNGHashAlgorithm sha1 Restart CA services and then request a new CA Root cert. (You will need to stop services again to request the new cert) After the new root cert is issued open the certificate and the Hash Algorithm should now say SHA1. Elsewhere I found a description that one must rebuild the CA with new parameters. I don't relish rebuilding the issuing CA at this time but I can since it is not production yet. However, resetting CNGHashAlgorithm would be a whole lot easier if it will not cause me problems later on. Can you comment on the above solution? Would changing CNGHashAlgorithm be a mistake? Thanks.

Yes, you should change CNG algorithm to SHA1 too. After the change is made, restart certificate services.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Thanks for the reply. I did go ahead and test the CNGHashAlgorithm change in my test network PKI. The issued auto-enrolled certs now look like those from the old issuing CA. I will do the same now in production where I still have the old issuing CA in production and my new issuing CA issuing to a very limited user base. There I can test the auto-enrolled certs from the new issuing CA for login to legacy web servers. Should I worry that making the CNGHashAlgorithm value change will create any problems down the road?

No, CNG algorithms have limited support and should not be used unless it is necessary.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

By limited support do you mean that the "new generation" just has not been implemented widely enough? Regarding the update of my issuing CA for hashalgorithm 0x8004 and CNGHashAlgorithm SHA1, the auto-enrolled cert still does not function for login to the older web sites which either require or accept certs. I get HTTP Error 403.13 - Forbidden: Client certificate has been revoked on the Web server. Discussions of this error imply that the CRL is unavailable. I think that is not true but I do have some trouble validating an ldap CDP. My Enterprise PKI (PKIHealth) display shows everything healthy. So now I'm wondering if I have been going in the wrong direction. Any advice would be greatly appreciated.

I followed up on this problem with Microsoft support. Here are some additional required details. The above thread has the goal of "degrading" the issuing CA so that it will use the weaker cryptography of SHA1 rather than the SHA256 which I started with. As it turns out, what was done up to this point is ok but another step needed is to issue a new CRL from the issuing CA with the two new issuing CA registry values hashAlgorithm and CNGHashAlgorithm, which were described in this thread. That is, for a web site to verify the certificate presented to the web site, it is necessary for the web site to have access to a CRL produced by the issuing CA after the registry changes were made and the CA restarted. Additionally, if the CRL period is long, the web site caching of the CRL may confuse your observed behavior. The web site needs to use the new CRL to validate the cert presented to it. If the CRL period is frequent, you may not notice any problem even if you do not issue a new crl. The command certutil -CRL will issue new CRLs, including a new base (and delta if applicable). Another useful command is certutil -verify -urlfetch [UserCertFileName] > usercert.txt which will verify the user cert against a CRL which it fetches from the CDP. Take a user cert produced by the issuing CA to the web server and run this command. Look at the txt file for errors. In summary, the required commands are: certutil -setreg ca\csp\hashalgorithm 0x8004 certutil -setreg ca\csp\CNGHashAlgorithm SHA1 net stop certsvc && net start certsvc certutil -CRL