DayZ bikey files and signature checks: fixing mod kicks

A DayZ player kicked at the loading screen with a signature error almost always means one thing: a mod they loaded is signed with a key the server does not have in its keys folder. The fix is to copy the .bikey file from that mod's own keys folder into the server's keys folder and restart, and to do it again every time the mod updates. Everything else in this guide explains why that works, how to tell which mod is missing its key, why server-only mods do not need one, and how to keep keys from going stale so the problem stops coming back after every Workshop update.

This post covers only keys and signatures. For installing the server, ports and the loot economy, start with the full DayZ server guide; for every line of the config file, see serverDZ.cfg explained.

What signature verification actually checks#

DayZ content ships as .pbo files - packed archives of models, textures, configs and scripts - inside a mod's addons folder. Next to each .pbo sits a .bisign file: a signature made by the mod author with a private key that never leaves the author's machine. The matching public key is the .bikey, which the author ships in the mod's keys folder so that servers can check the signatures.

When a player connects to a server with verifySignatures = 2, the engine asks the client to prove that every .pbo it has loaded carries a valid signature from a key the server trusts. "Trusts" means one thing only: a .bikey with that name and content is sitting in the server's keys folder. If any loaded .pbo has no signature, a broken signature, or a signature from a key the server does not hold, the player is kicked.

Three files, three jobs:

A signature file is named after both the .pbo and the key that signed it, so a mod author whose key is called MyMod produces pairs like these:

@MyMod/    addons/        mymod_core.pbo        mymod_core.pbo.MyMod.bisign        mymod_items.pbo        mymod_items.pbo.MyMod.bisign    keys/        MyMod.bikey    meta.cpp    mod.cpp

The important consequence is that the server does not compare files byte for byte against its own copy. It checks that the client's files were signed by someone the server trusts. That is why the system catches a player who edited a .pbo to make walls transparent - the edited file no longer matches its signature - but also why trusting a key is a decision with weight: anything signed with that key will be accepted.

It is also worth being clear about who does the kicking. Signature verification is part of the game engine, configured in serverDZ.cfg, and it works whether or not BattlEye is running. BattlEye is a separate anti-cheat layer that watches running processes and memory. Players and many guides blame BattlEye for signature kicks because the two happen at the same moment of the connection, but no BattlEye setting will fix a missing key. BattlEye and Easy Anti-Cheat on servers draws that line across games.

verifySignatures and the settings around it#

The setting is a single line in serverDZ.cfg:

verifySignatures = 2;allowFilePatching = 0;forceSameBuild = 1;

Bohemia's own documentation for DayZ describes 2 as the only supported value. Older Arma games had a weaker mode 1 that DayZ does not use, and 0 switches checking off. Running with 0 is occasionally suggested on forums as a quick fix for key errors. It does stop the kicks, in the same way that removing a lock stops you losing the key: every client can now load any modified file it likes, and your server will happily accept a player whose local copy of a mod has been altered to show loot through walls. Leave it at 2 and fix the key.

The two settings beside it are part of the same picture:

• allowFilePatching = 0 refuses clients started with the -filePatching parameter, which lets the game load loose unpacked files from disk instead of signed .pbo files. Loose files have no signatures, so file patching is a hole straight through signature checking. Only a mod developer testing locally has a reason to turn it on.
• forceSameBuild = 1 rejects clients on a different game build. That is a version check, not a signature check, but it produces kicks at the same moment, and after a game patch it is often the real cause of what players describe as "the signature thing again".

A key detail that saves time: the check is about what the client loads, not what the server runs. The server reads its own mods without checking signatures against its keys folder. The keys folder is purely the list of public keys a client's files are allowed to be signed with.

The keys folder#

The server's keys folder sits in the server root, beside DayZServer_x64.exe on Windows or DayZServer on Linux, and next to the @Mod folders. A fresh install already contains one file:

keys/    dayz.bikey

dayz.bikey is Bohemia's own key, which signs the base game's .pbo files. Never delete it. Without it every client fails verification on the vanilla data, and the server becomes impossible to join even with no mods at all.

Every client-loaded mod adds at least one key. A modded server's folder ends up looking like this:

keys/    dayz.bikey    CF.bikey    Dabs.bikey    Expansion.bikey    VPPAdminTools.bikey    BuilderItems.bikey

Names are whatever the author chose, so they do not always match the mod's folder name. A mod named @SomeWeaponsPack can ship SWP_v3.bikey. One author with several mods often signs them all with one key, and a large mod split into several Workshop items, such as DayZ Expansion, can ship the same key in each part. Copying a key that is already there is harmless - it overwrites an identical file.

Some mods ship their key in a folder called Keys or key instead of keys. On Windows that makes no difference. On a Linux server, paths are case-sensitive, so a script that only looks in keys/ misses them. Search for the file extension rather than trusting a folder name.

Installing a mod's key, step by step#

For one new client-side or client-and-server mod, the order is:

