Method for checking whether a self-signed CA certificate sitting in a JKS/PKCS12 keystore is still acting as the issuer for anything else in that same store — i.e. whether anything currently chains to it. Written up as a general technique; it does not describe any specific client engagement.
The basic check
A self-signed CA's own entry has identical Owner and Issuer DNs. Anything else in the store issued by that CA will show an Issuer DN matching the CA's Owner DN. List the store verbosely and pull out those fields:
keytool -list -v -keystore store.jks -storepass "$PW" | grep -E '^(Alias name|Owner|Issuer):'
For every alias other than the CA's own, if Issuer never equals the CA's Owner DN, nothing else in that store is (textually) issued by it.
Caveats — what this does and doesn't prove
- Chain entries, not just the leaf. A PrivateKeyEntry can carry a full certificate chain. -v prints an Owner/Issuer pair per certificate in the chain (look for "Certificate chain length" and Certificate[N] blocks), not just one pair per alias. Grepping only the first pair per alias can miss an intermediate further up the chain that does chain through the CA.
- Textual match, not cryptographic proof. This is a string comparison of the DN as encoded in the certificate, not signature verification. Two unrelated certificates can carry the same-looking subject DN with different keys behind them. For anything that matters, compare fingerprints/SPKI rather than trusting the printed DN string:
keytool -exportcert -alias X -keystore store.jks | openssl x509 -noout -issuer -subject -fingerprint sha256. - trustedCertEntry vs PrivateKeyEntry. What you actually care about is a PrivateKeyEntry whose issuer is your CA — that's a live identity depending on the chain. Other trustedCertEntry items are normally separate root/intermediate CAs, not leaves signed by your CA, and their presence isn't itself a dependency.
- Scope is this file only. A clean result (nothing else in this store chains to the CA) says nothing about: other keystores on other hosts holding a PrivateKeyEntry issued by this CA; a remote peer presenting a certificate signed by this CA that some client validates against a copy of the CA cert held elsewhere (the CA cert doesn't need to co-reside with anything it signed); direct pinning of the CA's alias, fingerprint, serial or public key in code/config with no chain relationship at all; or an application inheriting a default trust manager rather than naming the store explicitly.
Net effect: "grep shows nothing else in this keystore is issued by this CA" is a real, useful negative result, but it only closes off one class of dependency (this store, chain-based, textually detectable). It is not equivalent to "nothing anywhere depends on this CA" — a clean local result should not be read as proof of no external consumer.
For a reusable Perl implementation that extracts RFC-formatted certificates, verifies issuer relationships cryptographically and reports the available paths, see Perl Certificate-Path Analyser for keytool RFC Output.