denetarik

In a Microsoft AD CS based platform including an Enterprise CA, it is quite common to setup the OCSP responder to automatically enroll for and renew the required certificates. This is usually achieved creating a custom OCSP Response Signing certificate template and granting the computer(s) where the OCSP Responder runs the required enrollment rights. There are 2 interesting things to note in such a setup: 1. The OCSP Responder computer objects only require "Read" and "Enroll" rights on the template, although it feels like Windows auto-enrollment no "Auto-enroll" right is required. 2. The OCSP Response Signing certificates issued via this mechanism are stored in the service specific certificate store, and not in the Computer certificate store (as would be the case if they were generated on a different way). To view them run the mmc.msc snap-in and then go to File > Add/Remove snap-in > Certificates > Service Account > Local computer > Online

Although generally considered insecure and lacking support for modern cryptography, the Simple Certificate Enrollment Protocol (SCEP) is still a widely used and supported protocol. Microsoft's implementation of SCEP is the AD CS Network Device Enrollment Service (NDES), and one of the best deployment guides out there is Mark B. Cooper's "Securing and Hardening Network Device Enrollment Service for Microsoft Intune and System Center Configuration Manager" (from March 2015). Within the NDES configuration recommendations checklist we can find the following: " Dedicated Server Roles – The NDES service should be installed on a dedicated server. The Issuing CA should also be on its own dedicated server. " which makes a lot of sense but unfortunately is not always possible. Depending on the use case for the end entity certificates issued via SCEP, in many cases it will make sense to issue them from a standalone CA, to avoid it being trusted in Active Directory. If