rea-reverse

Signing certificate fingerprints: SHA-1, SHA-256 and MD5

Drop a keystore (.jks, .keystore, .p12, .pfx), an APK or AAB, or a certificate file to get the SHA-1, SHA-256 and MD5 fingerprints of every certificate in it, in the forms Firebase, Google Sign-In, Google Maps API keys and Facebook Login ask for. No keytool, no JDK.

Your keystore and password never leave your browser. The file is read locally in a Web Worker that has no network access. The password is used only in that worker's memory: it is not stored, logged or sent anywhere, and private keys are never decrypted. How to verify this yourself

JKS and JCEKS show their certificates without it; with it, the integrity check is verified. Most PKCS#12 files encrypt their certificates and need it.

Drop a keystore, APK, AAB or certificate here

or

JKS, JCEKS, PKCS#12 (.p12, .pfx, and .keystore files of either type), APK, AAB, PEM, DER, CRT, CER and P7B. Keystores up to 16 MiB, APK and AAB up to 1 GiB.

What this tool does not do

  • It never reads or decrypts private keys: only certificates and their fingerprints are shown. Signing still happens in your own build.
  • Bouncy Castle BKS / UBER keystores and JCEKS secret-key entries are not supported. APK signatures are listed, not verified; use apksigner verify for that.

Firebase, Google Sign-In, the Maps SDK and Google Cloud API key restrictions all want the same thing from an Android developer: the SHA-1 (and often the SHA-256) of the certificate that signs the app. Facebook Login wants a “key hash”, which is the same SHA-1 encoded as Base64. The usual answer is keytool -list -v, which needs a JDK and a terminal, and for the Facebook value a pipe through openssl:

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64

This page gives you all of those values from the file itself, in your browser.

What you can drop here

  • Java keystores: JKS and JCEKS (.jks, .keystore). Certificates are stored in clear in these formats, so you see every alias, entry type, creation date and certificate chain without the password. If you type the password, the keystore’s integrity digest is checked as well.
  • PKCS#12: .p12, .pfx, and .keystore files that keytool wrote as PKCS#12 (its default since JDK 9). These usually encrypt their certificates, so the password is needed. Both the current algorithms (PBES2 with AES-256 and PBKDF2-HMAC-SHA256) and the legacy ones written by older JDKs and openssl pkcs12 -legacy (RC2-40 and 3DES with the PKCS#12 key derivation) are supported.
  • APK and AAB: the signer certificates of the v1 (JAR), v2, v3 and v3.1 signature schemes, read with the same code as the APK analyzer. A signer that appears in several schemes is shown once with all of them; a rotated v3 key shows up as a separate signer.
  • Certificate files: PEM (one or several), DER, .crt, .cer and .p7b bundles. For a full field and extension view of those, the X.509 certificate decoder shows more.

What you get

For each entry: the alias, PrivateKeyEntry or trustedCertEntry (keytool’s names), and each certificate of the chain with subject, issuer, validity (and whether it has expired), key algorithm and size, signature algorithm and serial number. For each certificate, the SHA-1, SHA-256 and MD5 fingerprints in three forms, each with a copy button:

Form Example use
Colon hex, 5E:8F:16:… Firebase console, Google Cloud API key restrictions, Google Sign-In OAuth client, keytool output
Hex without colons, 5e8f16… config files and APIs that want a plain hex string
Base64 of the digest Facebook Login “Key Hashes” (Base64 of the SHA-1)

The page also shows the SHA-256 pin of the public key in Base64, the value Android’s network security config takes in <pin digest="SHA-256">.

Which certificate is the right one? The one that signs what users install. With Play App Signing, Google re-signs your app, so the fingerprints Firebase and Google Sign-In need for the Play build are those of the app signing key shown on the App signing page of Play Console; your upload keystore gives the upload key. Debug builds use ~/.android/debug.keystore (alias androiddebugkey, password android), and each machine has its own.

How we checked it

We generated keystores with keytool from Temurin JDK 17.0.18 (JKS, JCEKS, PKCS#12, and PKCS#12 in the legacy format with -J-Dkeystore.pkcs12.legacy), PKCS#12 files with OpenSSL 4.0.3 (default, -legacy, -descert and an unencrypted one), RSA 2048 and EC P-256 / P-384 keys, and a root, intermediate and leaf chain. The unit tests compare every alias, entry type, fingerprint, signature algorithm, key size and serial number with keytool -list -v, and the APK signers with apksigner verify --print-certs from Android build-tools 36.1.0. One thing that tripped us while building those files: keytool -importkeystore into PKCS#12 refuses to copy a trusted certificate entry if you also pass -destkeypass (“trusted certificate entries are not password-protected”), and leaves it out of the new keystore. If an alias seems to be missing after a conversion, that is a likely cause.

How your keystore and password stay private

  • The file is read in a Web Worker on your device; nothing is uploaded.
  • The password is posted to that worker together with the file, used to check the integrity digest or MAC and to decrypt the certificate bags, and dropped when the analysis ends. It is not saved in the page, in browser storage, or in any log, and it is never part of an analytics event. Clicking Read another file clears the field.
  • Private keys are skipped, never decrypted. This page cannot export or show a private key.
  • Analytics events contain only coarse values: success or an error code, the detected format (jks, pkcs12, apk, …), whether the integrity check passed, a count bucket, a size bucket and a duration bucket. No alias, name or fingerprint. The full list is on the privacy page.
  • The tool page shows no ads.

How to verify this yourself

  1. Open your browser’s developer tools on the Network tab, then drop a keystore and type its password. The only requests are page assets and the worker script /_astro/cert-worker-*.js; none carries your file or password.
  2. Or load the page, go offline (turn off Wi-Fi, or tick Offline in the Network tab) and read a keystore. It still works.
  3. The worker runs under the Content Security Policy default-src 'none'; script-src 'self'; connect-src 'none', so the browser does not let it make any network request.
  4. Compare with your own tools: keytool -list -v -keystore my.jks prints the same SHA-1 and SHA-256, and apksigner verify --print-certs app.apk the same signer digests.

Limitations

  • BKS and UBER keystores (Bouncy Castle) are not read. Convert them with keytool -importkeystore -srcstoretype BKS -providerpath bcprov.jar … first.
  • JCEKS secret-key entries are stored as Java-serialized objects; listing stops at the first one, and the entries after it are not shown.
  • PKCS#12 in public-key integrity mode and files whose MAC uses PBMAC1 (shown as “not checked”) are not supported. BER-encoded files (indefinite lengths, segmented OCTET STRINGs) are read.
  • APK signatures are listed, not verified. Use apksigner verify or the APK analyzer to check them. Source stamps and v4 signatures (.idsig) are not shown.
  • Aliases in JKS are decoded as UTF-8; Java’s modified UTF-8 differs only for NUL and characters outside the Basic Multilingual Plane.

FAQ

Do I need the keystore password to get the SHA-1?

For JKS and JCEKS, no: the certificates are not encrypted. For most PKCS#12 files, yes, because keytool and OpenSSL encrypt the certificate bags. Without the password the page still lists the entries and their aliases and tells you the certificates are locked.

The SHA-1 here differs from the one in Firebase.

Check that you are looking at the key that signed the installed build: debug keystore for debug builds, upload key for builds you sideload, app signing key from Play Console for builds from Google Play.

Is the Facebook key hash the same thing as the SHA-1?

Yes, the same 20 bytes. Facebook asks for them in Base64 (28 characters ending in =); Firebase wants them as colon-separated hex.