none
What is the Best Practice for publishing Offline Root CA Cert and CRL to Active Directory?

    Question

  • Hi,

    I've read and seen in a few labs different approaches to what is published in Active Directory for a Offline Root CA.  I've seen just the Root Cert published to AD as well as the Root Cert and the Root CRL published to AD. 

    I can understand why the Root Cert is published to AD, but why would the Root CRL need to be published to AD, especially if my Offline Root CA just issues the Cert for my Subordinate Issuing CA?  So looking for Best Practices here.


    Thanks for your help! SdeDot

    Sunday, February 22, 2015 6:29 PM

Answers

  • So in what other way you would like to confirm that Sub CA has not been revoked? You may have several Issuing CAs and some of them may have been revoked over the time, right?

    Best practice is to publish CRL to 2 alternative paths - LDAP for your internal users to access them on the first place and HTTP as an alternative option to LDAP and as the only option for your external users.


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    • Marked as answer by SdeDot Sunday, February 22, 2015 10:07 PM
    Sunday, February 22, 2015 6:44 PM
  • On Sun, 22 Feb 2015 18:44:25 +0000, Andrzej Kazmierczak wrote:

    Best practice is to publish CRL to 2 alternative paths - LDAP for your internal users to access them on the first place and HTTP as an alternative option to LDAP and as the only option for your external users.

    No, the current recommended best practice is to publish to a highly
    available HTTP location first (and possibly the only CDP) that is available
    both internally and externally. This covers Windows and non-Windows
    devices, domain joined and non-domain joined devices and internal and
    external devices as well as multi-forest scenarios with no trust between
    forests.


    Paul Adare - FIM CM MVP

    • Marked as answer by SdeDot Sunday, February 22, 2015 10:07 PM
    Sunday, February 22, 2015 8:42 PM
  • Many reasons:

    - Only usable by domain-joined Windows systems (not accessible by non-domain joined windows, unix, network appliances, MAC, IOS, MDMs, sometimes not accessible by other forests - depending on trusts)

    - Cannot be access publicly

    - Replication latency issues

    Brian

    • Proposed as answer by Brian Komar [MVP] Monday, February 23, 2015 1:06 PM
    • Marked as answer by SdeDot Tuesday, February 24, 2015 2:11 AM
    Monday, February 23, 2015 1:06 PM

All replies

  • So in what other way you would like to confirm that Sub CA has not been revoked? You may have several Issuing CAs and some of them may have been revoked over the time, right?

    Best practice is to publish CRL to 2 alternative paths - LDAP for your internal users to access them on the first place and HTTP as an alternative option to LDAP and as the only option for your external users.


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    • Marked as answer by SdeDot Sunday, February 22, 2015 10:07 PM
    Sunday, February 22, 2015 6:44 PM
  • On Sun, 22 Feb 2015 18:44:25 +0000, Andrzej Kazmierczak wrote:

    Best practice is to publish CRL to 2 alternative paths - LDAP for your internal users to access them on the first place and HTTP as an alternative option to LDAP and as the only option for your external users.

    No, the current recommended best practice is to publish to a highly
    available HTTP location first (and possibly the only CDP) that is available
    both internally and externally. This covers Windows and non-Windows
    devices, domain joined and non-domain joined devices and internal and
    external devices as well as multi-forest scenarios with no trust between
    forests.


    Paul Adare - FIM CM MVP

    • Marked as answer by SdeDot Sunday, February 22, 2015 10:07 PM
    Sunday, February 22, 2015 8:42 PM
  • Yes Paul, you are right - HTTP this is best practice.

    However, putting LDAP in CDP/AIA will not uncover a lot of usefull information for bad gus nor increase time for checing by external users. What's important is to put HTTP on the first place and make it highly availble.


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    Sunday, February 22, 2015 9:01 PM
  • Thanks Andrzej and Paul.

    Our PKI is strickly internal for Domain-joined devices, so Im not sure how HTTP would help if published to AD.


    Thanks for your help! SdeDot

    Sunday, February 22, 2015 10:09 PM
  • On Sun, 22 Feb 2015 22:09:47 +0000, SdeDot wrote:

    Our PKI is strickly internal for Domain-joined devices, so Im not sure how HTTP would help if published to AD.

    Flexibility for possible future changes.


    Paul Adare - FIM CM MVP
    "I can't see any data coming out of this Tolkien Ring card."
    "Well of course not, it confers invisibility." -- Anthony de Boer

    Sunday, February 22, 2015 11:21 PM
  • Makes sense....and been there before!

    Thanks for your help! SdeDot

    Monday, February 23, 2015 1:15 AM
  • Andrezj,

    As co-author of the whitepaper on revocation checking, I need to tell you that you are incorrect. As Paul correctly stated, only use HTTP on a highly available Web cluster that is both internally and externally accessible using the same DNS name.

    NEVER USE LDAP. This has been the best practice since Windows 2008/Windows Vista time frame.

    Hope this is clear.

    Brian

    Monday, February 23, 2015 1:15 AM
  • Hi Brian,

    Thanks for your comment.

    So I want to make sure I understand your point.

    When you say 'Never Use Ldap', I interpret that to mean AD.  Are you then stating not to publish CRLs to AD?

    I did finally round up a copy of your Windows Server 2008 PKI and Cert Security book and in Chap 6 you talk about Cert and CRL publishing to AD.


    Thanks for your help! SdeDot

    Monday, February 23, 2015 2:43 AM
  • Brian,

    Thanks for clarification.

    Can you please make a small comment what are the main reasons LDAP had stopped being used as CDP/AIA paths?


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    Monday, February 23, 2015 10:03 AM
  • Many reasons:

    - Only usable by domain-joined Windows systems (not accessible by non-domain joined windows, unix, network appliances, MAC, IOS, MDMs, sometimes not accessible by other forests - depending on trusts)

    - Cannot be access publicly

    - Replication latency issues

    Brian

    • Proposed as answer by Brian Komar [MVP] Monday, February 23, 2015 1:06 PM
    • Marked as answer by SdeDot Tuesday, February 24, 2015 2:11 AM
    Monday, February 23, 2015 1:06 PM
  • What would be the rationale for not having HTTP on the first place and LDAP as an backup?


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    Monday, February 23, 2015 1:35 PM
  • Andrzekj,

    It only leads to longer time outs in the event of failure.

    You can argue it anyway that you want, but LDAP is out!

    Do not use LDAP in AIA and CDP if you want to validate certificates in a heterogenous network (ie the real world)

    Brian


    Monday, February 23, 2015 8:36 PM
  • Brian, 

    You propably have done more PKI deployments than you have TechNet points and you know it inside-out, that's for sure! I wouldn't dare to argue with such experience :) Just wanted to learn not only that LDAP is out, period, but also what was the reason for that. Again - thanks for sharing your time and clarification on this topic.


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    Monday, February 23, 2015 9:45 PM
  • Microsoft certificate authority was originally focused on internal use only for domain joined computers. Now there are many devices available and they connect from almost anywhere in the world. I think OWA started the biggest part of this change to http
    Friday, July 13, 2018 9:02 PM