From the Field: AD CS

🔎 𝗙𝗿𝗼𝗺 𝘁𝗵𝗲 𝗙𝗶𝗲𝗹𝗱 — Real-World Findings from Security Assessments

💥 In 𝟰𝟮.𝟵% of infrastructures I’ve assessed, 𝗔𝗰𝘁𝗶𝘃𝗲 𝗗𝗶𝗿𝗲𝗰𝘁𝗼𝗿𝘆 𝗖𝗲𝗿𝘁𝗶𝗳𝗶𝗰𝗮𝘁𝗲 𝗦𝗲𝗿𝘃𝗶𝗰𝗲𝘀 (𝗔𝗗 𝗖𝗦) 𝗮𝗿𝗲 𝘀𝘁𝗶𝗹𝗹 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗲𝗱 𝘂𝘀𝗶𝗻𝗴 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲-𝘁𝗶𝗲𝗿 𝗵𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆

Let me borrow a line straight from 𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 on this one:

“𝘖𝘯𝘦-𝘵𝘪𝘦𝘳 𝘩𝘪𝘦𝘳𝘢𝘳𝘤𝘩𝘺 𝘪𝘴 𝘯𝘰𝘵 𝘳𝘦𝘤𝘰𝘮𝘮𝘦𝘯𝘥𝘦𝘥 𝘧𝘰𝘳 𝘢𝘯𝘺 𝘱𝘳𝘰𝘥𝘶𝘤𝘵𝘪𝘰𝘯 𝘴𝘤𝘦𝘯𝘢𝘳𝘪𝘰. 𝘈 𝘤𝘰𝘮𝘱𝘳𝘰𝘮𝘪𝘴𝘦 𝘰𝘧 𝘵𝘩𝘪𝘴 𝘴𝘪𝘯𝘨𝘭𝘦 𝘊𝘈 𝘦𝘲𝘶𝘢𝘵𝘦𝘴 𝘵𝘰 𝘢 𝘤𝘰𝘮𝘱𝘳𝘰𝘮𝘪𝘴𝘦 𝘰𝘧 𝘵𝘩𝘦 𝘦𝘯𝘵𝘪𝘳𝘦 𝘗𝘒𝘐.”

And yet, I hear this all the time:

👉 “We only need it for one internal cert. Nothing too crazy. Let’s just keep it simple.”

Yeah, same 𝗲𝗻𝗲𝗿𝗴𝘆 𝘄𝗲 𝗵𝗮𝗱 𝗳𝗼𝗿 𝗔𝗰𝘁𝗶𝘃𝗲 𝗗𝗶𝗿𝗲𝗰𝘁𝗼𝗿𝘆 back in the day — and you’ve seen how those decisions aged.

🛠️ 𝗛𝗲𝗿𝗲’𝘀 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴:

If you’re already taking the time to implement a critical service like AD CS — just 𝗳𝗼𝗹𝗹𝗼𝘄 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 from the start. It’s rarely much harder, and it’ll save you a lot of pain later.

🔐 What to Do Instead: 𝗨𝘀𝗲 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝗧𝘄𝗼-𝗧𝗶𝗲𝗿 𝗛𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆

The two-tier design is the sweet spot for most organizations:

🔹 An offline Root CA (only used to sign subordinate CAs)

🔹 One or more online Issuing CAs that handle certificate requests

𝗪𝗵𝘆 𝗶𝘀 𝘁𝗵𝗶𝘀 𝗯𝗲𝘁𝘁𝗲𝗿?

🔹 Stronger security: Root key is offline = harder to compromise

🔹 Better scalability: Add issuing CAs for different purposes or regions

🔹 Higher flexibility: Customize certificate policies per issuing CA

🔹 Manageability improves — and the additional cost is marginal (1 VM)

If one issuing CA is compromised, your root key is still safe — and your 𝗲𝗻𝘁𝗶𝗿𝗲 𝗣𝗞𝗜 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗴𝗼 𝗱𝗼𝘄𝗻 𝗶𝗻 𝗳𝗹𝗮𝗺𝗲𝘀.

𝗬𝗼𝘂 𝗰𝗮𝗻 𝘁𝗮𝗸𝗲 𝘁𝗵𝗶𝘀 𝗳𝘂𝗿𝘁𝗵𝗲𝗿:

🔹 Apply path length constraints

🔹 Limit Extended Key Usages (EKUs) for issuing CAs

𝗗𝗼𝗻’𝘁 𝗙𝗼𝗿𝗴𝗲𝘁 𝗧𝗵𝗲𝘀𝗲 𝗔𝗗 𝗖𝗦 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀:

📃 Properly configure certificate templates

⚙️ Use Windows Server Core

🔐 Consider using a Hardware Security Module (HSM) for private keys

🧑‍💼 Delegate specific roles for AD CS

Do you run a two-tier PKI, or are you stuck on a single-tier CA?