Fix: CSR version field must be 0 (v1), not 1, per RFC 2986

[poofygummy]

generateRequest:privateKey: in ALTCertificateRequest.m calls X509_REQ_set_version(request, 1). Per RFC 2986, the CSR version field is defined as INTEGER { v1(0) } — the only version ever standardized is named "v1," but its actual encoded value is 0, not 1. There's no version numbered 1 in the spec at all.
This passed unnoticed because X509_REQ_set_version's return value only confirms the field was set, not that the value was correct — so the existing != 1 success check still passes even with the wrong version number written in. The malformed CSR gets built successfully and signs fine locally; it's only rejected later, server-side, when actually submitted.
We hit this directly: a certificate renewal flow that revokes an old cert and requests a new one in the same pass was consistently failing with Apple's submitDevelopmentCSR endpoint returning "The certificate request is invalid," with no other indication of what was wrong. Changing the value to 0 fixed it immediately — the same request that failed with resultCode nonzero now returns resultCode = 0 and statusString = "Approved".
It's a one-character change, but it took a while to track down since the failure only ever shows up on Apple's side, well after local CSR generation reports success.
Helped by Claude Sonnet 5