Hello, I have a SCR3310 device and am using a GEMALTO ACCESS 64KV2 CAC. I have downloaded and installed CAC-NG (BETA v0.95)/Snow Leopard from http://smartcardservices.macosforge.org/trac/wiki/installers. I can now see my CAC certificates on the CAC Keychain where I could not before this step. That is great, however the 4 certificates I have are all showing that they have invalid issuers. When I show the certificate after evaluating it, it shows that the DoD Interoperability Root Ca 1 and DoD Root Ca 2 cannot be used due to unrecognized critical extensions. This shows up when I go to use Outlook 2011 for Mac and it will not allow me to digitally sign or encrypt my e-mail. I don¹t think it is a CAC issue because when I use the CAC on my old XP PC using Outlook 2003, I am able to digitally sign and encrypt my e-mail there. Can someone provide some insight as to what my issue may be?? Thanks in advance, Charlie Victory
On Nov 23, 2010, at 9:15 AM, Charles Victory wrote:
Hello,
I have a SCR3310 device and am using a GEMALTO ACCESS 64KV2 CAC. I have downloaded and installed CAC-NG (BETA v0.95)/Snow Leopard from http://smartcardservices.macosforge.org/trac/wiki/installers‘. I can now see my CAC certificates on the CAC Keychain where I could not before this step. That is great, however the 4 certificates I have are all showing that they have invalid issuers. When I show the certificate after evaluating it, it shows that the DoD Interoperability Root Ca 1 and DoD Root Ca 2 cannot be used due to unrecognized critical extensions. This shows up when I go to use Outlook 2011 for Mac and it will not allow me to digitally sign or encrypt my e-mail. I don’t think it is a CAC issue because when I use the CAC on my old XP PC using Outlook 2003, I am able to digitally sign and encrypt my e-mail there.
Can someone provide some insight as to what my issue may be??
This is most likely due to a certificate extension being flagged as Critical, but not being understood by the Apple Security framework. It could be that your certificates have a name constraints extension flagged as critical. I don't think Apple recognizes the name constraints, and must report that the certificate is invalid due to the critical flag. I have reported the name constraints problem as bug with the title "Apple PKI trust policy does not handle name constraints (RFC RFC5280)" Here is the bug report text:
This problem presents a denial of service security issue.
Implementations of RFC RFC5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" must support name constraints per section 4.2
This section states:
"At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14)."
Read more: http://www.faqs.org/rfcs/rfc5280.html#ixzz0dMPhg7t9
Most new CA certificates issued by the U.S. Federal Government contain name constraints.
For example NASA PIV cards include such certificates. The Macintosh cannot validate such certificate chains because the name constraint is marked as critical.
Refer to http://www.idmanagement.gov/fpkia
Just a clarification on the NASA Certificates: We do not have this issue if the proper certificate chaining is used. We have seen this issue occur but only if the someone does not have the proper certificates configured and they attempt to chain through the Federal Bridge. For example the, FBCA with Serial Number of 118979359, has an unrecognized critical extension and if a NASA certificate attempts chain to the Treasury Root via that certificate then it will fail. NASA Operational CA Certificates should be using the direct path from the NOCA certificate issued by the Treasury Root CA to the Treasury Root CA, or from the NOCA certificate issued by the Common Policy Root CA, to the Common Policy Root CA. There are no unknown [to OS X] critical extensions in those paths. Having said that, I agree that Apple needs to fix this and recognize the extensions. There is a thread about this with more detail from April 2-5, 2010 on Fed-Talk. The stubborn effect I have seen is that if a client is sending email with a malformed chain that attempts to use a certificate with an unknown [to OS X] critical extension, the email contains that chain information, so even if the client has the proper certificates in the keychain, Apple Mail will use the chain that the sender used because it is in the SMIME information. Ridley DiSiena ETADS / ICAM Engineering Phone: (216) 543-1357 ridley.disiena@nasa.gov<mailto:ridley.disiena@nasa.gov> On Nov 23, 2010, at 11:27 AM, Paul Nelson wrote: On Nov 23, 2010, at 9:15 AM, Charles Victory wrote: Hello, I have a SCR3310 device and am using a GEMALTO ACCESS 64KV2 CAC. I have downloaded and installed CAC-NG (BETA v0.95)/Snow Leopard from http://smartcardservices.macosforge.org/trac/wiki/installers‘. I can now see my CAC certificates on the CAC Keychain where I could not before this step. That is great, however the 4 certificates I have are all showing that they have invalid issuers. When I show the certificate after evaluating it, it shows that the DoD Interoperability Root Ca 1 and DoD Root Ca 2 cannot be used due to unrecognized critical extensions. This shows up when I go to use Outlook 2011 for Mac and it will not allow me to digitally sign or encrypt my e-mail. I don’t think it is a CAC issue because when I use the CAC on my old XP PC using Outlook 2003, I am able to digitally sign and encrypt my e-mail there. Can someone provide some insight as to what my issue may be?? This is most likely due to a certificate extension being flagged as Critical, but not being understood by the Apple Security framework. It could be that your certificates have a name constraints extension flagged as critical. I don't think Apple recognizes the name constraints, and must report that the certificate is invalid due to the critical flag. I have reported the name constraints problem as bug with the title "Apple PKI trust policy does not handle name constraints (RFC RFC5280)" Here is the bug report text: This problem presents a denial of service security issue. Implementations of RFC RFC5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" must support name constraints per section 4.2 This section states: "At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14)." Read more: http://www.faqs.org/rfcs/rfc5280.html#ixzz0dMPhg7t9 Most new CA certificates issued by the U.S. Federal Government contain name constraints. For example NASA PIV cards include such certificates. The Macintosh cannot validate such certificate chains because the name constraint is marked as critical. Refer to http://www.idmanagement.gov/fpkia _______________________________________________ SmartcardServices-Users mailing list SmartcardServices-Users@lists.macosforge.org<mailto:SmartcardServices-Users@lists.macosforge.org> http://lists.macosforge.org/mailman/listinfo.cgi/smartcardservices-users
Paul, Thank you very much for the prompt reply. I have looked at the certificates again and I can see several extensions marked as critical. At least I won't waste any more time pulling my hair out in frustration over this issue. Do you have any idea of how I can track this issue and when it might be resolved?? Thanks, Charlie From: Paul Nelson <nelson@thursby.com> Date: Tue, 23 Nov 2010 10:27:39 -0600 To: Charles Victory <cvictory@y-linkconsulting.com> Cc: <smartcardservices-users@lists.macosforge.org> Subject: Re: [SmartcardServices-Users] Issue with CAC on Snow Leopard On Nov 23, 2010, at 9:15 AM, Charles Victory wrote:
Hello,
I have a SCR3310 device and am using a GEMALTO ACCESS 64KV2 CAC. I have downloaded and installed CAC-NG (BETA v0.95)/Snow Leopard from http://smartcardservices.macosforge.org/trac/wiki/installers. I can now see my CAC certificates on the CAC Keychain where I could not before this step. That is great, however the 4 certificates I have are all showing that they have invalid issuers. When I show the certificate after evaluating it, it shows that the DoD Interoperability Root Ca 1 and DoD Root Ca 2 cannot be used due to unrecognized critical extensions. This shows up when I go to use Outlook 2011 for Mac and it will not allow me to digitally sign or encrypt my e-mail. I don¹t think it is a CAC issue because when I use the CAC on my old XP PC using Outlook 2003, I am able to digitally sign and encrypt my e-mail there.
Can someone provide some insight as to what my issue may be?? This is most likely due to a certificate extension being flagged as Critical, but not being understood by the Apple Security framework. It could be that your certificates have a name constraints extension flagged as critical. I don't think Apple recognizes the name constraints, and must report that the certificate is invalid due to the critical flag.
I have reported the name constraints problem as bug with the title "Apple PKI trust policy does not handle name constraints (RFC RFC5280)" Here is the bug report text:
This problem presents a denial of service security issue.
Implementations of RFC RFC5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" must support name constraints per section 4.2
This section states:
"At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14)."
Read more: http://www.faqs.org/rfcs/rfc5280.html#ixzz0dMPhg7t9
Most new CA certificates issued by the U.S. Federal Government contain name constraints.
For example NASA PIV cards include such certificates. The Macintosh cannot validate such certificate chains because the name constraint is marked as critical.
Refer to http://www.idmanagement.gov/fpkia
participants (3)
-
Charles Victory
-
Disiena, Ridley J. (GRC-VO00)[DB Consulting Group, Inc.]
-
Paul Nelson