denetarik

When troubleshooting Java code signing issues, we need to understand which certificates are involved, since one common root cause is some of them not being trusted on the system. Code signing involves typically 2 distinct end entity certificates and their corresponding chains, one for the code signature itself and another one for timestamping. The CA chain in either of those not being trusted is a common source of problems. When signed JAR files are involved, e.g. Java applications or the Deployment Rule Set itself, it is often the case that troubleshooting takes place on a system that only has the JRE installed, and not the full JDK. The standard approach to validate the signature of a JAR file is to use jarsigner -verify , but on systems that only have the JRE installed jarsigner is not available. If all we are after is to understand which code signing and timestamping certificates and chains are at play, one option is to inspect the files included in the JAR file. If we open the JA...

The following is one of the most common error messages nowadays when trying to install roles and/or features via Server Manager: When attempting installation via Server Manager the following error message is displayed: " The WS-Management service cannot process the request. The service is configured to not accept any remote shell requests " When trying via PowerShell a similar error message is displayed. There are a number of guides out there resolving it via Local Group Policy Editor, changing netsh settings etc., but in my experience, in locked down environments where policies are set via GPO etc. some of those don't work and often it is also the case that policy changes are not properly persisted even if GUIs or PowerShell commands tell otherwise. The most reliable way of temporarily (until policies are re-applied) working around it, is as follows: If you are using Server Manager close it Open the registry editor ( regedit.exe ) and look for the following entry:      ...

Sometimes we have AD CS based standalone CAs within our environment, and those not being Active Directory integrated introduces a number of constraints. We might want, for example, to run CA database queries from a different server in the environment, for certificate tracking and reporting purposes. Since the CA is standalone and does not have any Enrollment Services object within Active Directory (even if it is created as part of the role configuration process it is probably a good idea to remove it afterwards), it is often not clear whether remote queries are possible, since running standard certutil -dump on an AD member server does not provide information about the particular CA Assuming the standalone CA runs on an AD member server and is therefore able to authenticate remote RPC/DCOM requests, it does work as long as you have the required connectivity and access rights. In order to query the CA database remotely: On the standalone CA server itself run certutil -dump , this wil...

Often it is difficult to understand which flags are available on the AD CS CA, e.g. when it comes to CA\CRLFlags In order to see all available flags including which ones are configured, run: certutil -v –getreg CA\CRLFlags That will display all flags. those that are displayed in brackets are not active (in the example above only CRLF_DELETE_EXPIRED_CRLS is enabled). As usual, CRL Flags can be enabled or disabled using certutil , with a + sign to enable and a - sign to disable, followed by the name of the flag. To enable a flag: certutil -setreg CA\CRLFlags + CRLF_PUBLISH_EXPIRED_CERTS To disable it: certutil -setreg CA\CRLFlags - CRLF_PUBLISH_EXPIRED_CERTS The same applies to other available settings for the CA, the parameter -v (for verbose) added to certutil displays all available options; try simply running certutil -v -getreg ca

Certification Authorities provide validation services (CRL/OCSP) via plain HTTP, which often raises security concerns and the "why not HTTPS?" question. The information being transferred is not sensitive (although OCSP has privacy implications), and the fact that those interfaces are exposed via HTTP instead of HTTPS is precisely due to Security concerns. This setup is coming from the Security considerations in RFC 5280 ​​​​​​​: " When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies. CAs SHOULD NOT include URIs that specify https, ldaps...

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...