1. Stop the server. Keys and the mod list are read at start-up.
2. Download the mod. With SteamCMD that is the client app id, 221100, not the server's 223350. The files land in steamapps/workshop/content/221100/<workshop id>/.
3. Copy or link that folder into the server root under a readable name such as @SomeMod. Workshop folders are named by number, and a launch line full of numbers is unmaintainable.
4. Copy every .bikey from inside the mod into the server's keys folder.
5. Add the mod to -mod= in dependency order, frameworks first.
6. Start the server, then join it yourself through the DayZ Launcher before telling anyone it is live.

$ steamcmd +force_install_dir /home/dayz/server +login <steam_account> \    +workshop_download_item 221100 1559212036 +quit$ cd /home/dayz/server$ cp -r steamapps/workshop/content/221100/1559212036 @CF$ find @CF -iname '*.bikey' -exec cp -v {} keys/ \;

On a server with many mods, copy every key in one pass rather than mod by mod. From the server root on Linux:

$ find . -maxdepth 3 -path './@*' -iname '*.bikey' -exec cp -v {} keys/ \;

On Windows, from the server folder in PowerShell:

Get-ChildItem -Path .\@* -Recurse -Filter *.bikey | Copy-Item -Destination .\keys\

On a panel host you do the same thing with the file manager or SFTP: open each @Mod/keys/ folder, copy the file, paste it into keys/ in the server root. It takes a minute per mod, and it is the minute that decides whether anyone can join. SFTP and the file manager covers getting connected, and for a mod list of more than a handful, dragging every key from a local copy of the mods into keys/ in one upload is faster than clicking through each folder.

The step people skip is the last one. A server that starts cleanly has proved only that the server can read its mods. Joining with the launcher proves that a client with the advertised mod list passes the check, which is the thing you actually care about.

-mod vs -serverMod: which mods need keys#

DayZ has two launch parameters for mods, and the difference decides whether a key is needed at all:

-mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@BuilderItems-serverMod=@MyServerTweaks;@LootLogger

Mods in -mod= are advertised to the DayZ Launcher, which subscribes players to them and starts the game with a matching list. Every one of those mods is loaded on the client, so every one is checked, so every one needs its key on the server.

Mods in -serverMod= are never advertised and never loaded by clients. Since clients do not have them, there is nothing to verify, and their keys can stay out of keys/. Typical server-only mods are loot or economy tweaks done in script, logging tools, and the server half of mods that ship a separate server package. If the author says a mod is server-side, it belongs here.

The mistakes go both ways, and each produces a different symptom:

• A client mod placed in `-serverMod=`. The server loads it, players never get it, and anything it adds is invisible or broken for them: missing items, clothing showing as an error texture, menus that do not open. No signature kick, because the client never loads the mod.
• A server-only mod placed in `-mod=`. Every player is made to download it, and if it has no key in keys, every player is kicked. Some server-only mods are not signed at all, because their authors never expected a client to load them - which turns the mistake into a guaranteed kick for everyone.

Mods can also be client-only: interface tweaks, map overlays, sound replacements that the server does not need to run. These are not in either parameter. If you want to allow one, put its .bikey in keys/, and players who have it loaded will pass verification. Players without it are unaffected. This is the only correct way to permit an optional client mod, and also the reason to be sparing: every extra key widens what the server accepts.

Updating mods without locking everyone out#

Most signature kicks on established servers happen the day a mod updates, and the cause is a mismatch between what the server has and what the launcher gives players.

When a Workshop mod updates, players subscribed to it receive the new version automatically through Steam. If the server still has the old version, two things can break:

• The author signed the update with a new key. Some authors generate a fresh key for each release, or rotate their key after a version change. The new .bisign files on the client point to a key the server has never seen. Every player with the update is kicked until the new .bikey is copied into keys/.
• Server and client versions differ in content. Even with the same key, a server running an older version and clients running a newer one disagree about classes and data, which shows up as kicks, missing items or crashes on joining.

The routine that prevents both:

1. Stop the server.
2. Update every mod on the server to the current Workshop version, not just the one you heard about. With SteamCMD that is workshop_download_item again for each id, adding validate if a download looks incomplete.
3. Copy the mod folders over the old ones in the server root.
4. Copy every .bikey again, from every mod, using the one-pass command above.
5. Start the server, read the start of the log for errors, and join through the launcher yourself.

Step 4 is the habit to build: copy all keys after any update, whether or not you believe the key changed. It costs seconds and removes the most common reason a server goes unjoinable for an evening.

Old keys pile up as authors rotate them. A stale key does no harm to joining, but it does mean the server still trusts signatures made with a key the author may have retired - in rare cases because it leaked. Once or twice a year, clear the folder back to dayz.bikey, copy every current key again, and you are left with exactly the set you need.

