Post

Replies

Boosts

Views

Activity

Revocation-status source for Apple Code Signing Certification Authority (serial 0x21)
Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.
0
0
45
6h
Revocation-status source for Apple Code Signing Certification Authority (serial 0x21)
Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.
Replies
0
Boosts
0
Views
45
Activity
6h