none
CA generates bad KDC Certificates; i.e. "..._NOT_VALID_FOR_USAGE" RRS feed

  • Question

  • I'm not sure how long this has been an issue for me as Certificates show OK when MMC viewed; always did and still do.  But, a recent EventID20 brought the issue to my attention; i then tested via CertUtil -dcinfo Verify and learned of the CERT_TRUST_IS_NOT_VALID_FOR_USAGE error.

    There are 2 DC's; WS'03r2x64sp2 with current updates.  CA Root is on one of them; i realize this is a hi-risk installation but it's the point we're at now.

    The eID20 error first surfaced while pursuing an SQL`05 Reporting Services installation on a DC where the Root CA is.  (I know that this is a bad build scheme but it's budget limited.)  For the R/S installation, i had to enable 32bit ASP on IIS > Web Extensions.  Ultimately, I got Reporting Services installed and working.  However, shortly thereafter the KDC eID20 event popped up.

    Realizing i screwed up, i removed all of the SQL`05 stuff; including R/S!!!  I reverted IIS back to 64bit ASP as per kb894435.  At this point i would leave SSL enabled for CertEnroll>Directory Security and pkiView would show status of all the http locations as Bad.  I would then disable the said SSL and pkiView would show these http locations as OK;  i could copy the URL's to IE and get a file!  Also, i could IE browse host.domain.local\CertSrv\.

    I went on with different methods to replace the bad KDC Certs; e.g. -dcinfo DeleteBad, used Certs/localComputer & deleted all bad or expired, reboots, and on and on.  I did these methods while said SSL was enabled and again while disabled; didn't seem to matter.  Now, i can't even IE browse CertSrv; http or https.  I applied Kb979892 (IIS patch) hoping that would help; it didn't.  Now i'm just exhausted, floundering, and hoping for the forum to find me a gracious expert that can help this wannabe pkiAdmin resolve this dilema.

    I'm guessing my CertEnroll configuration is screwed up; e.g. SSL settings, ASP configuration, ...  i'm currently at a loss. 

    Thanks 


    Glenn of xSyLent
    • Edited by GlennXS Monday, August 2, 2010 1:17 AM more detail
    Monday, August 2, 2010 12:19 AM

