denetarik

In order to emulate how a particular client would behave when it comes to certificate path building, sometimes it is useful to be able to modify the content of a client's trust store. This can help e.g. to understand whether an old client, without a particular root CA certificate in its trust store, will be able to build a trusted path for a given server configuration. In Windows, the attempt to delete from the certificate store certain root CAs will display a warning: Selecting "Yes" and proceeding will briefly delete those root CAs from the trusted store but they will reappear shortly after, difficulting testing. This happens regardless of an available connection to the Internet, since this phenomenon does not rely on the Automatic Root Certificates Update mechanism. In order to remove one of those root CAs and proceed with the testing, we first have to stop the Windows service that restores them, the " Cryptographic Services " service, which includes the ...

Often certificate templates in AD CS are configured to require a set of authorised signatures for issuance: This is useful e.g. when issuance approval is delegated to a component outside of AD CS roles, such as some CA management or registration authority portal software. Combined with the template security settings this can prevent requests from being raised directly from the CA without going through a custom standard request process, and depending on the level of security required, multiple signatures can be enforced and optionally also additional CA certificate manager approval. In order to produce each of this signatures an "Enrollment Agent" certificate is used, a certificate with the "Certificate Request Agent (1.3.6.1.4.1.311.20.2.1)"  Enhanced Key Usage. Sometimes it is required to raise requests directly towards the CA, e.g. using the RPC/DCOM interface from the command line, but it is not desirable and/or possible to change the template configuration, so t...