locked
Invalid issuance policies problem RRS feed

  • Question

  • Hi,

    I have a problem with my new pki hierarchy. It consists from standalone windows 2008 se root ca and enterprise windows 2008 r2 ee issuing ca. root ca was installed using the following capolicy.inf:

    [Version]
    Signature= "$Windows NT$"
    [Certsrv_Server]

    [CRLDistributionPoint]
    Empty=True

    [AuthorityInformationAccess]
    Empty=True

    [PolicyStatementExtension]
    Policies = LegalPolicy

    [LegalPolicy]
    OID = 1.3.6.1.4.1.50000.1.1.1
    URL = "http://www.company.com/cps"

    Issuing CA was installed using following capolicy.inf:

    [Version]
    Signature= "$Windows NT$"

    [PolicyStatementExtension]
    Policies = LegalPolicy

    [LegalPolicy]
    OID = 1.3.6.1.4.1.50000.1.2.1
    URL = "http://www.company.com/cps"

    Right after I installed issuing ca I noticed an error on certificate generation based on caexchange template:

    Active Directory Certificate Services could not create an encryption certificate.  Requested by COMPANY\user  Invalid Issuance Policies:  1.3.6.1.4.1.50000.1.2.1.  The certificate has invalid policy. 0x800b0113 (-2146762477).

    What can cause such an error? Different OID for issuing ca?

    I've found the following thread:

    http://social.msdn.microsoft.com/Forums/en/biztalkgeneral/thread/741bbe77-20c9-4a46-bc45-5becacaa5164

    And I've tried this workaround:

    Run the following command at the CA and restart the CA service

    ·         certutil –setreg CA\CRLFlags +CRLF_IGNORE_INVALID_POLICIES

    net stop certsvc

    net start certsvc

    ·         Try to issue an end-entity certificate with Issuance Policies


    Error dissapeared and certificate based on CAExchange template was generated. But I want to know root cause of this problem. What exactly is wrong with my issuing ca? What is right way to correct this? Thanks.
    Wednesday, February 17, 2010 4:51 PM

Answers

  • Just to add some reference. We have deployed several PKIs for the US Federal Bridge
    In the US federal bridge, the CAs can assert up to Five different assurance levels (CP OIDS).
    See section 1.5 http://www.va.gov/proj/vapki/documents/FBCA_CP_v1_04_100500.doc

    Here is the declared OIDs for certificate policy from a DOD issuing CA:

    [1]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.1

    [2]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.2

    [3]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.3

    So in this example, tey have chosen to do rudimentary, Basic, and Medium assurance levels.
     Joson, even in the link that you posted, the issuing CA asserts *two* issuance policy OIDs, and is allowed to do it because the intermdiate CA in their example asserts the AllIssuancePolicy OID (2.5.29.32.0)

    The two OIDs asserted in your example link are:
    [Version]
    Signature= "$Windows NT$"
    [PolicyStatementExtension]
    Policies = LegalPolicy, LimitedUsePolicy
    [LegalPolicy]
    OID = 1.1.1.1.1.1.1.1.1

    [LimitedUsePolicy]
    OID = 2.2.2.2.2.2.2.2.2

    Thanks,
    Brian

    • Marked as answer by Joson Zhou Monday, March 1, 2010 8:23 AM
    Monday, February 22, 2010 2:50 PM

