加密凭据报 Embedded credential name does not match

systemd-creds encrypt 生成的文件能保存下来，unit 加上 LoadCredentialEncrypted= 后却启动失败，日志出现 Embedded credential name does not match。先对照加密时绑定的名称与加载时的凭据 ID：加密文件的磁盘文件名、凭据 ID 和应用读取路径，可能是三个不同的值。

加密时若没有指定 --name=，通常会使用输出文件名的最后一个路径部分作为凭据名称。这个名称保存在加密数据中。之后把文件改名，或给 LoadCredentialEncrypted= 左边换一个 ID，不会同步修改其中的绑定名称。

在加密时明确指定应用使用的 ID

假设应用需要一个名为 foobar 的凭据，磁盘上则要保留名为 ciphertext.cred 的加密文件。系统服务的示例为：

systemd-creds encrypt --name=foobar plaintext.txt ciphertext.cred

plaintext.txt 是事先准备好的明文输入，ciphertext.cred 是输出文件。运行前应限制明文与工作目录的权限，确认当前机器支持选用的密钥方式，并保留已有凭据和可恢复配置。示例不要求把明文内容打印到终端。

将加密文件放入受控位置后，unit 的片段可写为：

[Service]
LoadCredentialEncrypted=foobar:/etc/myapp/ciphertext.cred

/etc/myapp/ciphertext.cred 是需要替换的部署路径，应让服务管理器能够读取加密文件。解密后的凭据在服务凭据目录下名为 foobar，应用应从自己的 CREDENTIALS_DIRECTORY 对应目录读取它，而不是自行把 /etc/myapp/ciphertext.cred 当成明文配置。

LoadCredentialEncrypted= 的 ID 必须与加密时的名称一致，应用读取的 ID 也必须一致。不要把 unit 指令左边的 foobar 当成任意别名。

已有加密文件不能靠重命名重新绑定

如果已有文件是以 ciphertext.cred 为内嵌名称加密的，可以在应用确实接受这个 ID 的前提下，让加载配置与它一致。应用必须用 foobar 时，则需要通过受控流程重新加密，并显式指定 --name=foobar。

不要直接改加密数据中的字符串，也不要用空的 --name= 来绕过名称校验。名称绑定用于避免凭据被加载到错误的用途，关闭它会改变安全边界。

把 LoadCredentialEncrypted= 换成 LoadCredential= 也不是解密修复。后者会按普通凭据加载数据，加密内容可能原样进入应用，随后产生更难辨认的认证错误。

名称一致后，继续核对密钥与管理器

名称匹配不能保证在任意机器解密成功。加密所用的主机密钥、TPM 条件和当前机器环境仍需符合要求；不要把复制加密文件到另一台主机等同于完成了凭据迁移。

系统服务与用户服务的加密范围也要匹配。systemd 256 起提供 --user 选项，用于用户范围的凭据；用于用户服务管理器的凭据通常应采用这个范围，系统服务管理器则使用系统范围。--uid= 还涉及具体用户，不能只在 user unit 中换路径而沿用另一种密钥范围。

如果当前 systemd 连加载凭据的指令都不支持，应先处理 旧版本不识别 LoadCredential，不能把所有凭据目录为空都归到名称不匹配。

验收时检查服务已经成功加载正确 ID，应用从自己的凭据目录读取到了预期格式且认证成功。日志和验收记录只保留必要的状态信息，不记录秘密值。重新加密的版本尚未验证前，不要提前删除唯一的可恢复明文或旧凭据。