macOS installers are code-signed, and those certificates expire. When the Mac's clock is wrong — which is routine on old machines with a dead PRAM battery, or in Recovery with no network — the signature check fails and macOS reports the installer as damaged.
Set the date correctly and the same installer works immediately. In Terminal: date to check, and date MMDDHHMMYY to set it.
Why the clock breaks the installer
Apple signs installers with a certificate valid for a fixed window. macOS verifies that the signature is valid as of the current date. Two situations trip it constantly on the sort of Mac people patch:
- A dead PRAM battery. These Macs are ten to fifteen years old. When the internal battery dies, the clock resets on every power loss — often to 2001 or 1970. A certificate issued in 2024 is not yet valid in 2001, so verification fails.
- Recovery with no network. No network means no time sync, so the environment keeps whatever nonsense the clock held.
An installer that's genuinely too old to be signed by any currently valid certificate produces the same message, which is why redownloading sometimes does fix it — but only after you've ruled out the clock.
Fixing it
Open Terminal where you are.
In the installer or Recovery, it's under Utilities → Terminal in the menu bar. On a booted macOS, open Terminal normally.
Check what the Mac thinks the date is.
Type date and press Return. If it reports something absurd, that's your problem confirmed.
Set it manually.
The format is date MMDDHHMMYY — month, day, hour (24-hour), minute, two-digit year, no punctuation. For 17 August 2026 at 15:00, that's date 0817150026. You may need sudo in front of it.
Retry the installer.
No redownload, no USB rebuild. The exact same installer that was “damaged” a minute ago will proceed.
If your Mac keeps forgetting the date between restarts, the internal PRAM/CMOS battery is flat. It's a common part costing very little, and replacing it ends a long list of odd symptoms beyond this one — including certificate errors on ordinary websites.
The other “damaged” message: the OCLP app itself
Different message, different cause. If macOS says “OpenCore-Patcher is damaged and can't be opened”, that's Gatekeeper quarantine, not a clock issue.
Use the signed PKG installer from the download page rather than a zipped app bundle — the PKG is signed and notarised and doesn't hit this. Also verify the SHA-256 hash listed there; a mismatch means a genuinely corrupt or tampered download, which is the one case where the warning is telling the truth.
When the clock isn't the answer
- Redownload the installer. Use OCLP's own Create macOS Installer, which fetches a current copy from a known-good source rather than whatever old copy is sitting in your Applications folder.
- Check available space. A download truncated by a full disk produces an installer that looks complete and isn't.
- Rebuild the USB. If it was written from a partial download, start over — see USB installer problems.
Common questions
Is my download actually corrupted?
Usually not. Check the clock first — it costs thirty seconds and resolves the large majority of these. Only redownload once you've confirmed the date is right.
Why does the wrong date come back after every shutdown?
The internal battery that maintains the clock while the Mac is unplugged has died. Common on machines this age and inexpensive to replace.
Can I just disable the signature check?
No, and you wouldn't want to — the check is what stops you installing a tampered system. Correcting the date lets the legitimate check pass, which is the right outcome rather than a workaround.