To check your iOS sideloading certificate, upload it here. My tool will check the OCSP status and all the details including how many days the certificate has left before it expires. I DO NOT store the certificates, they are just used in memory and deleted after the result is computed.
If you want to check an iOS Configuration Profile (mobileconfig), please use this Configuration Profile checker. Or, if you wanna check a mobileprovision file, use this Provisioning Profile checker.
What this tool does
The checker above reads an iOS signing certificate, the kind that lives inside a .p12 file, and tells you everything Apple baked into it.
You get the identity it was issued to, the team behind it, the day it was issued and the day it dies, the fingerprints, and the part most people actually came here for: a live check on whether Apple has revoked it.
Nothing you upload is kept. The file is read in memory, parsed, and gone the instant the page finishes loading. I go into exactly how that works further down, because if you are handing a signing identity to a website you deserve to know.
I built this because I was doing the same dance by hand over and over. Drop a cert into a terminal, run a few OpenSSL commands, squint at the output, then fire an OCSP request to figure out if the thing was still usable. This just does all of that in one shot and puts it in plain language.
So what is a .p12 file, really?
A .p12 (sometimes .pfx) is a PKCS#12 archive. Think of it as a locked box that holds two things: a certificate and its matching private key.
The certificate is the public half. It says who you are and carries Apple’s signature vouching for that. The private key is the secret half, and whoever holds it can sign apps as you. That is why the box is password protected, and that is why you should never hand your real .p12 to a service you do not trust.
The password you type into the checker is used once, in memory, to open the box so the certificate can be read. It is never written down, never logged, and the private key inside is never used for anything. The tool only ever looks at the public certificate.
Reading the results, one field at a time
Common Name
The human readable name Apple stamped on the certificate. It usually starts with the certificate type, like “Apple Development”, “Apple Distribution”, or “iPhone Developer” on older ones, followed by a name or a team.
Team ID
The ten character code that identifies your Apple developer team. Every account has one. It ties the certificate, your app IDs, and your provisioning profiles together.
Type
What the certificate is allowed to do. Development, distribution, enterprise in-house, Developer ID, push, and so on. This is the single most useful thing to know, because it decides how the cert can be used for signing.
Issuer
Who signed the certificate. For iOS this is almost always one of Apple’s Worldwide Developer Relations intermediate authorities (WWDR). Your certificate is trusted because it chains up to Apple’s root.
Valid from and Valid until
The window the certificate is alive. Before the first date it is not active yet. After the second it has expired on its own. The tool also tells you how many days are left, or how long ago it lapsed.
Serial number
A unique ID Apple assigns to the certificate. This is the exact value used when asking Apple whether the cert has been revoked.
SHA-1 and SHA-256 fingerprints
A cryptographic thumbprint of the whole certificate. Handy for confirming two certs are identical, or for matching a cert against a record somewhere else.
Public key
The algorithm and size of the key, for example RSA 2048 bit. Nothing secret, just the public parameters.
Private key present
Whether the archive actually contains the private key. A proper signing .p12 has it. If it says no, you have exported only the public certificate, which cannot sign anything.
The certificate types you will run into
Development
For building and running your own apps on devices you have registered. Short leash, meant for testing.
Distribution
Used to ship apps. This covers App Store submissions and Ad Hoc builds. Ad Hoc lets you install on a fixed list of registered devices, up to one hundred per device type per membership year.
Enterprise (In-House)
Issued through the Apple Developer Enterprise Program. These are meant for a company to distribute internal apps to its own staff without going through the App Store and without registering each device. This is also the type that gets abused the most, and the type Apple revokes the fastest, which I will come back to.
Developer ID
A macOS thing, not iOS. Used to sign Mac apps distributed outside the Mac App Store so Gatekeeper lets them run.
Push
For sending Apple Push Notifications, not for signing apps.
How these certificates actually power iOS sideloading
iOS will not run code that is not signed. The kernel checks every executable and refuses anything whose signature does not chain up to a certificate Apple trusts.
On top of that, for anything outside the App Store, the app also needs a provisioning profile that says this certificate is allowed to run this app, with these entitlements, on these devices. Signing certificate plus provisioning profile is the whole game.
Sideloading is just the art of getting a valid pair onto a device. There are three flavors of this in practice.
Free Apple ID
Anyone can sign apps with a free personal team. The catch is that the certificate and profile only last about seven days, and you can only keep a handful of apps installed at once.
Tools like AltStore, SideStore and Sideloadly automate the seven day re-signing so your apps do not die on you. It works, but it is a treadmill.
Paid developer account
A regular paid membership gives you a certificate that lasts a year and Ad Hoc distribution to registered devices. Longer lived, but you are pinned to the devices whose UDIDs you registered.
Not to mention Apple has become quite twitchy about the UDIDs and how many you register lately…
Enterprise certificates
This is where the sideloading scene has historically leaned hard. An enterprise in-house certificate can install apps on any device with no per device registration, which is exactly what a public sideloading service wants.
Whole ecosystems of “app stores” have run on enterprise certs bought, borrowed, or shared. And this is precisely why revocation matters so much to that world.
For completeness, the picture shifted in the EU in 2024, when iOS 17.4 opened the door to alternative app marketplaces and notarized distribution under the Digital Markets Act. That is a separate thing with its own rules.
The certificate mechanics above still describe how classic sideloading works everywhere else, and how most of the tools people use day to day still operate.
Expired versus revoked, and why your apps suddenly stop opening on iOS
These two get mixed up constantly, so let me split them cleanly.
Expired means the certificate reached its “valid until” date and aged out naturally. It is predictable. You can see it coming, because the date is right there on the certificate.
Revoked means Apple actively killed the certificate before its expiry date. This is sudden and it is not something you can read off the certificate itself, because the kill switch lives on Apple’s servers, not in the file. When Apple revokes an enterprise or distribution certificate, every app ever signed with it stops launching, often all at once. If you have ever watched a sideloaded app store go dark overnight and everyone’s apps refuse to open, that was a revocation.
Both outcomes look similar from the couch, your app will not open, but the reason and the fix are different. Expiry you re-sign on schedule. Revocation means the identity is dead and you need a new one.
How the revocation check works
To answer “is this revoked right now”, the tool speaks OCSP, the Online Certificate Status Protocol. In plain terms, it asks Apple’s certificate authority directly about this one specific certificate and gets back one of three answers: good, revoked, or unknown. If the answer is revoked, Apple also returns the date it happened and a reason code, and the tool shows both.
Worth knowing what actually leaves your browser for this. An OCSP request does not contain your private key, and it does not contain the whole certificate. It carries a hash of the issuer’s name, a hash of the issuer’s key, and the certificate’s serial number. That is enough for Apple to look it up and nothing more. Your secret key never goes anywhere near the network.
One nuance on reason codes. If you see “certificate hold” rather than something like “key compromise”, that specific reason is technically reversible in the standard. In Apple’s real world practice a held certificate is dead for signing all the same, so treat any revoked result as a dead identity.
What happens to your file
Since the whole point is to inspect a signing identity, trust is the entire ballgame, so here is the honest accounting.
Your .p12 is received, held in memory only, read, and discarded when the request ends. It is not written to disk. It is not saved in any database. The password is used once to unlock the archive in memory and is never stored or logged.
The private key inside the archive is never used and never transmitted. The only outbound network call is the OCSP lookup described above, and that request cannot expose your key.
If you would still rather never upload a signing identity to any website, that instinct is correct in general, and it is a good habit to keep.
Frequently asked questions
Is my certificate revoked if it shows as expired?
No. Expired and revoked are different states. Expired means it aged out on its own. Revoked means Apple killed it early. The tool shows both separately.
Why does the tool say it cannot check revocation?
Usually because the certificate does not list an OCSP responder, or the issuing intermediate could not be reached to build the request. Most Apple leaf certificates include everything needed, so this is uncommon.
Can this tool sign apps or renew my certificate?
No. It only reads and reports. It never uses the private key for anything.
Do you store the certificates people upload?
No. Files are parsed in memory and discarded. Nothing is written to disk or a database.
My sideloaded apps stopped opening. Was my cert revoked?
Very possibly, especially if they were signed with an enterprise certificate. Upload the .p12 and the revocation line will tell you. If it says revoked, that identity is finished and the apps need re-signing with a fresh one.
What is the difference between a .p12 and a provisioning profile?
The .p12 is your signing identity, the certificate and private key. The provisioning profile is a separate file that authorizes that identity to run specific apps on specific devices. You need both to sideload.
Who made this
I am GeoSn0w, and I run iDevice Central. I spend my time on iOS security research, reverse engineering, and responsible disclosure, and I have handled more signing certificates and dead enterprise certs than I care to count.
I wrote this tool and this guide because the questions around it come up constantly and the answers are usually buried in terminal OPENSSL commands.
If you spot something inaccurate, tell me, I would rather fix it than leave it wrong.
