denetarik

Java includes its own Root CA trusted certificate store, regularly updated via its  Root Certificate Program  and implemented via its cacerts certificates file (by default under  $JAVA_HOME\lib\security ). In addition to its own trusted certificate store, it is also possible to configure clients to make Java trust the certificates present in a browser's certificate store (limited to Internet Explorer and Mozilla Firefox). This can be achieved via a setting within Control Panel > Java > Advanced > Advanced Security Settings called " Use certificates and keys in browser keystore ": The setting is enabled by default, and it is documented  here . According to its description, in particular on Windows platforms " On Windows, browser keystore is supported through Internet Explorer. Certificates and keys in Internet Explorer are automatically recognized by Java Plug-in and Java Web Start when Java and JavaFX applications are deployed on Windows ". Microsoft W

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