All replies

  • You have restricted the valid issuance policies at the root to 1.3.6.1.4.1.50000.1.1.1
    At the policy CA, you have tried to assert the issuance policy 1.3.6.1.4.1.50000.1.2.1, which does not match the policy asserted at the root.
    What you need to do, is at the root CA, do one of two things:
    1) Do not assert CP/CPS OIDS.
    2) Assert both OIDS
    [PolicyStatementExtension]
    Policies = LegalPolicy1,LegalPolicy2
    [LegaPolicy1]
    OID = 1.3.6.1.4.1.50000.1.1.1
    URL = "http://www.company.com/cps"

    [LegaPolicy2]
    OID = 1.3.6.1.4.1.50000.1.2.1
    URL = "http://www.company.com/cps"


    Brian
    • Proposed as answer by gregg10 Sunday, October 19, 2014 9:57 PM
    Wednesday, February 17, 2010 7:16 PM
  • Thanks Brian for great answer. But I still have a question.

    If I'll assert both oid's at the root level - is it enough to assert OID = 1.3.6.1.4.1.50000.1.2.1 at the issuing ca level (in capolicy.inf)? Or will I be forced to assert the same two oid's and at issuing ca level? Thanks.
    Thursday, February 18, 2010 6:52 AM
  • It really depends on your policies.
    You can honestly assert both, one, or the other
    - What are you attempting to do at the issuing CA
    - What issuance policy are you asserting
    - What is the difference between the two issuance policies?
    - Is there a difference?
    Brian
    Thursday, February 18, 2010 6:59 AM
  • As for now I'm doing tests with my test PKI infrastructure. What I've did till now:

    I modified root ca Capolicy.inf file and specified both policies in there. I renewed my root CA using the same key. Certificate Policies field in root ca certificate got updated.

    So now I'm going to install new enterprise issuing ca and I want specify only:

    OID = 1.3.6.1.4.1.50000.1.2.1
    URL = "http://www.company.com/cps"

    in it's capolicy.inf file. I want to know if there will be no errors I've encountered earlier with only one oid specified. So I asked you if is it enough to specify only one OID at lower ca level? Because in our environment root ca is tied with one cps and issuing ca is tied with other cps. So I want these differences to be reflected in CAs certificates.


    Thursday, February 18, 2010 8:03 AM
  • Joson,
    that is incorrect. We have deployed numerous PKIs with multiple assurance levels.
    Contact me offline for more info
    Brian

    Monday, February 22, 2010 2:32 PM
  • Just to add some reference. We have deployed several PKIs for the US Federal Bridge
    In the US federal bridge, the CAs can assert up to Five different assurance levels (CP OIDS).
    See section 1.5 http://www.va.gov/proj/vapki/documents/FBCA_CP_v1_04_100500.doc

    Here is the declared OIDs for certificate policy from a DOD issuing CA:

    [1]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.1

    [2]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.2

    [3]Certificate Policy:
    Policy Identifier=2.16.840.1.101.3.2.1.12.3

    So in this example, tey have chosen to do rudimentary, Basic, and Medium assurance levels.
     Joson, even in the link that you posted, the issuing CA asserts *two* issuance policy OIDs, and is allowed to do it because the intermdiate CA in their example asserts the AllIssuancePolicy OID (2.5.29.32.0)

    The two OIDs asserted in your example link are:
    [Version]
    Signature= "$Windows NT$"
    [PolicyStatementExtension]
    Policies = LegalPolicy, LimitedUsePolicy
    [LegalPolicy]
    OID = 1.1.1.1.1.1.1.1.1

    [LimitedUsePolicy]
    OID = 2.2.2.2.2.2.2.2.2

    Thanks,
    Brian

    • Marked as answer by Joson Zhou Monday, March 1, 2010 8:23 AM
    Monday, February 22, 2010 2:50 PM
  • Thanks for your correction, Brian.

    Hi Rimvydas,

    How are you? We've not heard back from you in a few days and wanted to check the current status of the issue. If you need further assistance, please do not hesitate to respond back.

    Thanks.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, February 25, 2010 5:40 AM
  • Hi All,

     

    i get the same error (Active Directory Certificate Services could not create an encryption certificate.  Requested by COMPANY\user  Invalid Issuance Policies:  1.3.6.1.4.1.x.  The certificate has invalid policy. 0x800b0113 (-2146762477).)

    on a three tier ca hierarchy, i only defined the PolicyStatementExtension on the Policy CA. All CAs are Windows 2008 R2.

    [PolicyStatementExtension]
    Policies = LegalPolicy
    Critical = 0

    [LegalPolicy]
    OID = 1.3.6.1.4.1.x (x=real number)
    URL = "http://www.company.com/cps"

    Notice = "Policy Information"

    Do i need to configure the PolicyStatementExtension on the Issuing CA? Any idea?

    Thanks

    Jochen

    Monday, March 29, 2010 11:03 AM
  • Do i need to configure the PolicyStatementExtension on the Issuing CA? Any idea?

    Yes, with Server 2008 R2 it now enforces the issuance policies on subordinate CAs. So if you assert an issuance Policy oID in a policy CA, you must assert all or some of the issuance policies in the subordinate CA.

    Brian

    Monday, March 29, 2010 1:43 PM
  • Brian,

    back to this topic.

    If I want to implement a 2 tier PKI infrastructure with 1 offline root CA and 3 Enterprise issuing CAs, and I have 4 CPS (1 for the Root CA certificate, and the other 3 to each Issuing CA cert), the question is,

    Is correct to specified the 4 OIDs in the Root CA, and then 1 OID on each of the Issuing CA?

    (because the 3 Issuing CAs are intended to be use for different procedures, user authentication, computer authentication and the last for encryption).

    Thanks in advance.


    Cristian L Ruiz

    Tuesday, May 15, 2018 7:51 PM
  • I would not assert any OIDs on the Root CA.

    Then you can choose to declare one or more OIDs for each issuing CA (with no restrictions from the root). 

    One thing I should make clear is that you assert OIDs for Certificate Policies (CP), not Certification Practices Statements (CPS).

    The CPS document asserts which CPs are supported by the CPS.

    You then include all supported CPs of an issuing CA in the issuing CA certificate.

    FInally, you include a single CP in a leaf certificate indicating the exact CP used to identify the subject and protect the associated key for a specific certificate

    Brian

    Wednesday, May 16, 2018 4:35 AM