none
A required CRL extension is missing

    Question

  • Heyo!

    I'm hoping Mark gets back to me on this one, but anyone willing to help is greatly appreciated.

    I've been working on a PKI project for a fair while, who woulda thunk PKI was so complex (and important), anyway this one revolves around AD publishing of Certs and CRLs and Delta CRLs.

    A while ago someone posted about how to fix CDP locations, I did as well, seems a hot topic, which generally requires either publishing a new CRL or issuing new certs and deplying them accordinly depending on exactly where the mistake was made (in a two tier PKI enviro anyway).

    There seems to be a bit of confusion on when a computer name is required at the end of a -dspublish command, in particular with publishing CRLs. I had come to the point I was running my documentation I had done from my Test enviro into Production, and low and behold I missed somethings, Classic...

    I found that when I was attempting to publish the CRL provided from my offline root, into AD via my Sub CA, I was still getting "A required CRL extension is missing" when using certutil -dspublish -f "blah.crl".

    Now Mark very simply stated this "If you have configured the LDAP CDP path to enable the option "Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually" and have configured the DSConfigDN properly, then it is unnecessary."

    I read up on the supplied reference material, however to my dismay my DSConfigDN was configured properlly already, I can only assume this is because I didn't have "Include in CRLs" checked off under the Offline Root CA's CDPs Extension properties, in particular for the LDAP entry. 

    In my case i removed the entry completely from the Offline Root CA's CDP exemptions. Am I correct in my assumption?

    Also, what's the difference if I do set the extension proper, and re-issue my Sub CA cert, vs simply running the -dspublish command with the required parameter of a computer name at the end of it?

    Wednesday, April 11, 2018 4:51 PM

Answers

  • If that checkbox is turned off, the CRL lacks the DN location for the -dspublish. It's an easy thing to fix and nothing that requires reissuance of subordinate certificates. On the root CA, locate your CRL Extensions, on the LDAP line enable the "Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually" option. Click OK. Publish a new CRL and use that new CRL to do the DSPublish.  

    Your Subordinate CA doesn't need to be reissued because it was stamped to look at LDAP with the option you chose of "Include in the CDP Extension of issued certificates".


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    • Marked as answer by Zewwy Thursday, April 12, 2018 7:58 PM
    Wednesday, April 11, 2018 5:39 PM
  • 1) Only the DSConfigDN needs to be set

    4) You will also then need to publish that CRL to AD

    5) No need to delete request file. Just renew the CA and it will create a new request file with a (1) in the name.


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    • Marked as answer by Zewwy Thursday, April 12, 2018 7:59 PM
    Thursday, April 12, 2018 5:25 PM

