A Certificate Signing Request (CSR) is the file you give Apple to be issued a code signing certificate. It is a PKCS#10 structure containing a freshly-generated public key plus the team's identity, all signed by the matching private key as proof that you hold it. Apple's portal accepts the CSR, verifies the signature, and issues a certificate that wraps the same public key.
Why Apple wants a CSR instead of just a public key
- It proves you actually have the private key (you signed the request with it).
- It commits you to a specific public key, so the issued certificate binds to a key only you control.
- It is a standard PKI format. Apple did not have to invent anything.
Generating one
# Keychain Access: # Keychain Access > Certificate Assistant > Request a Certificate from a CA # - email: anything, Apple does not validate it # - common name: a label you will recognize later # - 'Saved to disk' (not 'Emailed to the CA') # openssl equivalent openssl req -new -newkey rsa:2048 -nodes \ -keyout HexSignDist.key \ -out HexSignDist.csr
Reuse vs regenerate
When a certificate is about to expire, you can either generate a brand new CSR and a new private key, or reuse the same CSR (and therefore the same private key) and issue a fresh certificate against it. Reusing means every artifact that already trusts the public key, like a long-lived provisioning profile or an embedded certificate hash, keeps working. Most teams reuse for App Store distribution and rotate keys only when they are forced to (compromise, lost key, policy).