Apple certificate viewer
Drop a .cer from the Apple Developer website, a .pem or .crt, or a .p12 with its password to see which kind of certificate it is (Apple Development, Apple Distribution, Developer ID, Push and older types), its Team ID, the Apple intermediate that issued it, the serial number, the dates and days left, the key type and size, and the SHA-1 and SHA-256 fingerprints. For a .p12 it also says whether the private key inside matches the certificate, without showing the key. Everything happens in your browser.
Nothing is uploaded. The file and the password stay in this page, in your browser. The private key in a .p12 is never shown or kept: it is only compared with the certificate, then wiped from memory.
Drop a .cer, .pem, .crt or .p12 file
Read in your browser only, never uploaded.
How it works
- •A .cer from Apple is a DER-encoded X.509 certificate; a .pem or .crt is the same in Base64 text. The page reads the subject, issuer, serial number, validity dates, public key and extensions with its own DER reader.
- •The certificate type comes from the start of the common name ("Apple Development:", "Developer ID Application:" and so on) and from Apple's own extension fields: for example an Apple Development certificate carries 1.2.840.113635.100.6.1.2 and 1.2.840.113635.100.6.1.12. When the two disagree, the page says so.
- •A .p12 is decrypted in your browser. PBES2 (PBKDF2 with AES-CBC, what OpenSSL 3 writes by default) goes through Web Crypto. The older PKCS #12 encryption written by macOS `security export`, the openssl built into macOS and `openssl pkcs12 -legacy` (RC2-40 or RC2-128 for certificates, 3-key or 2-key 3DES for keys, keys derived with SHA-1 as RFC 7292 describes) is decrypted by the page's own RC2 and 3DES code, because Web Crypto has neither cipher. The password never leaves the page.
- •Before decrypting, the page checks the file's integrity code: an HMAC (SHA-1, SHA-256, SHA-384 or SHA-512) keyed from your password. A wrong password is reported as wrong instead of producing garbage.
- •If the .p12 holds a private key, its public half is compared with the public key of each certificate. The decrypted key bytes are overwritten straight after that comparison and are never shown.
- •Fingerprints are SHA-1 and SHA-256 hashes of the certificate, computed by Web Crypto. Days left are counted from your device's clock.
What it does not do
- •It does not check the signature chain up to Apple's root or whether the certificate was revoked, so a self-made certificate with an Apple-like name shows the same fields. Keychain Access and codesign do those checks.
- •It does not decrypt .p12 files that use RC4 or single DES (the PKCS #5 v1 schemes). Current macOS and OpenSSL do not write those by default. The page recognizes them and gives you an openssl command to run instead.
- •It does not verify the newer PBMAC1 integrity code (RFC 9579). Such a file still opens, and a wrong password is caught when decryption fails.
- •It never shows, exports or converts the private key, and it does not read .p7b bundles.
Questions
- How do I see what is inside a .cer file?
- Drop it on this page. On a Mac you can also run `openssl x509 -inform DER -in file.cer -noout -subject -issuer -dates -serial`, or double-click it to add it to Keychain Access and open it there. A .cer from the Apple Developer website is binary (DER); a file that starts with -----BEGIN CERTIFICATE----- is PEM, so drop -inform DER for that one.
- Which Apple WWDR intermediate certificate do I need?
- The one named in your certificate's issuer line. Apple has issued several generations of the Worldwide Developer Relations intermediate, told apart by the OU field (G3, G4, G5, G6). If Keychain Access says your certificate is "not trusted" or has an invalid issuer, install the matching intermediate from Apple's certificate authority page at apple.com/certificateauthority.
- Can this page open a .p12 exported from the macOS keychain?
- Yes, it opens in this page. In our test on macOS 27, the security export command wrote the certificates with RC2-40 and the private key with 3-key 3DES, with a SHA-1 integrity code. Browsers' Web Crypto supports neither cipher, so the page decrypts them with its own code; we compared the certificates it reads with what openssl pkcs12 prints. Only .p12 files with RC4 or single DES still need the openssl command the page shows.
- Why does Keychain refuse a .p12 made with OpenSSL 3?
- OpenSSL 3 writes AES encryption and a SHA-256 integrity code by default. In our test, macOS `security import` rejected such a file with "MAC verification failed", while the same certificate exported with `openssl pkcs12 -export -legacy` imported fine. Add -legacy when the .p12 is meant for a Mac keychain.
- What does "the private key matches" tell me?
- A certificate on its own cannot sign anything; Xcode also needs the private key that was made with the certificate request. If the key matches, this .p12 is enough to sign on another Mac. If there is no key, or it does not match, Xcode will report the certificate as missing its private key.
- What happens when a signing certificate expires?
- You cannot sign new builds with it, and provisioning profiles that include it stop working, so development and ad hoc builds stop launching. Apps already on the App Store are not affected. Mac apps signed with Developer ID and a secure timestamp keep opening after the certificate expires. An expired push certificate stops push notifications until you replace it.