The other half is not updating at a bad moment. A DayZ game patch can break mods until their authors rebuild them, and on patch day the launcher hands players new mod versions as fast as authors publish them. Updating the server a few hours after the authors, when the mod list has settled, beats updating it the minute the game patches. What to do when a mod update breaks has the rollback routine, and Steam Workshop mods on dedicated servers explains how Workshop downloads behave server-side across games.

Diagnosing a signature kick#

The kick message on the player's screen is short, and its wording has changed between versions, but it usually mentions a signature check, modified data, or a specific file. The useful detail is the file name, when it is shown: a .pbo name points straight at the mod that failed.

Work through it in this order:

1. Is it everyone or one player? If every player is kicked, the server is missing a key, or a server-only mod has ended up in -mod=. If only one player is kicked, their local files are the problem.
2. Read the server log. The kick is logged in the .RPT file and the console log in the profiles folder at the moment it happens, usually naming the player and the file or reason. Search for the player's name around the time they tried to join.
3. Find the mod. Match the .pbo name to a mod folder: search every @Mod/addons/ folder for that file.
4. Check its key. Open that mod's keys folder, note the .bikey name, and confirm the same file is in the server's keys/. If a file with that name is there but the mod was recently updated, copy it again anyway - a rotated key can keep the same name.
5. Check the version. Compare the mod's last update time on the Workshop with when the server's copy was updated. If the Workshop is newer, update the server.

For one player on their own, the fix is on their machine:

• In the DayZ Launcher, open the mod list, unsubscribe from the failing mod and subscribe again, or use the launcher's repair option. Verifying through the launcher rather than through Steam's game properties makes sure the mods are checked too.
• Make sure they are not running a local edited copy of a mod, or extra client mods whose keys the server does not hold. Players who play on several servers often have a pile of mods loaded that your server never asked for.
• If they added -filePatching to their launch options for some other server or a modding tutorial, remove it.

If none of this finds it, start the server with only @CF or with no mods at all and join. If vanilla works, add mods back in groups until the kick returns. It is slow, but it always ends with a name.

Signing your own repacks#

Server owners sometimes edit a mod - changing a config inside a .pbo, merging small mods, or retexturing an item. The moment you repack a .pbo, its original .bisign no longer matches, and every client loading your version is kicked. The answer is to sign it yourself, which is what the system is designed for.

DayZ Tools, free on Steam, includes the DS utilities for this: DSCreateKey generates a key pair and DSSignFile signs a .pbo with the private half. Addon Builder in DayZ Tools can also sign while it packs, given a private key. The pair consists of a .biprivatekey, which signs, and a .bikey, which you ship.

• Put your .bikey in the server's keys/ folder and in your repack's own keys/ folder.
• Never share or upload the .biprivatekey. Anyone with it can sign files your server will accept.
• Respect the original author's terms. Many mods forbid repacking outright, and publishing someone else's work re-signed under your key is how servers get Workshop items taken down.

For most servers the better route is to avoid repacking entirely: change behaviour through the mission files, the mod's own config in the profiles folder, or a small server-side mod in -serverMod=, which needs no key at all. The DayZ Expansion server guide shows how far that gets you with one of the largest mods there is.

Keys on RE:NODE#

On a RE:NODE DayZ server the keys folder and every @Mod folder are reachable through the panel's file manager and over SFTP, with credentials per server. The file manager unpacks archives in place, so a mod uploaded as a zip can be extracted straight into the server root before you copy its key. The mod list goes in the startup settings on the Startup tab. There is no whitelist of allowed mods - you upload what you choose, and you choose which keys to trust.

Before a mod update, take a backup from the panel. Backup slots are on every DayZ plan, a backup can be restored with a button, and restoring the previous state is the quickest way out of an update that went wrong. The DayZ install itself needs your own Steam login, entered on the Setup tab after the server is created, as with any host that installs DayZ for you.

FAQ#

Where do I put a DayZ .bikey file?

In the keys folder in the server root, beside the server executable and the @Mod folders - not inside the mod, and not in the profiles folder. Every mod listed in -mod= needs its key there. Restart the server after adding keys.

Can I just set verifySignatures to 0 to stop the kicks?

You can, and it will stop them, but it also stops the server rejecting modified files, so any player can load an edited .pbo that shows loot through walls or removes recoil. Fixing the missing key takes a minute and keeps the protection.

Do server-side mods need a bikey?

No. Mods loaded with -serverMod= are never loaded by clients, so nothing is verified against them. Keys are only for what clients load: everything in -mod=, plus any optional client-only mod you choose to allow.

Why did the server break after a mod update when nothing else changed?

The mod's author probably signed the new version with a new key, so players who received the update through the launcher now carry signatures the server cannot check. Update the mod on the server and copy every key again.

Why is only one player getting kicked?

Their local copy differs: a corrupted or outdated download, a mod they edited, an extra client mod your server has no key for, or -filePatching in their launch options. Have them repair or re-subscribe through the DayZ Launcher.

Can I delete dayz.bikey?

No. It is the key for the base game's own files. Without it, every client fails the signature check on vanilla data and nobody can join, modded or not.