Check signing certificates in a JAR file without jarsigner

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 JAR file with a file compression utility and brose to the META-INF directory we will find a .RSA file in there:


Opening it with a file editor will display the binary data, and within it we can typically find some details of the CAs involved in human readable form:


This can already provide some hints, but a much better way to identify the certificates and chains used when jarsigner is not available is to use keytool.

There are 2 useful variations of keytool commands we can use to check the certificates:

keytool -printcert -jarfile <SignedJARFile>

keytool -printcert -rfc -jarfile <SignedJARFile>

Both commands will print the certificate chains used for JAR signing, both for code signing and timestamping.First a block starting with Signature will be displayed, followed by the certificate chain used for the code signing part:


Followed by a Timestamp block including the details for the timestamping certificate chain:


The first option (with the -rfc flag) will directly display the details of each certificate:

While the second one (with the -rfc flag) will output each certificate in PEM format:

Once the certificates involved in both chains are known whether those are trusted by Java (via its own trust store) and/or the underlying OS can be validated.

Please note: The above commands, unlike jarsigner -verify, do not perform any signature validation, so they can only to be used to troubleshoot trust decisions.




Comments

Post a Comment

Popular posts from this blog

Decoding OCSP GET requests

Many clients default to OCSP requests via HTTP GET, encoding the request details as part of the URL. These kind of requests can be found in the logs: http://ocsp.ekaitza.net/ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK%2BGVqszOaLAawQUb38ZjesMwNeYLEzdGvP%2FZi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho%3D As per RFC 6960 , the request is constructed as: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} So in order to find out the details of the request we have to: 1. Remove the URL encoding This can be done with different tools, depending on the OS/platform being used.Given the input above: MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK%2BGVqszOaLAawQUb38ZjesMwNeYLEzdGvP%2FZi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho%3D the output would be: MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK+GVqszOaLAawQUb38ZjesMwNeYLEzdGvP/Zi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho= We can then create a text file with it, e.g.:  $ echo "MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK+GVqsz
Read more

Compacting an AD CS database

Given the healthy trend towards decreasing certificate validity periods, it is very likely that the size of an AD CS Certification Authority database will grow following that same trend. Despite regular maintenance activities including deletion of records such as failed, denied etc. it could be that at some point the CA database reaches a problematic size. Deleting records from an AD CS CA database will internally free up the space previously occupied by those records but will not decrease the size of the database file itself. I.e. new records will reuse the freed up space but the total space used by the database file will not decrease. This helps keeping the database size under control but does not help if the size had already increased over acceptable limits; in this case the database must be compacted. The CA is often a critical resource, so it is recommended to keep various backups of different nature, to try to make sure we can recover it in case something goes wrong. Here a
Read more

Signing a CSR with an Enrollment Agent certificate

Image
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
Read more