{"id":42062,"date":"2024-02-07T14:38:10","date_gmt":"2024-02-07T19:38:10","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42062"},"modified":"2024-02-07T14:38:10","modified_gmt":"2024-02-07T19:38:10","slug":"inside-code-signing-certificates","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/02\/07\/inside-code-signing-certificates\/","title":{"rendered":"Inside Code Signing: Certificates"},"content":{"rendered":"

TN3161<\/a> (via Quinn<\/a>):<\/p>\n

\n

To condense this into plain English, this certificate says that “Apple certifies that this developer is associated with this public key, and the matching private key can be used to sign Mac code.” This is clearly a simplification—it doesn’t touch on the valid date range, serial number, or even how Apple identified the developer in the first place—but it’s a reasonable model to start out with.<\/p>

Apple issues a variety of different code-signing certificate types. For a complete list, see Certificate types<\/a>.<\/p>\n

[…]<\/p>\n

Certificates often form a chain of trust: the verifier uses the issuer information in a certificate to find the issuer’s certificate, then uses its issuer information to find the next certificate in the chain, and so on, until it hits an anchor, that is, a certificate it trusts as a matter of policy.<\/p>\n

[…]<\/p>\n

To sign code you need a certificate and the private key that matches the public key in that certificate. This combination is called a digital identity or, if it’s for signing code, a code-signing identity.<\/p>\n

[…]<\/p>\n

It’s easy to miss that your most critical code-signing asset, your private key, is tucked away in your login keychain. And if you do miss that, you might lose your private key, for example, when you migrate to a new Mac.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n