Answers

  • Hi,

    The error CERT_TRUST_IS_NOT_VALID_FOR_USAGE is reported in the certutil output because the Windows Server 2003 version of certutil is hard code to evaluate the KDC certificate for the Smart Card Logon OID:

    dwFlags = CA_VERIFY_FLAGS_NT_AUTH (0x10)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
    Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    As you are using the V1 Domain Controller certificate template, the KDC certificate does not contain the Smart Card Logon OID

      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc1.Bowman.local
      Serial: 6138a04600000000000e
      Template: DomainController
      3d 1a 2c c4 a6 78 4c b1 22 06 96 77 d6 47 b9 90 9f f8 d4 cb
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
        CRL 447:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        80 8b 48 8c d1 e1 3d 76 6b 90 e7 43 d1 42 82 a0 62 4e ef e5
        Delta CRL 449:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        b4 7b 9b 68 12 db 5d cf 34 c0 2c 5f 67 9e 75 58 79 f0 9a fc
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

    As a result, the error CERT_TRUST_IS_NOT_VALID_FOR_USAGE is reported. However, this template is completely OK to use for smart card authentication.

    This issue has been fixed in Windows Server 2008 version of certutil.exe.

    In this case, as for the event KDC 20, we cannot verify the KDC certificate by using the certutil -dcinfo command. Please open the Computer Personal Store and verify that the domain controller certificate is not expired. After that, please restart the server and check if event occurs again.

    If the issue continues, please export the domain controller certification, save as a .crt file, run certutil -verify -urlfetch Cert.crt and post the output here.

    Note: Please replace cert.crt with the exact file name of the certificate file.

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by GlennXS Monday, August 9, 2010 8:32 PM
    Friday, August 6, 2010 2:31 AM
    Moderator
  • Sorry to say, but to use that template you need to install the CA on enterprise version of w2k3. So the only thing is to ignore it until you can migrate the CA.

     

    • Marked as answer by GlennXS Monday, August 9, 2010 8:31 PM
    Monday, August 9, 2010 8:15 PM
  • Hi Glenn, it depends on what kind of PKI setup you want. Usually the ones most used is a 2.tier where the Root CA is offline (not a enterprise root CA, but a standalone), and a domain joined w2k3/w2k8 Enterprise server for the subordinate CA. Note it's the CA who does the actual issuing of end certificates (for clients and servers) that needs to reside on the enterprise version of the server OS (this can be installed on a DC with the Enterprise version of the OS).

    If you just want 1.tier PKI just stick the Enterprise Root CA on a system with the Enterprise version of the OS. I have not tested if it is possible to migrate the one you have to a server with Enterprise version of the OS. It might be possible, but not sure if you can just import the copy of the registry of the old server, and get it to start using templates for 2003. Maby some one else have tested this and can give a chime to if it is possible.

    The issue you have with the enterprise root is that it needs to be online as it is integrated into AD, you could probably just set up a subordinate on a DC with the Enterprise version of the OS, and use this to issue certificates based on the DCA template. It all depends on you'r security policies and if it tolerable to keep the Root CA online.

    So you have 3 choices:
    1)  Migrate the one you have to a server with the Enterprise OS installed (not sure if this works)
    2)  Install a new 2.tier PKI, with an offline standalone Root CA, and a domain joined subordinate CA on a enterprise server OS version.
    3)  Install a subordinate to the Enterprise Root CA on a server with the Enterprise version of the OS and issue DCA certificates form this. (Both CA has to be online)

    Regards
    Morten

    • Marked as answer by GlennXS Tuesday, August 10, 2010 7:56 AM
    Tuesday, August 10, 2010 7:40 AM
  • If that is the way you want to go, then yes.
    If you run any virtual machines,  you could put the Root there or both. Also be aware if you want to go with an offline Root CA, you will need to cook up a scheme for publishing the CRL at the configured time interval. With the server offline you could bring it online or use usb stick or something to publish. For our test environments I configured an online server behind a firewall that automatically publish the CRL. Either way it's important to go into this with both eyes open as design choices brings different challenges.

    The easy way is to configure a new Enterprise Root CA on a server with the Enterprise Edition. Then you cut out the extra hassle with a 2.tier PKI. But again it depends on your security policies.

    Best of luck
    Morten

     

    • Marked as answer by GlennXS Tuesday, August 10, 2010 9:16 AM
    Tuesday, August 10, 2010 8:09 AM

