本文介绍使用非对称加密（rsa 签名）在两个 php 应用之间验证邮件真实性，解决内网环境无法依赖 ip 或简单哈希的可信问题，确保附件邮件确实来自指定服务端。
本文介绍使用非对称加密（rsa 签名）在两个 php 应用之间验证邮件真实性，解决内网环境无法依赖 ip 或简单哈希的可信问题，确保附件邮件确实来自指定服务端。
在分布式或内网多系统架构中，当一个 PHP 应用（发送方）向另一个 PHP 应用（接收方）通过邮件传输关键文件（如报表、凭证、配置）时，仅靠邮件头字段（如 From、Subject）或明文哈希（如 MD5 放入主题）极易被篡改，完全不具备防伪能力。真正可靠的方式是采用数字签名机制——即基于非对称加密的 RSA 签名验证，它能同时保证完整性（附件未被修改）和身份真实性（确为私钥持有者发出）。
✅ 核心原理简述
发送方使用自己的私钥对附件内容的摘要（如 MD5/SHA256）进行签名；接收方使用预先共享的公钥验证该签名。只要私钥不泄露，攻击者即使截获并重放邮件，也无法伪造有效签名——这是哈希值、时间戳或 API Token 等方案无法提供的密码学保障。
? 第一步：生成密钥对
在发送方服务器执行以下 OpenSSL 命令（推荐 2048 位以提升安全性）：
openssl genrsa -out private.key 2048 openssl rsa -in private.key -pubout > public.key
将 private.key 严格保护在发送方应用可读目录（如 /etc/app/keys/），而 public.key 安全分发给所有接收方（可通过内部配置管理或部署流程同步）。
立即学习“PHP免费学习笔记（深入）”；
? 第二步：发送端签名与封装
在 PHP 发送逻辑中，对附件生成摘要并签名，注入自定义邮件头（避免污染正文或主题）：
<?php
$attachmentPath = '/var/data/report.pdf';
$hash = hash_file('sha256', $attachmentPath); // 推荐 SHA256 替代 MD5
$privateKey = openssl_pkey_get_private('file:///etc/app/keys/private.key');
if (!$privateKey) {
throw new Exception('Failed to load private key');
}
if (!openssl_sign($hash, $signature, $privateKey, OPENSSL_ALGO_SHA256)) {
throw new Exception('Signing failed: ' . openssl_error_string());
}
openssl_free_key($privateKey);
// 构建邮件（示例使用 mail()，生产环境建议用 SwiftMailer 或 PHPMailer）
$headers = [
'From' => 'sender@internal.example',
'X-Auth-Signature' => base64_encode($signature),
'X-Auth-Hash' => $hash, // 可选：便于调试，但非必需（签名已隐含摘要）
];
mail($to, $subject, $body, implode("\r\n", $headers), "-f sender@internal.example");
?>⚠️ 注意事项：
- 绝不硬编码私钥路径或内容；应通过环境变量或安全密钥管理服务加载。
- X-Auth-Signature 是自定义头，确保接收方解析时保留该字段（部分邮件网关可能过滤非常规头，建议测试）。
- 若附件较大，hash_file() 高效且内存友好；切勿对整个邮件体签名（易受编码/换行干扰）。
? 第三步：接收端验证
接收方需解析原始 .eml 文件（推荐使用成熟库如 php-mime-mail-parser），提取附件与签名头后验证：
<?php
require_once 'vendor/autoload.php';
use PhpMimeMailParser\Parser;
$parser = new Parser();
$parser->setPath('/tmp/incoming/message.eml');
// 提取首个附件（按业务逻辑调整）
$attachments = $parser->getAttachments();
if (empty($attachments)) {
throw new Exception('No attachment found');
}
$attachment = $attachments[0];
$tempFile = tempnam(sys_get_temp_dir(), 'verify_');
file_put_contents($tempFile, $attachment->getContent());
// 获取签名与预期哈希
$signature = base64_decode($parser->getHeader('x-auth-signature'));
$expectedHash = $parser->getHeader('x-auth-hash'); // 或重新计算：hash_file('sha256', $tempFile)
$publicKey = openssl_pkey_get_public('file:///etc/app/keys/public.key');
if (!$publicKey) {
throw new Exception('Failed to load public key');
}
$result = openssl_verify($expectedHash, $signature, $publicKey, OPENSSL_ALGO_SHA256);
openssl_free_key($publicKey);
if ($result === 1) {
echo "✅ Signature valid — email and attachment are authentic.\n";
// 安全处理附件：移动至业务目录、触发后续流程等
} elseif ($result === 0) {
throw new Exception('❌ Signature invalid — possible tampering or wrong sender');
} else {
throw new Exception('❌ OpenSSL error: ' . openssl_error_string());
}
?>? 关键总结
- 哈希 ≠ 签名：单纯在邮件中嵌入 md5(file) 完全无安全意义，必须结合私钥签名才能抗伪造。
- 公钥分发需可信：首次部署时确保接收方公钥与发送方私钥配对，且公钥不被中间人替换（可通过内网配置中心签名发布）。
- 防御纵深：签名验证应作为第一道闸门，后续仍需做 MIME 类型检查、病毒扫描、文件大小限制等常规防护。
- 升级建议：长期运行系统可引入证书体系（X.509）或 JWT+JWK 实现更灵活的密钥轮换与多发件人管理。
通过以上实现，你构建了一套轻量、标准、可审计的跨应用邮件身份认证机制，从根本上杜绝了内网场景下的冒充与篡改风险。
