Re: CertGetCertificateChain() - CERT_TRUST_HAS_PREFERRED_ISSUER

From: Michael Virgil (mvirgil_at_nortelnetworks.com)
Date: 09/11/03 

Date: Thu, 11 Sep 2003 10:45:48 -0700

Thanks, It didn't occur to me that CA Certs would not be
in the local machine store.

Thanks again for the help,
Michael

>-----Original Message-----
>If you imported the CA cert via IE cert manager, then the
certificate was
>imported into the current user's root store (if a self-
signed certificate)
>or the current user's CA store. To import it into the
local machine store
>you need to use the MMC certificates snap-in for the
local machine
>certificates.
>
>--
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>Use of included script samples are subject to the terms
specified at
>http://www.microsoft.com/info/cpyright.htm
>"Michael Virgil" <mvirgil@nortelnetworks.com> wrote in
message
>news:0b9001c377d5$d2e2bc80$a001280a@phx.gbl...
>>
>> Thanks for the quick reply and the explaination of the
>> InfoStatus. That helps.
>>
>> I did the investigation as you suggested. The CA and
>> Server certificates do agree on the issuing CA, as
>> indicated in the AKI extension of the server
certificate:
>>
>> CA Certificate:
>> SUBJECT: CN = Client Engineering CA
>>
>> O = Engineering
>>
>> C = US
>> Serial number: 06 66 e8 ca ac 6d 9f bd 45 e9 38 3d e9 90
>> 7e f1
>> Subject key indenter: b3 44 87 b4 56 68 78 05 80 63 90
>> a5 d1 c9 86 38 37 2a d9 9e
>>
>> Server Certificate:
>> SUBJECT: CN = mikes server cert
>>
>> AKI:
>> KeyID=b3 44 87 b4 56 68 78 05 80 63 90 a5 d1 c9 86 38 37
>> 2a d9 9e
>> Certificate Issuer:
>> Directory Address:
>> CN=Client Engineering CA
>>
O=Engineering
>> C=US
>> Certificate SerialNumber=06 66 e8 ca ac 6d 9f bd 45 e9
38
>> 3d e9 90 7e f1
>>
>> I also imported the server certificate onto the system
>> that was failing the CRL check. The certificate manager
in
>> IE was happy with the server and CA. indicating that it
>> has a valid and trusted CA.
>>
>> The thing I didn't mention in my original description
was
>> that the client side application is running as a
>> Windows/NT service. Then, I tried on a whim,
impersonating
>> the logged on user! It works!
>>
>> I would have expected it to work running as a service
>> since, I assumed that the CA certs would be stored in
>> HKEY_LOCAL_MACHINE...?
>>
>> Interesting.
>>
>> Now, so the question now becomes; Is this the correct
>> approach when running as a service?
>>
>> Thanks,
>> Michael
>>
>>
>> >-----Original Message-----
>> >If the CA certificate is showing as an untrusted root,
it
>> means that it's
>> >not in the ROOT store for the machine where the
>> verification is taking
>> >place. If it appears that it is there, compare the
public
>> key and subject
>> >and issuer nams of the one that appears to be there
>> against the one being
>> >used in the verification - they will most likely not
>> match, meaning they are
>> >different certificates.
>> >
>> >Info status bits (they are listed in wincrypt.h):
>> >
>> >CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
>> >CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x001)
>> >CERT_TRUST_IS_SELF_SIGNED (0x008)
>> >CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x004)
>> >
>> >So the server certificate element has "exact match"
>> and "preferred issuer"
>> >info bits set. The CA element has "self signed"
and "name
>> match" info bits
>> >set.
>> >
>> >Note that "exact match" means that the CA's issuer and
>> serial number must
>> >match EXACTLY what is listed in the server cert's
>> Authority Key Identifier
>> >(AKI) extension.
>> >
>> >--
>> >This posting is provided "AS IS" with no warranties,
and
>> confers no rights.
>> >Use of included script samples are subject to the terms
>> specified at
>> >http://www.microsoft.com/info/cpyright.htm
>> >"Michael Virgil" <mvirgil@nortelnetworks.com> wrote in
>> message
>> >news:06b001c37709$5290d3e0$3101280a@phx.gbl...
>> >>
>> >> Baffled...
>> >>
>> >> Using the same X.509 certificate and calling
>> >> CertGetCertificateChain() to perform the CRL check, I
>> get
>> >> different results on three different systems,
Windows/XP
>> >> and Windows/2000. On one Windows/2000 system, the
>> >> certificate CRL check passes. On the other 2, a
>> Windows/XP
>> >> and a Windows/2000 system the call fails with the
>> >> following:
>> >>
>> >> TrustStatus.dwErrorStatus =
CERT_TRUST_IS_UNTRUSTED_ROOT
>> >> TrustStatus.dwInfoStatus =
>> CERT_TRUST_HAS_PREFERRED_ISSUER
>> >>
>> >> Is is a standalone CA that is on the same network.
>> >>
>> >> My assumption is that the problem is environmental,
but
>> >> for the life of me can't find it. The server X.509
>> >> certificate is not installed on the system, but
passed
>> to
>> >> the client application from the server application
for
>> >> verification, mutual authentication of the client and
>> >> server. The ROOT CA Certificate is installed on all
>> these
>> >> client systems. All certificates are issued by the
same
>> >> Microsoft stand-alone CA.
>> >>
>> >> The call to CertGetCertificateChain() to perform the
CRL
>> >> check uses the default Certificate Chain Engine for
CRL
>> >> checking. No enhanced key usage is checked. The
>> following
>> >> flags are used:
>> >>
>> >> CERT_CHAIN_REVOCATION_CHECK_CHAIN |
>> >> CERT_CHAIN_REVOCATION_CHECK_END_CERT |
>> >> CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT;
>> >>
>> >> The other interesting thing is that I dumped the CRL
>> chain
>> >> to look at it, the log shows only one chain with 2
>> >> elements; server's certificate and the signing CA
>> >> certificate.
>> >>
>> >> The status from the CRL chain:
>> >>
>> >> The server certificate element:
>> >> - TrustStatus: 0
>> >> - InfoStatus: 257 (or 0x0101) UNKNOWN
>> >>
>> >> The CA certificate element:
>> >> - TrustStatus: 32 - The certificate or certificate
>> chain
>> >> is based on an untrusted root.
>> >> - Infostatus: 268 (or 0x010C) UNKNOWN
>> >>
>> >> I couldn't find either of these in WinCrypt.h? What
do
>> >> these mean? And Why is the CA certificate an
untrusted
>> >> root?
>> >>
>> >> Any ideas or helpful hints would be greatly
appreciated.
>> >>
>> >> Thanks,
>> >> Michael
>> >>
>> >>
>> >>
>> >
>> >
>> >.
>> >
>
>
>.
>

Relevant Pages

  • X.509 Certs - Best practice?
    ... X.509 certs correctly. ... I'm going to digitally sign my SOAP messages using an X.509 certificate ... before sending them to the web service. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: ADFS and Certificate Services
    ... ADFS even allows you to do client certificate ... Joe Kaplan-MS MVP Directory Services Programming ... We just want to be able to give out certs to our own ... sub-CA on the internet for employees to access remotely to get certs. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS Proxy Cert issue
    ... know the command line for requesting a proper client certificate though. ... you would start getting these certs from the CA that you will ... FSP setup better. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS and Certificate Services
    ... sub-CA on the internet for employees to access remotely to get certs. ... Essentially, to become a certificates "reseller", you need a CA certificate ...
    (microsoft.public.windows.server.active_directory)
  • Re: HP Procurve 2626 - port-based access IAS EAP-LTS doesnt work
    ... It depends on how you deploy EAP-TLS -- are you using computer certs ... The first thing is to make sure the client and user certificates are ... To configure the certs, you must open Certificate ...
    (microsoft.public.internet.radius)