keygen 标签已被彻底移除，所有主流浏览器均不解析；其替代方案是 Web Crypto API 手动生成密钥对或优先采用 WebAuthn 进行身份认证。
keygen 标签已被彻底移除，没有“废弃但还能用”这回事
document.querySelector('keygen') 返回 null，表单提交时不会附带任何密钥材料。
为什么不能继续用 —— 安全模型与控制权问题
浏览器原生
- 私钥导出机制不透明，开发者无法审计或控制私钥生命周期
- 不同浏览器实现差异大，Chrome 用 OS 密钥库，Firefox 曾用 NSS，行为不可预测
- 无法配合 WebAuthn、TPM 或硬件安全模块（HSM）等现代认证路径
- 表单提交即发送公钥，缺乏对签名上下文、挑战（challenge）和算法的显式控制
实际可落地的替代方案：Web Crypto API + 自定义流程
当前唯一标准、跨浏览器（Chrome 37+、Firefox 34+、Safari 16.4+）、可控性强的方案是直接使用 crypto.subtle.generateKey() 配合后端协作。关键不是“替换一个标签”，而是重构密钥生成与身份绑定逻辑：
-
前端调用
crypto.subtle.generateKey({ name: 'RSA-PSS', modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: 'SHA-256' }, true, ['sign', 'verify'])生成密钥对 - 用
crypto.subtle.exportKey('spki', publicKey)提取公钥（DER 编码），再转为 PEM 格式供后端验证 - 私钥始终保留在
KeyPair.privateKey中，仅用于后续sign()，绝不序列化或上传 - 后端需支持接收 PEM 公钥，并在用户登录/操作时发起 challenge，要求前端用私钥签名返回
const challenge = new TextEncoder().encode("login-20240521-abc123");
const signature = await crypto.subtle.sign(
{ name: "RSA-PSS", saltLength: 32 },
privateKey,
challenge
);
// 发送 signature（ArrayBuffer）和 challenge 给后端校验
更推荐的升级路径：优先考虑 WebAuthn 而非手搓密钥
如果目标是用户身份认证（比如替代密码登录），navigator.credentials.create() 是比手动管理 RSA 密钥对更安全、更易用的选择：
立即学习“前端免费学习笔记（深入）”；
- 密钥由 authenticator（如 YubiKey、Touch ID、Windows Hello）本地生成并保管，私钥永不离开设备
- 天然防钓鱼：每次签名都绑定当前源（origin）和 challenge
- 无需自己处理 PEM/DER、base64url 编码、算法协商等细节
- 服务端只需调用
webauthn.verifyRegistrationResponse()（如用@simplewebauthn/server）
只有当业务明确需要长期可复用的公钥（如 SSH 登录代理、代码签名证书申请）时，才需坚持 Web Crypto 手动流程；其他绝大多数身份场景，WebAuthn 是更少出错、更难绕过的路径。
别再找
