keygen 的 challenge 属性仅作为任意字符串嵌入 CSR 的 attributes 字段供后端关联上下文，不参与加密或密钥生成；Chrome 65+、Firefox 69+等已彻底废弃该元素，须改用 Web Crypto API 手动构造含 challenge 的 PKCS#10 CSR。
keygen 的 challenge 属性到底干啥用？
它本身不参与加密，也不生成密钥，只是作为一段任意字符串，被浏览器在生成密钥对时一并打包进 CSR（证书签名请求）的 challenge 字段里，最终传给后端。后端收到 CSR 后可读取该字段，用于关联请求上下文（比如绑定用户会话 ID、防重放 token 等），但完全由后端解析和校验，keygen 自身不做任何处理。
为什么现在根本用不了 keygen 和 challenge？
Chrome 65+、Firefox 69+、Edge（基于 Chromium 后）已彻底移除 <keygen> 元素支持，HTML5 规范也早在 2018 年将其标记为“废弃（obsolete）”。调用 document.querySelector('keygen') 会返回 null，表单提交时该字段直接消失，控制台报错 The keygen element is obsolete。所有依赖它的前端逻辑都会静默失效。
替代方案：用 Web Crypto API 手动构造带 challenge 的 CSR
若仍需客户端生成密钥 + 附带 challenge 字符串（如对接私有 CA），必须绕过 keygen，改用 crypto.subtle.generateKey() + ASN.1 编码库（如 asn1js）手动拼 CSR。关键点：
-
challenge不再是 HTML 属性，而是你写进 CSR 的attributes部分的一个 OID（例如1.2.840.113549.1.9.7）对应值 - 私钥必须用
extractable: false生成，否则无法导出用于签名 - CSR 签名必须用私钥对 TBSCertRequest 结构做
sign()，不能只 base64 encode 公钥 - 服务端收到的不再是
application/x-www-form-urlencoded中的keygen字段，而是完整 PEM 格式 CSR 字符串，需自行解析attributes
最容易被忽略的兼容性陷阱
很多老项目以为只要把 keygen 换成 input type="hidden" + 后端生成密钥就能过渡，其实不行——challenge 的语义绑定在 CSR 生成环节，脱离客户端密钥生成，服务端就无法确保 challenge 与公钥的强绑定关系，攻击者可截获并复用 challenge 值。真正安全的迁移必须让 challenge 参与 CSR 签名过程，哪怕只是作为 attributes 字段，也得走一遍完整的 PKCS#10 构造流程。
