none
[MS-CSRA] ICertAdmin::GetCAProperty bugs RRS feed

  • Question

  • Hi!
    It seems like here is a several bugs in ICertAdmin2::GetCAProperty() that is defined in certadm.dll library.
    The issue is associated with following PropID's (as far as I have tested. Perhaps this issue is associated with CR_PROP_CAXCHGCERTCOUNT, nut not tested):

    • CR_PROP_CASIGCERTCOUNT (0x0b)
    • CR_PROP_KRACERTUSEDCOUNT (0x18)
    • CR_PROP_KRACERTCOUNT  (0x19)

    This method is described in 3.2.5.2.2 ICertAdminD2::GetCAProperty (Opnum 32). All PropID's are described in 3.2.1.4.3.2 ICertRequestD2::GetCAProperty (Opnum 7) and Opnum7 is used for both ICertAdmin2 and ICertRequestD2 interfaces that utilizes the same method. However ICertRequest is defined in certcli.dll library. And the same methods in both interfaces produces different results.

    A little info about my test lab CAs
    DC1 — Enterprise Root CA with name Contoso CA. Total has 2 CA certificates (renewed) and 1 defined Key Recovery Agent.
    DC2 — Entrprise Subordinate CA with name Contoso-DC2-CA. Total has 1 CA certificate and hasn't any defined Key Recovery Agents.

    here are examples that shows output using both ICertAdmin2::GetCAProperty() and ICertRequest::GetCAProperty() on both CA servers. All examples provided using Windows PowerShell.

    running script on DC1 server using ICertAdmin2 interface:

    [Administrator] # instantiate COM object: [Administrator] $CertAdmin = New-Object -com CertificateAuthority.Admin.1 [Administrator] # retrieve specified properties from local CA: [Administrator] # we see that CA has 2 signing certificates [Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0xb,0,1,0) 2 [Administrator] # the same result will be for remote CA: [Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0) 2 [Administrator] # now we retrieve all KRA certs count from local CA [Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0x19,0,1,0) 1 [Administrator] # all ok. And used KRA certs: [Administrator] $certadmin.GetCAProperty("dc1\contoso ca",0x18,0,1,0) 1 [Administrator] # ok, as mentioned 1 defined KRA. [Administrator] # however it will return the same numbers for remote CA, where I haven't any KRA certs [Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0) 1 [Administrator] $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0) 1 [Administrator]

    running script on DC2 server:

    PS C:\> # instantiate COM object: PS C:\> $CertAdmin = New-Object -com CertificateAuthority.Admin.1 PS C:\> # retrieve specified properties from local CA: PS C:\> # we see that CA has 2 signing certificates PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0) 1 PS C:\> # in previous example this line return to us 2 certs. Now we see correct results. PS C:\> # retrieve the same property from remote CA with 2 certs: PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0xb,0,1,0) 1 PS C:\> # wow! Looks like this info is cached. To ensure,now I will retrieve KRA PS C:\> # certs count from remote CA first: PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0x19,0,1,0) 0 PS C:\> $certadmin.GetCAProperty("dc1\contoso ca",0x18,0,1,0) 0 PS C:\> # in previous example we saw that DC1 has 1 defined KRA. Also we saw that DC2 has 1 PS C:\> # defined KRA (that is not true). Now we see correct info: PS C:\> $certadmin.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0) 0

    now we examine the same properties using ICertRequest interface that will show correct results in both cases.

    running script from DC1

    [Administrator] $request = New-Object -com CertificateAuthority.Request.1 [Administrator] $request.GetCAProperty("dc1\contoso ca",0xb,0,1,0) 2 [Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0) 1 [Administrator] $request.GetCAProperty("dc1\contoso ca",0x19,0,1,0) 1 [Administrator] $request.GetCAProperty("dc1\contoso ca",0x18,0,1,0) 1 [Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0) 0 [Administrator] $request.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0) 0 [Administrator]

    and correct results from DC2 server:

     

    PS C:\> $request = New-Object -com CertificateAuthority.Request.1 PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0xb,0,1,0) 1 PS C:\> $request.GetCAProperty("dc1\contoso ca",0xb,0,1,0) 2 PS C:\> $request.GetCAProperty("dc1\contoso ca",0x19,0,1,0) 1 PS C:\> $request.GetCAProperty("dc1\contoso ca",0x18,0,1,0) 1 PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0x19,0,1,0) 0 PS C:\> $request.GetCAProperty("dc2\contoso-dc2-ca",0x18,0,1,0) 0 PS C:\>

    it is real bug in ICertAdmin2 interface for me. thanks!


    http://www.sysadmins.lv
    Sunday, November 15, 2009 9:50 PM