All replies

  • If that checkbox is turned off, the CRL lacks the DN location for the -dspublish. It's an easy thing to fix and nothing that requires reissuance of subordinate certificates. On the root CA, locate your CRL Extensions, on the LDAP line enable the "Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually" option. Click OK. Publish a new CRL and use that new CRL to do the DSPublish.  

    Your Subordinate CA doesn't need to be reissued because it was stamped to look at LDAP with the option you chose of "Include in the CDP Extension of issued certificates".


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    • Marked as answer by Zewwy Thursday, April 12, 2018 7:58 PM
    Wednesday, April 11, 2018 5:39 PM
  • haha thanks man! ill check that later tonight. watching the Jets game! White out! Go Jets Go!
    Wednesday, April 11, 2018 11:46 PM
  • Sorry for my ignorance Mark,

    I did as you stated, however when leaving the LDAP entry as default (using the <ServerDNSName>) and applying the checkbox you stated, it seems indeed the certutil -dspublish command was attempting to use the variable set there, but it uses the Offline CA's ServerDNSName, and I get the resulting error:

    ldap: 0x20: LDAP_NO_SUCH_OBJECT: Blah blah blah

    CertUtil: -dsPublish command FAILED: 0x8007208d (WIN32: 8333 ERROR_DS_OBJ_NOT_FOUND)

    Well yeah of course it doesn't exist, it's not a domain joined systems, it's offline...

    And I suppose to provide the FQDN of my SubCA in the LDAP entry of the CDP Extension? My DC's? I figured for LDAP that the DC's would be providing these files, I'd feel odd having a LDAP share on my SubCA but if that's how it works, that's how it works.

    Again so sorry for my ignorance here. Thanks for all your help. I'm kind of embarrassed after so much time working on this I'm still not getting it properly.

    Ugh, I quickly double checked the proper default configuration line for ldap, and I had it all wrong. going to try to do it proper this time, total PEBAC.... Facepalm... I'm not having a good day.


    • Edited by Zewwy Thursday, April 12, 2018 2:43 PM
    Thursday, April 12, 2018 2:28 PM
  • What syntax are you using to publish? You will need to include the -f in the publish to force the creation of the destination object. You are not creating “an LDAP share”. Not even sure that is a thing. You are publishing the CRL to AD which will be retrieved from domain controllers. Your subca will not be involved in the process.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com


    Thursday, April 12, 2018 2:38 PM
  • Well I swear I had it right this time... the line in my Offline Root's CA Properties -> Extensions -> CRL Distribution Points -> ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

    Left only "Include in all CRLs. Specifies where to publish in AD when publishing manually."

    Ran the -dspublish command got this error:

    I can not figure this out! ARRRRGGG

    Thursday, April 12, 2018 3:27 PM
  • That's what I figured, so why is it getting these values wrong?! This is clearly a huge mess caused by myself I feel. AKA punching myself in the face.

    hahah "LDAP Share", what was I thinking... Time to have some more coffee, step back read a bit more, then try again.

    Reading this right now...

    • Edited by Zewwy Thursday, April 12, 2018 4:15 PM
    Thursday, April 12, 2018 3:30 PM
  • Is your DSConfigDN set properly? The publish error says it doesn't know your DS info. If it is set, did you restart ADCS to read the registry and THEN publish a new CRL after setting DSConfigDN to pick up that value? Also, your LDAP line doesn't have the "Include in the CDP extension of issued certificates" so nothing will actually look at AD to pick up the CRL. If you want to use LDAP for that, you will need to turn on that option and reissue your subordinate CA certificates.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, April 12, 2018 4:44 PM
  • Thanks for the reply mark, I double checked the blog I followed and the link I shared in my previous post. There seemed to have been a bit of confusion on my part (Clearly hahaha).

    1) Is your DSConfigDN set properly?

    The first time I checked this I checked this and SET this on The SUB CA, from reading the TechNet Post I shared above, the user is stating that they are setting this on the Offline Root CA! This seems to be were the confusion and mistakes are taking place.

    So...

    "Your Subordinate CA doesn't need to be reissued because it was stamped to look at LDAP with the option you chose of "Include in the CDP Extension of issued certificates"."

    This only applies, when this is also checked off,

    "Also, your LDAP line doesn't have the "Include in the CDP extension of issued certificates" so nothing will actually look at AD to pick up the CRL. If you want to use LDAP for that, you will need to turn on that option and reissue your subordinate CA certificates."

    I'll need to do the following to fix this all.

    1) Set the DSConfigDN setting on the Offline Root CA, as well as the DSDomainDN.
    (Both things that were not covered by the initial blog post I was following)

    2) Ensure the LDAP entry is correct with "Include in CRLs For AD Publish" and Include in Signed Certs.

    3) Restart CertSrv on Offline Root CA

    4) Right click revoked Certs -> publish new CRL

    5) Delete old req file on Sub-CA, generate new Sub-CA Cert

    6) Sign Sub-CA req by Offline root CA.

    7) Import new cert into Sub-CA. (The Copied offline root cert shouldn't have changed)

    8) I already published the Offline Root cert so no need to do that again (certutil -dspublish -f "Offkine-Cert.crt"), However I will need the new CRL file I published in step 4. Assuming everything was done correctly, I should be able to publish the CRL WITHOUT specifying a comp object name at the end of the command. (certutil -dspublish -f "New-Offline-CRL.crl")

    Fingers crossed I'll report back if it worked.

    Thanks again for your patients with me.


    • Edited by Zewwy Thursday, April 12, 2018 5:21 PM
    Thursday, April 12, 2018 5:21 PM
  • 1) Only the DSConfigDN needs to be set

    4) You will also then need to publish that CRL to AD

    5) No need to delete request file. Just renew the CA and it will create a new request file with a (1) in the name.


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    • Marked as answer by Zewwy Thursday, April 12, 2018 7:59 PM
    Thursday, April 12, 2018 5:25 PM
  • 1) I'll test by simply altering this one field first.

    4) Indeed I stated that further down at step 8 :P

    5) I'll try that again but did you forget about this? :P Maybe it was a bug in my case. I'll see if its replicatable.

    Just to double check with you, you stated only teh first needs to be set, the Post I shared where he fixed this set both values, and set them as follow:

    The first command in this article seemed to be duplicating data I already had

    certutil -setreg ca\DSConfigDN "CN=Configuration, DNpath "

    The second command was adding data which I DIDN'T have in my RootCA's registry. I've run this command as so:

    certutil -setreg ca\DSDomainDN "DC=domain,DC=internal "

    Should I do the same or... just this?

    certutil -setreg ca\DSConfigDN "DC=domain,DC=local"


    • Edited by Zewwy Thursday, April 12, 2018 5:37 PM
    Thursday, April 12, 2018 5:33 PM
  • 5) You wouldn't be reusing the request file. The CA will create a new one. When you renew the CA it will create an entirely new request file with (1) in the name.

    You only need to run:

    certutil -setreg ca\DSConfigDN "CN=Configuration,DC=Your,DC=Domain"


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, April 12, 2018 5:41 PM
  • OMG Finally! the command worked without needing to specify a computer name object at the end of it!!!

    WoooHoooo!

    Thanks for teaching me the ways Mark!

    Thursday, April 12, 2018 6:29 PM
  • Nice work!

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, April 12, 2018 6:40 PM
  • Thank again. Also yes, for some reason running through the renewing of the Sub-CA Certificate I was able to renew simply with the CertUtil -RenewCert ReuseKeys, and it generated a new CSR exactly like it should. I have no clue why it was erroring out on my the last time I attempted to do it. :S oh well.

    Also final question that was kind of missed being answered:

    What's the difference if I do set the extension proper, and re-issue my Sub CA cert, vs simply running the -dspublish command with the required parameter of a computer name at the end of it?

    Like it's nice having figure out exactly when and when not a object name needs to be specified with the -dspublish option when publishing a CRL. But what exactly is the difference from my setting the DSConfigDN on the Offline Root, Vs simple not configuring it, and publishing via "CertUtil -dspublish "PATH\CRL.crl" RootCa"?

    • Edited by Zewwy Thursday, April 12, 2018 8:04 PM
    Thursday, April 12, 2018 8:00 PM