denetarik

The error messages an AD CS Certification Authority displays are often not very useful. Errors, for instance, when trying to start the Certificate Services are sometimes generic and make troubleshooting difficult. One option to get additional information regarding the problem is to set the CA to debug level. This can be achieved running the following command: certutil -setreg ca\debug 0xffffffe3 When restarted, a debug log file is written to %windir%\certsrv.log , with its content being something like: ======================================================================== Opened Log: 21.11.2023 00:23 38.237s GMT + 1,00 certca.dll: 6.3:9600.17415 retail certsrv.exe: 6.3:9600.21062 retail 503.1945.0:<2023/11/21, 0:23:38>: 0x0 (WIN32: 0) 508.1341.0:<2023/11/21, 0:23:38>: 0x2 (WIN32: 2 ERROR_FILE_NOT_FOUND): DBMaxReadSessionCount 513.17174.0:<2023/11/21, 0:23:38>: 0x80070490 (WIN32: 1168 ERROR_NOT_FOUND): CAExchange 508.1734.0:<2023/11/21, 0:23:38>: 0x80070490 (W

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