none
Fix CDP location on Offline Root CA

    Question

  • I almost completed my in house guide of our PKI renewal.

    See here and here for some interesting issues I had to fight along the way.

     Now following the initial blog guide I went through everything just fine according to me reading through everything again.

    For me sadly the Enterprise PKI was showing failure, my first failure was that the Root Offline CA was not trusted. The guide didn't provide any further details other than to add the offline crt and crl files to the subCA CertSrv/CertEnroll folder. Which I did, and my first attempts to validate the certificate chain directly on the SubCA server showed (at first to be fine)..

    Certutil -viewstore my <serial>

    after enabling remote IIS mgmt feature, registry, and service start (I wanted to see why https wasn't working, and it is core). After this change I opened up the console to the server and to my dismay it then stated the cert chain was no longer trusted and that the offline root CA was not under the SubCA's Trusted Root CA store (I have no clue what happened).

    Either way no member servers or end devices were getting the offline Root CA into their Trusted CA stores... so More Technet posts, and more lovely help From no one other than Mark Cooper...

    Sure enough the initial answers from Bill were dead on:

    Command is:                    certutil -dspublish -f "Your New CACert Filename.crt" RootCA
    Command for the CRL is:   certutil -dspublish -f "CRL filename.crl" <COMP OBJECT>

    Except for me the CRL command failed, so I had to find this...

    Seems Bill forgot to add the Computer argument to the end of the CRL publishing command, Bolded for correction.

    So at this point a couple GP updates or certutil -pulse (Thanks again Mark)

    So after ALL This I thought I was good to go, to my dismay (AGAIN) I guess I made a mistake when I was editing the CDP extensions of my Offline Root CA.

    Under Configuring CA Extensions of the Blog I was following didn't provide good snippets of all the settings he was actually making changes too. So I can only guess that under the "File://" CDP extension option I must have forgot to uncheck a checkbox.. I could only see the following Checkbox missed...

    So when I open Enterprise PKI I only get one error now and that's for the CDP Location #1

    So obviously that failed to download, it's offline. I tried editing the setting, restarting the CertSrv Service, republishing, adding the new Root-CA to the Sub-CA and attempting to republish it into AD simply states the Cert is already published.

    Is it this checkbox that made this error in my Enterprise PKI tests? And what is the proper method to correct this without completely rebuilding.

    Again this is my second run of this in my test environment, I'd hate to have to do a third run to get this dang setup right.

    Who woulda thought a proper PKI set is sooooo dang complicated Vs simply setting up an online Enterprise Root CA (Sooooo Easy)...

    Thursday, February 8, 2018 8:10 PM

Answers

  • Hi Zewwy,

    So you still see the file:// entry in PKIView.msc, and it gives an error, right?

    When you had the file:// CDP active, the checkbox "Include in the CDP extension of issued certificates" was checked as we can see in the screenshot. When you remove the CDP, the entry will still sit in certificates issued by the Root CA in the meantime.

    You can verify this by double-clicking the sub CA certificate in PKIView.msc, selecting the Details tab, and inspecting the CRL Distribution Point attribute. You'll find that the file:// entry is still there.

    To get rid of the entry there, you have to reissue the certificate of your issuing CA. You don't need to replace the keypair, so this is a pretty routine operation, see https://technet.microsoft.com/en-us/library/cc962077.aspx

    Kind Regards,

    Wednesday, February 14, 2018 7:46 AM

All replies

  • Hi,

    As a matter of fact, we are currently working on this issue and we’ll update you soon. Your understanding and support will be highly appreciated.

    Best regards, 
    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, February 9, 2018 9:42 AM
    Moderator
  • The CDP you marked yellow is generally used as a publishing CDP. You publish the CRL to the share where the http CDP is by checking the first and possibly the fourth checkbox (if you want a delta CRL), then on the http CDP you turn on the two marked checkboxes.

    However, since you have an offline Root CA, publishing CDPs are probably not going to work as it will have no connection to the share in question. Instead you need to place the CRL file in there manually.

    Friday, February 9, 2018 12:43 PM
  • Sorry for my ignorance J.C,

    Can you elaborate on that a bit more. Maybe with some examples, I wasn't quite able to follow along. :(

    I think I might know what you're saying. I'll try to remove the record completely from the Offline Root CA before creating and issuing the Sub CA cert and chain.

    Thanks I'll report my findings when completed. :)


    • Edited by Zewwy Friday, February 9, 2018 4:27 PM
    Friday, February 9, 2018 4:24 PM
  • The "file://" location is no longer needed nor is it supported. that line is the error you see in pkiview as shown.

    Remove it and republish the CRL and you'll be fine.

    While you're at it, place http above ldap since you want everything to search that location first. Who knows? you may have a non-windows device out there looking for the crl!

    If your PKI is set up right, you should just leave the ldap out of the CDP, but you need to think that through for your implementation.

    Complications correspond directly to how well the planning is.

    -bill

    Friday, February 9, 2018 4:34 PM
  • Thanks Bill!

    I'll test your solution this afternoon! 

    That's what I was going to do on my rebuild, but If I can do it that simply then sweet I'll mark it as the answer, please wait. Thanks again

    Maybe I missed something when it comes to re-publishing a new CRL... cause it didn't work...

    I opened up my Offline-Root-CA, opened the CA tool, right clicked my CA object -> properties -> Extentions Tab -> CDP -> removed "file://" entry.  Adjusted my offline entries to have http at top. After applying changes states needs to restart services, services restarted.

    Then expand CA node -> Right Click Revoked Certs -> Publish -> Complete new CRL.

    Copy CRL from Windows\System32\CertSrv\CertEnroll\Offline-Root-CA.crl from my offline root CA to my Sub CA. Copied to same folder path. then published the new CRL to AD.

    certutil -dspublish -f "filename.crl" Offline-Root-CA

    which succeeded fine without error and states the Base CRL added to DS store.

    I then manually ran a sync between all my DC's, and to my dismay the error and order of the CRL locations on the Root-CA object in the pkiview still reported the same error and order....

    • Edited by Zewwy Friday, February 9, 2018 9:09 PM
    Friday, February 9, 2018 6:57 PM
  • Hi,

    I am checking how the issue is going, if you still have any questions, please feel free to contact us.

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, February 12, 2018 2:11 AM
    Moderator
  • lol, you told me you were looking into this issue Wendy :P

    I haven't yet had a chance to rebuild my PKI with a Server Core Sub CA yet. Been working on a storage project.

    Tuesday, February 13, 2018 3:03 PM
  • Hi,
    Sorry for that, as others are involved in the case to offer suggestions, so we are waiting for the results if they are helpful on this case.
    If the problem still persists, we would contuinue and appreciate your understanding.
    Best regards, 
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 14, 2018 2:00 AM
    Moderator
  • Hi Zewwy,

    So you still see the file:// entry in PKIView.msc, and it gives an error, right?

    When you had the file:// CDP active, the checkbox "Include in the CDP extension of issued certificates" was checked as we can see in the screenshot. When you remove the CDP, the entry will still sit in certificates issued by the Root CA in the meantime.

    You can verify this by double-clicking the sub CA certificate in PKIView.msc, selecting the Details tab, and inspecting the CRL Distribution Point attribute. You'll find that the file:// entry is still there.

    To get rid of the entry there, you have to reissue the certificate of your issuing CA. You don't need to replace the keypair, so this is a pretty routine operation, see https://technet.microsoft.com/en-us/library/cc962077.aspx

    Kind Regards,

    Wednesday, February 14, 2018 7:46 AM
  • Thanks for the suggestion J.Couwenberg.

    I'll def take a look at what you suggested and attempt to re-issue a new Sub-CA cert.

    All great tasks to add to my documentation. This will all be great stuff to append to my blog post once it's ready too.

    Thank you all for all your input and support, you guys are amazing.

    I quickly looked were you told me and sure enough there's the info still sitting in my face. It's nice to see helpful posts that point you exactly in the right direction. I'm pretty confident a re-issue will fix this now. Once I 100% verify it I'll mark you post as the answer, as it's appears to be dead on!

    Sorry took me a lil while to report back. That was the answer, I had run across a lil hiccup trying to renew my Sub CA Cert, but I figured it out, and signing a new Sub CA cert after correcting the CDP locations on the Offline Root Ca, worked.

    • Edited by Zewwy Tuesday, February 27, 2018 4:22 AM
    Thursday, February 15, 2018 4:57 PM