All replies

  • Hi,

    CERT_TRUST_IS_NOT_VALID_FOR_USAGE means the certificate is used for a purpose that is different from its enhanced key usage. Please confirm if the Client Authentication and Server Authentication are included in the Enhanced Key Usage of the domain controller certificate.

    Meanwhile, please post the output of the certutil -dcinfo verify here for further research.

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, August 5, 2010 6:50 AM
    Moderator
  • Did see this once implementing smartcard logon and enrolling DC certificates. The reason I got the same error was that autoenrollment was not used (I manually triggered autoenrollment for the DC certificates), and that seemd to generate this problem. Solution was to get autoenrollment to do the job enrolling the DC certificates. 

    You will also see the problem doing what Joson suggests (certutil -dcinfo on the DC).
    Thursday, August 5, 2010 8:20 AM
  • Hi Joson and thanks for the reply/advice!

    I confirmed that Client Authentication and Server Authentication are included in the Enhanced Key Usage of these domain controller certificates; i checked that of both DC's.  The output from -dcinfo verify follows:

    C:\WINDOWS>CertUtil -dcinfo verify
    0: DC1
    1: DC0

    *** Testing DC[0]: DC1
    ** Enterprise Root Certificates for DC DC1
    Certificate 0:
    Serial Number: 626fb02fbeef3fb3443ac55596b57fc7
    Issuer: CN=Enterprise Root, DC=Bowman, DC=local
    Subject: CN=Enterprise Root, DC=Bowman, DC=local
    CA Version: V0.0
    Signature matches Public Key
    Root Certificate: Subject matches Issuer
    Cert Hash(sha1): 77 67 8e 06 f6 7e e4 7e 2e 5d 69 0e 27 79 9b e7 e7 8a 4b 50

    ** KDC Certificates for DC DC1
    Certificate 0:
    Serial Number: 6138a04600000000000e
    Issuer: CN=Enterprise Root, DC=Bowman, DC=local
    Subject: CN=dc1.Bowman.local
    Certificate Template Name: DomainController
    Non-root Certificate
    Template: DomainController, Domain Controller
    Cert Hash(sha1): 3d 1a 2c c4 a6 78 4c b1 22 06 96 77 d6 47 b9 90 9f f8 d4 cb

    dwFlags = CA_VERIFY_FLAGS_NT_AUTH (0x10)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
    Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_NT_AUTH
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
    ChainContext.dwRevocationFreshnessTime: 21 Hours, 55 Minutes, 28 Seconds

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
    SimpleChain.dwRevocationFreshnessTime: 21 Hours, 55 Minutes, 28 Seconds

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=10
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc1.Bowman.local
      Serial: 6138a04600000000000e
      Template: DomainController
      3d 1a 2c c4 a6 78 4c b1 22 06 96 77 d6 47 b9 90 9f f8 d4 cb
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
        CRL 447:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        80 8b 48 8c d1 e1 3d 76 6b 90 e7 43 d1 42 82 a0 62 4e ef e5
        Delta CRL 449:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        b4 7b 9b 68 12 db 5d cf 34 c0 2c 5f 67 9e 75 58 79 f0 9a fc
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=Enterprise Root, DC=Bowman, DC=local
      Serial: 626fb02fbeef3fb3443ac55596b57fc7
      77 67 8e 06 f6 7e e4 7e 2e 5d 69 0e 27 79 9b e7 e7 8a 4b 50
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    Exclude leaf cert:
      9f 43 16 10 5e 94 2a d7 e5 bc b5 a7 97 a3 c1 02 3c 52 5c 66
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc1.Bowman.local
      Serial: 6138a04600000000000e
      Template: DomainController
      3d 1a 2c c4 a6 78 4c b1 22 06 96 77 d6 47 b9 90 9f f8 d4 cb
    The certificate is not valid for the requested usage. 0x800b0110 (-2146762480)
    ------------------------------------
    1 KDC certs for DC1

    *** Testing DC[1]: DC0
    ** Enterprise Root Certificates for DC DC0
    Certificate 0:
    Serial Number: 626fb02fbeef3fb3443ac55596b57fc7
    Issuer: CN=Enterprise Root, DC=Bowman, DC=local
    Subject: CN=Enterprise Root, DC=Bowman, DC=local
    CA Version: V0.0
    Signature matches Public Key
    Root Certificate: Subject matches Issuer
    Cert Hash(sha1): 77 67 8e 06 f6 7e e4 7e 2e 5d 69 0e 27 79 9b e7 e7 8a 4b 50

    ** KDC Certificates for DC DC0
    Certificate 0:
    Serial Number: 61398ae500000000000f
    Issuer: CN=Enterprise Root, DC=Bowman, DC=local
    Subject: CN=dc0.Bowman.local
    Certificate Template Name: DomainController
    Non-root Certificate
    Template: DomainController, Domain Controller
    Cert Hash(sha1): 21 eb 98 fd d7 4f b6 c8 5c b6 8d 28 23 18 ef a0 95 8c e9 d3

    dwFlags = CA_VERIFY_FLAGS_NT_AUTH (0x10)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
    Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_NT_AUTH
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
    ChainContext.dwRevocationFreshnessTime: 21 Hours, 55 Minutes, 28 Seconds

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
    SimpleChain.dwRevocationFreshnessTime: 21 Hours, 55 Minutes, 28 Seconds

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=10
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc0.Bowman.local
      Serial: 61398ae500000000000f
      Template: DomainController
      21 eb 98 fd d7 4f b6 c8 5c b6 8d 28 23 18 ef a0 95 8c e9 d3
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
        CRL 447:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        80 8b 48 8c d1 e1 3d 76 6b 90 e7 43 d1 42 82 a0 62 4e ef e5
        Delta CRL 449:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        b4 7b 9b 68 12 db 5d cf 34 c0 2c 5f 67 9e 75 58 79 f0 9a fc
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=Enterprise Root, DC=Bowman, DC=local
      Serial: 626fb02fbeef3fb3443ac55596b57fc7
      77 67 8e 06 f6 7e e4 7e 2e 5d 69 0e 27 79 9b e7 e7 8a 4b 50
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    Exclude leaf cert:
      78 cc 26 e3 5a 89 80 94 1f 63 a8 fa c2 4a d7 5b 85 ee cc 22
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc0.Bowman.local
      Serial: 61398ae500000000000f
      Template: DomainController
      21 eb 98 fd d7 4f b6 c8 5c b6 8d 28 23 18 ef a0 95 8c e9 d3
    The certificate is not valid for the requested usage. 0x800b0110 (-2146762480)
    ------------------------------------
    1 KDC certs for DC0

    CertUtil: -DCInfo command completed successfully.

    -I can see that i need to learn how to interpret/understand the implication of "context[x][y]" sections!  Can u recommend a good spot for such within TechNet libraries?

     


    Glenn of xSyLent
    Thursday, August 5, 2010 4:09 PM
  • Hi Lerun and thanks for the reply!

    The Policy Module is using the Windows Default: "-Follow the settings in the Certificate Template, if applicable.  Otherwise, automatically issue the certificate."  Is this the AutoEnrollment provisions u r speaking of?  Our installation is very simple/primitive, however, i'm making an effort to get it where is should be (as recommended).  -I suspect that the NOT_VALID_ resolve regards the  ...

    Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
    Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    ... applications, however, i don't know what to do about it.  The Certificate has the Enhanced Key Usage spec' that Joson advised of but i don't know y CA resolved the Certificate applications as noted above.  -Don't know what to do about it either (yet).  Do u know if my suspicions r correct?  Do u any recommendations on what i should check/do next?


    Glenn of xSyLent
    Thursday, August 5, 2010 4:28 PM
  • Actually this is the same error I was having. Have you set up a GPO allowing autoenrollment for the Domain Controller OU where this DCs resides?

    Can do this under the machine settings --> Security Settings --> Public Key Policies --> Autoenrollment (depending on if this is 2003 or 2008). Just enable all the settings there.

    Check that the certificate template has "read, enroll and autoenroll" for the Domain Controller security group. Do a gpupdate /force on the DCs and the certificates should get enrolled (don't forget to remove the old ones from the DC). You may need to do a reboot if gpupdate does not work.

    Regards
    Morten

    Thursday, August 5, 2010 5:17 PM
  • Hi,

    The error CERT_TRUST_IS_NOT_VALID_FOR_USAGE is reported in the certutil output because the Windows Server 2003 version of certutil is hard code to evaluate the KDC certificate for the Smart Card Logon OID:

    dwFlags = CA_VERIFY_FLAGS_NT_AUTH (0x10)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
    Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    As you are using the V1 Domain Controller certificate template, the KDC certificate does not contain the Smart Card Logon OID

      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc1.Bowman.local
      Serial: 6138a04600000000000e
      Template: DomainController
      3d 1a 2c c4 a6 78 4c b1 22 06 96 77 d6 47 b9 90 9f f8 d4 cb
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
        CRL 447:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        80 8b 48 8c d1 e1 3d 76 6b 90 e7 43 d1 42 82 a0 62 4e ef e5
        Delta CRL 449:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        b4 7b 9b 68 12 db 5d cf 34 c0 2c 5f 67 9e 75 58 79 f0 9a fc
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

    As a result, the error CERT_TRUST_IS_NOT_VALID_FOR_USAGE is reported. However, this template is completely OK to use for smart card authentication.

    This issue has been fixed in Windows Server 2008 version of certutil.exe.

    In this case, as for the event KDC 20, we cannot verify the KDC certificate by using the certutil -dcinfo command. Please open the Computer Personal Store and verify that the domain controller certificate is not expired. After that, please restart the server and check if event occurs again.

    If the issue continues, please export the domain controller certification, save as a .crt file, run certutil -verify -urlfetch Cert.crt and post the output here.

    Note: Please replace cert.crt with the exact file name of the certificate file.

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by GlennXS Monday, August 9, 2010 8:32 PM
    Friday, August 6, 2010 2:31 AM
    Moderator
  • Hi Morten; i think u r on to something as i worked on this as per your prescription but i still have the same problem!

    Hi Joson; i'm looking forward to digesting your prescription, however, i'm bushed now and calling it a night.  I'll dig into your prescription first thing tomorrow.

    Morten:  In following your prescription; i did, i saw some settings here that seemed to conflict with AutoEnrollment.  I changed them to align with your advice and followed thru only to find the same error.  However, I feel good about where it's going.  I'll post the exact changes i made tomorrow along with the corresponding -dcinfo verify status.


    Glenn of xSyLent
    Friday, August 6, 2010 3:12 AM
  • Taking into account what Joson posted, I remember using the V2 template Domain Controller Authentication and not the Domain Controller template. But I had the same error before I configured autenrollment to automatically distribute the certificate. Using the MMC snappin and enrolling the certificate this way made certutil dump the same error. Did not clear until autoenrollment pushed the certificate for me...

     

    Friday, August 6, 2010 8:36 AM
  • Hi Morten,

    i found the AutoEnrollment status to be Not Allowed for the Domain Controller template and Allowed for Domain Controller Authentication template.  I found the Domain Controller Group permissions to be enabled for only Enroll of the Domain Controller Template and enabled for only Enroll and AutoEnrollment the Domain Controller Authentication Template.  I added the Domain Controller Group Read permission to these two templates.  Of the PK Policies-AutoEnrollment settings, I found Enroll Certificates Automatically to be the only option to be enabled; i enabled the two options below it; i.e. Renew ... and Update ...  Were these the settings u are referring to?   I then did DeleteBad and then /force on both DC's and the KDC Certs did not enroll.  I rebooted both DC's and both DC's had new KDC Certs enrolled!

    However, the AutoEnrollment status within the Template Management context is still Not Allowed for the Domain Controller Template and i'm concerned about this.  Could this b related to the persistant ..._NOT_VALID... error?  Shouldn't this status be Allowed?  Is any of this related to the SSL tunings i did as noted in my original post?

    Thanks Morten!  I'm looking forward to your comments.


    Glenn of xSyLent
    Friday, August 6, 2010 5:02 PM
  • Hi Joson!

    U'v provided me with lots to digest; i'm working on it.  I've since learned a bit about the 2 subject templates; Domain Controller(v4.1) & Domain Controller Authentication(v110).  -I'm using the versions as subscripted.  I'm not sure i understand what u r saying about CertUtil of WS'03 having an issue; not having the ability to accurately assess a scenario such as i have.  How can this be?  R those with heavily productive domains to reboot and look for KDC20 errors (or not) whenever there is a seemingly related problem?  (However, our domain implementation will afford time for me to do this.)  -I see that the superceding template; DC Authentication, will allow me to Remove the SmartCard application policy; couldn't i do this, regenerate new KDC Certs without having the _NOT_VALID error, and then b able to depend upon CertUtil to accurately assess the scenario?

    I had a few questions for Lerun in my recent reply ... 1) i suspect the Not Allowed concern is relieved by the virtue of the superceding DCA template having Allowed status; am i right here?  Could u comment on any of those other questions; e.g. SSL issue?

    I still have the _NOT_VALID condition and am contemplating deleting the Smart Card policy as aforementioned; any comments here?  I assumed defaults while exporting and cer file of such follows:

    F:\Tmp0>CertUtil -verify DC.cer
    Issuer:
        CN=Enterprise Root
        DC=Bowman
        DC=local
    Subject:
        CN=dc0.Bowman.local
    Cert Serial Number: 61038aad000000000013

    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwRevocationFreshnessTime: 17 Minutes, 48 Seconds

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwRevocationFreshnessTime: 17 Minutes, 48 Seconds

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=dc0.Bowman.local
      Serial: 61038aad000000000013
      Template: DomainController
      ca d1 b5 74 ce 0f 0b ab 92 05 32 76 1e e4 9e bf c9 2d c2 91
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
        CRL 447:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        80 8b 48 8c d1 e1 3d 76 6b 90 e7 43 d1 42 82 a0 62 4e ef e5
        Delta CRL 451:
        Issuer: CN=Enterprise Root, DC=Bowman, DC=local
        89 fb 78 f8 f5 8f 6a 35 be 66 51 75 96 5d a1 68 4d 42 40 39
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Enterprise Root, DC=Bowman, DC=local
      Subject: CN=Enterprise Root, DC=Bowman, DC=local
      Serial: 626fb02fbeef3fb3443ac55596b57fc7
      77 67 8e 06 f6 7e e4 7e 2e 5d 69 0e 27 79 9b e7 e7 8a 4b 50
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    Exclude leaf cert:
      24 d7 7f 51 bc d5 12 b3 b3 6a 46 20 62 c3 b4 dc 97 1a 4e 97
    ------------------------------------
    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.5.5.7.3.1 Server Authentication
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.

    Thanks Joson and i'm looking forward to your reply.

     


    Glenn of xSyLent
    • Edited by GlennXS Friday, August 6, 2010 6:24 PM clarification
    Friday, August 6, 2010 6:21 PM
  • Hi Morten,

    i found the AutoEnrollment status to be Not Allowed for the Domain Controller template and Allowed for Domain Controller Authentication template.  I found the Domain Controller Group permissions to be enabled for only Enroll of the Domain Controller Template and enabled for only Enroll and AutoEnrollment the Domain Controller Authentication Template .  I added the Domain Controller Group Read permission to these two templates.  Of the PK Policies-AutoEnrollment settings, I found Enroll Certificates Automatically to be the only option to be enabled; i enabled the two options below it; i.e. Renew ... and Update ...   Were these the settings u are referring to?   I then did DeleteBad and then /force on both DC's and the KDC Certs did not enroll.  I rebooted both DC's and both DC's had new KDC Certs enrolled!

    However, the AutoEnrollment status within the Template Management context is still Not Allowed for the Domain Controller Template and i'm concerned about this.  Could this b related to the persistant ..._NOT_VALID... error?  Shouldn't this status be Allowed ?  Is any of this related to the SSL tunings i did as noted in my original post?

    Thanks Morten!  I'm looking forward to your comments.


    Glenn of xSyLent

    Hi Glenn

    You just need one of the templates. The Domain Controller template is the old version, just forget about it. Use only the Domain Controller Authentication template, so if certificates from this gets pushed automatically you are good to go. These two templates do the same thing, difference lie in template version. 

    The settings in the GPO sounds right.

     

     

    Monday, August 9, 2010 6:54 AM
  • Hi Morten!

    I tried a dry-run; i requested a new KDC Cert (before doing DeleteBad) and Domain Controller is the only type available for me to choose from. (-Is this a reference to the template of that name).  I then canceled out.  When i do Template>Manage from with the CA snap-in, i c the Domain Controller Authentication template, however, i can't seem to get this template to appear in the Certificate Templates folder of CA.  I suspect this is y it doesn't show up when i Request New.  Forgive my CA inabilities, but how do i do this?  Also, should i delete the SmartCard option from Application Policies of the DCA template; e.g. make a duplicate of the DCA template and delete SmartCard from the dup and then use the dup in the Request?  We don't do the SmartCard stuff over here!

    I enabled the Publish in Active Directory option within the DCA template, applied it, restarted CA, however, the DCA template still did appear in CA>Certificate Templates and it still wasn't an option to choose from when doing Request New.

    This is getting exciting; it doesn't take much for me anymore!

    Thanks,

     


    Glenn of xSyLent
    • Edited by GlennXS Monday, August 9, 2010 8:15 AM update
    Monday, August 9, 2010 8:00 AM

  • Hi Morten!

    I tried a dry-run; i requested a new KDC Cert (before doing DeleteBad) and Domain Controller is the only type available for me to choose from. (-Is this a reference to the template of that name).  I then canceled out.  When i do Template>Manage from with the CA snap-in, i c the Domain Controller Authentication template, however, i can't seem to get this template to appear in the Certificate Templates folder of CA.  I suspect this is y it doesn't show up when i Request New .  Forgive my CA inabilities, but how do i do this?  Also, should i delete the SmartCard option from Application Policies of the DCA template; e.g. make a duplicate of the DCA template and delete SmartCard from the dup and then use the dup in the Request ?  We don't do the SmartCard stuff over here!

    I enabled the Publish in Active Directory option within the DCA template, applied it, restarted CA, however, the DCA template still did appear in CA>Certificate Templates and it still wasn't an option to choose from when doing Request New .

    This is getting exciting; it doesn't take much for me anymore!

    Thanks,

     


    Glenn of xSyLent


    Don't alter the DCA certificate template, don't worry about the SmartCard policies. This only tells users of the certificate that it can be used for smartcard logon also.
    I may have misunderstood your previous post, but it sounded like you got the autoenrollment going.

    So in the CA managment console, the DCA template is not published? When you right click Certificate Template folder and choose new certificate template to issue, do you see the DCA template. If NO I suspect that this CA is installed on a standard OS and not the Enterprise version? For 2003/2008 Standard you can not use V2/V3 templates, this is only reserved for the Enterprise version.

    For DCA template to issue certificates it needs to be published by the CA (can see it in the certificate template folder in the CA management tool), Domain Controller groups must have Read, Enroll and autoenroll rights on the DCA template. GPO for domain controllers must allow automatic enrollment (all the settings there should be checked).

    Hope we have come one step further in finding a solution for you.

     

    Monday, August 9, 2010 11:00 AM
  • Hi Morten,

    I did get autoenrollment going and it's setup as u prescribed, however, the template used is Domain Controller (not Domain Controller Authentication).  When i select Certificate Template to Issue from the CA mmc, the enumeration of choices goes from Code Signing to Enrollment Agent; the DCA (Domain Controller Authentication) template is not presented.  However, i do see the DCA template when i select to Manage templates.  -That's a little confusing; i can Manage it but not Issue it?  Though, i do see that the Minimum Supported CAs type for the DCA template is WS03, Enterprise.

    I do have Read, Enroll, and Autoenroll permissions set for the DCA template; just can't issue it.  Peculiar: version is V3 when viewed from the Details tab on an issued KDC Certificate; hmmm.

    It was a great learning experience for me, however, i still have the _NOT_VALID_ state when tested by CertUtil.  Am I stuck with this situation unless i move CA to WS03 Enterprise host?  -As Joson said; Ignore it unless a KDC20 event pops up?

    Thanks


    Glenn of xSyLent
    • Edited by GlennXS Monday, August 9, 2010 6:22 PM clarification/grammer
    Monday, August 9, 2010 4:21 PM
  • Sorry to say, but to use that template you need to install the CA on enterprise version of w2k3. So the only thing is to ignore it until you can migrate the CA.

     

    • Marked as answer by GlennXS Monday, August 9, 2010 8:31 PM
    Monday, August 9, 2010 8:15 PM
  • Thanks for sticking with me through this!  I really appreciate that!

    Can u tell me more specifically what the minimum deployment of Enterprise Edition would be for my build?  Of my domain build, I have only two DC's and they both are '03 Standard Editions.  I want to incorporate 2 more servers; 1) a stand alone server; domain member, to host Exchange (now, Exchange is installed on a DC).  2) an isolated box for the Enterprise Root CA.

    I was thinking that the domain server could also host a Subscribing CA; i.e. not the Enterprise Root CA.  I'm thinking the DC's would have to be Enterprise Edition to use the DCA template; am i right?  I'm  hoping that it would be suffice to only have one Enterprise Edition in the domain; e.g. the Subscribing CA.  Could u clarify for me?

    Thanks again Morten!!!

     


    Glenn of xSyLent
    Monday, August 9, 2010 8:45 PM
  • Hi Glenn, it depends on what kind of PKI setup you want. Usually the ones most used is a 2.tier where the Root CA is offline (not a enterprise root CA, but a standalone), and a domain joined w2k3/w2k8 Enterprise server for the subordinate CA. Note it's the CA who does the actual issuing of end certificates (for clients and servers) that needs to reside on the enterprise version of the server OS (this can be installed on a DC with the Enterprise version of the OS).

    If you just want 1.tier PKI just stick the Enterprise Root CA on a system with the Enterprise version of the OS. I have not tested if it is possible to migrate the one you have to a server with Enterprise version of the OS. It might be possible, but not sure if you can just import the copy of the registry of the old server, and get it to start using templates for 2003. Maby some one else have tested this and can give a chime to if it is possible.

    The issue you have with the enterprise root is that it needs to be online as it is integrated into AD, you could probably just set up a subordinate on a DC with the Enterprise version of the OS, and use this to issue certificates based on the DCA template. It all depends on you'r security policies and if it tolerable to keep the Root CA online.

    So you have 3 choices:
    1)  Migrate the one you have to a server with the Enterprise OS installed (not sure if this works)
    2)  Install a new 2.tier PKI, with an offline standalone Root CA, and a domain joined subordinate CA on a enterprise server OS version.
    3)  Install a subordinate to the Enterprise Root CA on a server with the Enterprise version of the OS and issue DCA certificates form this. (Both CA has to be online)

    Regards
    Morten

    • Marked as answer by GlennXS Tuesday, August 10, 2010 7:56 AM
    Tuesday, August 10, 2010 7:40 AM
  • Thanks a bunch Morten!  So bottom line is that i need to procure one Enterprise license (DC with Subordinate CA), another Standard Edition for the Root CA in a standalone configuration, supporting hardware, and reshuffle the deck for 2.tier PKI.  (Please correct me if i'm wrong.)

    Thanks again and Cheers!

     


    Glenn of xSyLent
    Tuesday, August 10, 2010 7:59 AM
  • If that is the way you want to go, then yes.
    If you run any virtual machines,  you could put the Root there or both. Also be aware if you want to go with an offline Root CA, you will need to cook up a scheme for publishing the CRL at the configured time interval. With the server offline you could bring it online or use usb stick or something to publish. For our test environments I configured an online server behind a firewall that automatically publish the CRL. Either way it's important to go into this with both eyes open as design choices brings different challenges.

    The easy way is to configure a new Enterprise Root CA on a server with the Enterprise Edition. Then you cut out the extra hassle with a 2.tier PKI. But again it depends on your security policies.

    Best of luck
    Morten

     

    • Marked as answer by GlennXS Tuesday, August 10, 2010 9:16 AM
    Tuesday, August 10, 2010 8:09 AM