Answers

  • Hello John!
    I still see this issue. I have contacted with product group (PG) through MSDN Library writer Don Glover. PG can confirm this bug. Here is a mail from Don:

    Vadims,

    A bit of follow up.
    I have heard back from the product team and there is indeed a bug in the ICertAdmin2 code. To address the bug in the short term I will be adding text similar to the following to all of the appropriate methods
    Note:
    GetCAPRoperty does not clear the internal caches when the configuration string is changed. When you change the configuration string for the CA, you must instantiate a new ICertAdmin object and call the method to work with a new CA.

    I have opened a code bug against the interface with the product team.

    This doesn't apply to ICertRequest interfaces that properly clear caches when configuration string is changed.


    http://www.sysadmins.lv
    Friday, December 18, 2009 6:58 AM

All replies

  • Hi Vadims Podans,

    Thank you for your question.  One of my colleagues will contact you soon to work with you on this issue.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Sunday, November 15, 2009 10:18 PM
  • is there any news?
    http://www.sysadmins.lv
    Thursday, November 19, 2009 10:55 AM
  • Hello Vadims Podans,
       I am sorry to say that this one slipped through the cracks. I don't know how this happened but please accept our apology. I will work on this issue with you. Please let me know if you are still seeing this problem. In the mean time I will be researching this.

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM
    Thursday, December 17, 2009 9:52 PM
  • Hello John!
    I still see this issue. I have contacted with product group (PG) through MSDN Library writer Don Glover. PG can confirm this bug. Here is a mail from Don:

    Vadims,

    A bit of follow up.
    I have heard back from the product team and there is indeed a bug in the ICertAdmin2 code. To address the bug in the short term I will be adding text similar to the following to all of the appropriate methods
    Note:
    GetCAPRoperty does not clear the internal caches when the configuration string is changed. When you change the configuration string for the CA, you must instantiate a new ICertAdmin object and call the method to work with a new CA.

    I have opened a code bug against the interface with the product team.

    This doesn't apply to ICertRequest interfaces that properly clear caches when configuration string is changed.


    http://www.sysadmins.lv
    Friday, December 18, 2009 6:58 AM
  • Hello Vadims Podans,
       Thank you for the quick response! I am glad that you received the help you needed from Microsoft for this issue. Again I apoliguze for the delay with getting an answer from this forum though.  I would like to make sure that we are on the same page. From my understanding of your last post the Microsoft product team has confirmed that this problem is caused by a bug in the Microsoft  ICertAdmin2 code and that you currently have a work around to get you past this issue. Is this correct? If so, I would also like to know if you still  need any additional assistance from the Microsoft Protocol Team or if you have what you need from us. Please let me know.

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM

    Monday, December 21, 2009 4:40 PM
  • Yes, I have 2 workarounds:
    1) reinstantiate COM object when configuration string is changed
    2) use ICertRequest interface

    and I'm satisfied with this response. However I believe that in future Windows releases this bug will be resolved and MSDN pages will be accordingly updated as soon as possible.

    Thanks!

    http://www.sysadmins.lv
    Monday, December 21, 2009 8:15 PM
  • as far as I know — no. So you will have to use ICertRequest COM object or reinstantiate ICertAdmin each time it is called.
    http://en-us.sysadmins.lv
    Friday, August 6, 2010 6:30 AM