locked
SSL Certificate Settings in .NET - "Disable all purposes for this certificate" RRS feed

  • Question

  • I need to disable all purposes for a specific Root CA certificate due to some SSL chaining issues we're experiencing in our environment.  IE...  Go to "Edit Properties" on the details tab of an SSL certificate and select the "Disable all purposes for this certificate" radio button.  I'm assuming that the appropriate namespace to use would be System.Security.Cryptography.X509Certificates, but I cannot find any way to modify this specific setting programatically.  Any help would be greatly appreciated.  If there's any way to do this using command line tools or any other means that would be appreciated as well...

    X509Store xStore = new X509Store(StoreName.Root, StoreLocation.LocalMachine); 
    xStore.Open(OpenFlags.ReadWrite); 
    X509Certificate2 xCert = xStore.Certificates.Find(X509FindType.FindBySerialNumber, "344ed55720d5edec49f42fce37db2b6d", false)[0]; 
    xCert.?????????
    xStore.Close();
    
    
    • Moved by SamAgain Tuesday, July 20, 2010 12:17 AM (From:.NET Base Class Library)
    Monday, July 12, 2010 6:30 PM

Answers

  • FYI...  This requirement/problem was a result of the migration to 2048-bit SSL certificates by our SSL provider (Thawte), but I believe that all other providers that now require 2048-bit keys may have the same issue as well.  From my recollection, I believe the problem was due to Microsoft's CA certificates acquired by Windows Server (when processes such as IIS validate the SSL chain for a given certificate) being invalid for these new 2048-bit certificates, causing chaining issues with integration partners.  The solution in our case was to deploy and "disable" these "bad" certificates to all servers across our Windows domains.  This can be easily accomplished using AD Group Policy.  Simply create a new policy and add the "bad" certificates.  Once the certificates are added, you can modify their intended purpose and set them to "Disable all purposes for this certificate" via the GPM editor.  The policy node can be found at the following path:

    Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Trusted Root Certification Authorities

    In our case, we also deployed the new intermediate certificates with the same policy.  Simply add them to:  Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Intermediate Certification Authorities

    • Marked as answer by rdoram Tuesday, May 24, 2011 1:50 PM
    Tuesday, May 24, 2011 1:50 PM

All replies

  • Hello,

                Thank you for your post!  I would suggest creating a new thread for your question in the (.NET  Framework Developer Center > .NET Development Forums > .NET Framework Setup  ) forum located here:  (http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/threads).

               Hope that would be helpful.

               Have a great day!

               Thanks & regards,


    Tagore Bandlamudi Tier 2 Application Support Server and Tools Online Operations Team
    Friday, August 13, 2010 12:03 PM
  • FYI...  This requirement/problem was a result of the migration to 2048-bit SSL certificates by our SSL provider (Thawte), but I believe that all other providers that now require 2048-bit keys may have the same issue as well.  From my recollection, I believe the problem was due to Microsoft's CA certificates acquired by Windows Server (when processes such as IIS validate the SSL chain for a given certificate) being invalid for these new 2048-bit certificates, causing chaining issues with integration partners.  The solution in our case was to deploy and "disable" these "bad" certificates to all servers across our Windows domains.  This can be easily accomplished using AD Group Policy.  Simply create a new policy and add the "bad" certificates.  Once the certificates are added, you can modify their intended purpose and set them to "Disable all purposes for this certificate" via the GPM editor.  The policy node can be found at the following path:

    Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Trusted Root Certification Authorities

    In our case, we also deployed the new intermediate certificates with the same policy.  Simply add them to:  Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Intermediate Certification Authorities

    • Marked as answer by rdoram Tuesday, May 24, 2011 1:50 PM
    Tuesday, May 24, 2011 1:50 PM