Ctrlk
Website
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Verify Downloaded Installers

Verify a downloaded We360.ai MyZen installer before deploying it - check the publisher signature on Windows and macOS, and match the file against the published version and MD5 checksum.

Before you push an installer to a fleet, confirm two things about the file on disk:

  1. It came from us - the file carries a valid publisher signature.

  2. It arrived intact - its checksum matches the checksum we published for that build.

Both checks take under a minute and are worth running on every fresh download, especially for mass deployment where one bad file reaches every endpoint.

Always download from https://portal.we360.ai (or the portal URL issued for your deployment) over HTTPS. An installer obtained from a file-share, a chat attachment or a colleague's USB drive is exactly the case these checks exist for.

Step 1 - Check the published version and checksum

Every installer on the download server has a companion metadata file at the same URL with .version appended. It is public, small, and lists the build version and the MD5 checksum of the installer:

Invoke-RestMethod "https://portal.we360.ai/static/installers/MyZenV2.msi.version"
curl -s https://portal.we360.ai/static/installers/MyZenV2-arm64.pkg.version

The response looks like this (extra build metadata fields may also be present):

{
  "file": "MyZenV2-arm64.pkg",
  "version": "4.26.0-26222",
  "os": "macos",
  "arch": "arm64",
  "md5": "45c36169af2e0824bd5c2d3befd686c2"
}

Now compute the checksum of the file you downloaded and compare it to the md5 value:

Get-FileHash .\MyZenV2.msi -Algorithm MD5 | Select-Object -ExpandProperty Hash
md5 -q MyZenV2-arm64.pkg
md5sum zs-amd64.sh

The values must match, ignoring case. A mismatch usually means a truncated or interrupted download - delete the file and download it again. If it still does not match, do not install it; contact support.

The version field also tells you which build you are about to deploy, which is the quickest way to confirm a download is current before a fleet-wide rollout.

Step 2 - Check the publisher signature

Windows (EXE and MSI)

The Windows installers are Authenticode-signed and timestamped, as are the executables they carry. Check the installer from PowerShell:

Expected result:

Field
Expected value

Status

Valid

SignatureType

Authenticode

Certificate subject

CN=Zenstack Private Limited, O=Zenstack Private Limited, S=Madhya Pradesh, C=IN

Certificate issuer

CN=Sectigo Public Code Signing CA E36, O=Sectigo Limited, C=GB

Status values other than Valid mean stop. HashMismatch means the file was modified after signing, NotSigned means it is not one of our published installers, and UnknownError on a machine with no internet access is usually a revocation-check failure - re-run the check from a machine that can reach the CA.

Checking the signature in the GUI (no PowerShell)

If you prefer to check by hand, or you are walking a colleague through it on a machine where scripts are restricted:

  1. Right-click the downloaded .exe or .msi and choose Properties.

  2. Open the Digital Signatures tab. If this tab is missing, the file is not signed - stop and re-download.

  3. Under Embedded Signatures, confirm there is a row naming Zenstack Private Limited, with a sha256 digest and a date in the Timestamp column.

Windows file Properties dialog on the Digital Signatures tab, showing one embedded signature from Zenstack Private Limited with a sha256 digest and a timestamp

  1. Select that row and click Details. The dialog must read "This digital signature is OK.", with Name showing Zenstack Private Limited and a Countersignatures entry from DigiCert - that countersignature is the trusted timestamp.

Digital Signature Details dialog reading "This digital signature is OK" with signer Zenstack Private Limited, a signing time, and a DigiCert countersignature

  1. Click View Certificate. On the General tab, Issued to must read Zenstack Private Limited and Issued by a Sectigo public code-signing CA. The Certification Path tab shows the full chain and should report "This certificate is OK".

Certificate dialog General tab showing the certificate issued to Zenstack Private Limited by Sectigo Public Code Signing CA E36, with its validity dates

An .msi shows the same information under Embedded Signatures; the empty Catalog Signatures list below it is normal and is not a problem. The certificate's validity dates are the dates the certificate is usable for signing - an installer signed while the certificate was valid keeps verifying after it expires, because of the timestamp.

Because the signature is timestamped, it stays valid after the signing certificate expires. A build signed today verifies years from now.

macOS (PKG and DMG)

macOS installers are signed with an Apple-issued Developer ID certificate and notarized by Apple, with the notarization ticket stapled to the file so the check works offline.

Expected output:

The team identifier in brackets - 5KPT5U8WVR - is the value to match. For a .dmg or an extracted .app, use codesign --verify --deep --strict --verbose=2 <path> instead of pkgutil, and expect the same Developer ID identity.

Checking the signature in the GUI (Suspicious Package)

Suspicious Package is a free macOS app that opens a .pkg without installing it. It is the usual choice for reviewing a package before deployment, because it shows the signature and the notarization status alongside everything the package would install.

  1. Install Suspicious Package, then double-click the downloaded .pkg - it opens in Suspicious Package instead of the macOS Installer.

  2. On the Package Info tab, check the signature summary: it must report the package as signed with a Developer ID certificate issued to Zenstack Private Limited (5KPT5U8WVR), and as notarized by Apple.

  3. Click through the signature entry to see the full certificate chain - Developer ID Installer -> Developer ID Certification Authority -> Apple Root CA - and the signing timestamp.

  4. Anything else - unsigned, signed by an unexpected name, or not notarized - means the file is not one of our published installers. Delete it and download again.

The All Files and All Scripts tabs in the same window let a security reviewer see exactly what the package installs and which install scripts it runs, which is often what an internal review board asks for before a rollout.

Without any extra software, double-clicking a signed .pkg opens the macOS Installer with a small lock icon in the title bar; clicking it shows the signing certificate. Suspicious Package is preferred because it never risks starting the installation.

spctl reporting rejected or source=no usable signature, or stapler reporting that the validate action failed, means the file is not a trusted copy of our installer. Delete it and download again from the portal.

Linux

The Linux stealth installer is a shell script and is not code-signed. Verify it with the MD5 check in step 1, and download it only over HTTPS from the portal.

Verifying stealth installers

Stealth installers are renamed to <stealth_license_key>.<extension> before use - see Download Links & Utilities. Renaming does not affect any of these checks: the signature, the notarization ticket and the checksum all travel with the file contents, not the filename. You can verify before or after renaming, and both give the same result.

Two filename rules still matter, for reasons unrelated to signing:

  • The name must be exactly the license key plus the extension. A duplicate-download suffix such as zs-setup (1).exe breaks the license the installer reads from its own filename.

  • Verify the file you are about to distribute, not a re-saved copy. Re-zipping or re-exporting a PKG through an unpacking tool can drop the stapled notarization ticket.

Where to go next

PreviousDownload Links & Utilities
NextInstallation & Update Architecture

Last updated

Was this helpful?