Simple answer:
To verify a certificate chain, call SecTrustEvaluate.
Longer answer:
This requires first obtaining a SecPolicyRef for the desired evaluation
policy. You start by calling SecPolicySearchCreate with the OID for the
desired policy, which returns a SecPolicySearchRef. If you are just
interested in whether the chain verifies back to a trusted root in
X509Anchors, as opposed to whether it meets additional policy rules for
SSL, S/MIME, etc., then pass &CSSMOID_APPLE_X509_BASIC for the
CSSM_OID* parameter. Once you have created the SecPolicySearchRef, call
SecPolicySearchCopyNext to get the first matching SecPolicyRef.
Next, call SecTrustCreateWithCertificates to create a SecTrustRef with
this policy and your certificate chain.
Finally, you call SecTrustEvaluate, which returns a simple evaluation
result (of type SecTrustResultType). If you need more information, such
as which cert in the chain didn't verify (and why), you can
additionally call SecTrustGetResult, which gives you per-cert status
info.
Remember that all these *Ref references are Core Foundation object
instances, so you need to call CFRelease on them when you're done.
I have this on my list of "things that need sample code," but
unfortunately don't have it written at the moment.
-ken
On Nov 22, 2004, at 4:10 PM, Jamie Wood wrote:
Hi Perry,
Thanks for this info.
I have one more question.
I have a certificate chain that I want to verify. I want to make sure
that the leaf certificate comes from me, and that the root certificate
is a trusted root CA (i.e., it is in X509Anchors).
Can you give me some API hints on how best to do this?
Thanks,
Jamie
From: Perry The Cynic <email@hidden>
To: Jamie Wood <email@hidden>
CC: email@hidden
Subject: Re: Mac OS X code signing suggestions?
Date: Wed, 10 Nov 2004 15:51:08 -0800
> The "codesigning" value of the extended key usage extension is
> explicitly designed to cover signing executable stuff. It would
be a
> reasonable policy to only accept code signed with a certificate
that
> has this usage enabled (following the usual X509 rules and
profiles).
> You will find that Verisign et al charge rather larger fees for
code
> signing certificates, on the grounds that you're probably a
> corporation that can afford it. (There is arguably also a greater
risk
> of lawsuits associated with those.)
>
> The manifest APIs in Tiger will, by default, verify against the
X509
> Generic policy and thus accept any (valid) certificate. They have
> provisions to break out the certificate validation step so you can
hack
> it any way you like.
>
So, in Tiger I will be able to sign my code with a JavaSoft
certificate
and write my client so that Tiger will accept it, by modifiying the
verification process so that it handles JavaSoft certificates? Or,
will I
have to ask Verisign to just give me a "generic" code signing
certificate
(if such a thing exists)?
Careful here. "Tiger" does not accept or reject anything. The system
does not, as of Tiger, *require* that you sign code, and it will
ignore any signatures applied to your bundles. It's up to you to call
APIs to verify any signatures as you see fit.
Note (since you brought up Java) that the Java programming
environment may have its own idea of signing and verifying Java code,
which is entirely separate and independent from the Manifest APIs
we're discussing, and is only used within the Java environment.
With that proviso, any code signing cert should do. In fact, any cert
without an "extended key usage" extension will do, too, because the
default is "if the extension is absent, it allows anything." (Any CA
handing out such certificates today ought to be flogged, of course.)
If I use the Generic policy, will I be able to sign my code with any
certificate and verify it using the manifest APIs, even if the
certificate does not have a code signing extension?
Yes. The "X509 Generic" policy just verifies the cryptographic
integrity of the cert chain. It does not impose any other constraints
on the certificate, other than self-consistency (e.g. CA certs with
extended usage extensions must be consistent with the certs they
sign).
Cheers
-- perry
----------------------------------------------------------------------
-----
Perry The Cynic
email@hidden
To a blind optimist, an optimistic realist must seem like an Accursed
Cynic.
----------------------------------------------------------------------
-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
