Win2K certificate chain validity problem

[Rudy Hartono]

Hi,

I have a problem with a Win2k Certificate Chain validation. (Try using
Win2K SP2 and Win2K SP4)

I have 3 certificates:
1. Root CA Certificate
2. Intermediate CA Certificate
3. End User Certificate

I put Root CA Certificate to Trusted Root Certification Authorities
Current User Store and Intermediate CA Certificate to Intermediate
Certification Authorities Current User Store and End User Certificate
to Personal (My) Current User Store.

When I view the Root CA Certificate, the Certificate Viewer said the
Certificate is valid. It is the same when I view Intermediate CA
Certificate.
But when I view End User Certificate, it said "Windows does not have
enough information to verify this certificate" and on Certification
Path tab the status is "The issuer of this certificate could not be
found".

Check Root CA Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 01
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c
f0 6a
No key provider information
No stored keyset property
Certificate is valid

Check Intermediate CA Certificate using certutil.exe and here is the
result:
================ Certificate 0 ================
Serial Number: 06
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Certificate Template: SubCA
Non-root Certificate
Cert Hash(sha1): b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95
8b fb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

CertContext[0][1]: dwInfoStatus=c dwErrorStatus=0
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Serial: 01
f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c f0 6a
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

Exclude leaf cert:
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Full chain:
01 d7 91 7e 65 13 4b 1a 6d 2d f9 e5 2c 29 29 d3 56 bc 05 dd
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
The revocation function was unable to check revocation for the
certificate. 0x80092012 (-2146885614)
------------------------------------
Revocation check skipped -- no revocation information available
Certificate is valid


Check End User Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 12
Issuer: [email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Non-root Certificate
Cert Hash(sha1): af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12
e8 cb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Missing Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
An internal certificate chaining error has occurred. 0x800b010a
(-2146762486)
------------------------------------
Incomplete certificate chain
Cannot find certificate:
[email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG

Do anybody know what is going wrong ?
Is there any bugs reported by Microsoft about this problem (Have been
searching at microsoft web site since yesterday but cannot found
anything) ?

Thanks in advance.

Best Regards,


Rudy

 

[Rudy Hartono]

Hmm,

Strange, try on WinXP and Win2003 server and everything works fine.

Can anybody from Microsoft respond on this ?

Best Regards,

Rudy

Hi,

I have a problem with a Win2k Certificate Chain validation. (Try using
Win2K SP2 and Win2K SP4)

I have 3 certificates:
1. Root CA Certificate
2. Intermediate CA Certificate
3. End User Certificate

I put Root CA Certificate to Trusted Root Certification Authorities
Current User Store and Intermediate CA Certificate to Intermediate
Certification Authorities Current User Store and End User Certificate
to Personal (My) Current User Store.

When I view the Root CA Certificate, the Certificate Viewer said the
Certificate is valid. It is the same when I view Intermediate CA
Certificate.
But when I view End User Certificate, it said "Windows does not have
enough information to verify this certificate" and on Certification
Path tab the status is "The issuer of this certificate could not be
found".

Check Root CA Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 01
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c
f0 6a
No key provider information
No stored keyset property
Certificate is valid

Check Intermediate CA Certificate using certutil.exe and here is the
result:
================ Certificate 0 ================
Serial Number: 06
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Certificate Template: SubCA
Non-root Certificate
Cert Hash(sha1): b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95
8b fb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

CertContext[0][1]: dwInfoStatus=c dwErrorStatus=0
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Serial: 01
f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c f0 6a
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

Exclude leaf cert:
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Full chain:
01 d7 91 7e 65 13 4b 1a 6d 2d f9 e5 2c 29 29 d3 56 bc 05 dd
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
The revocation function was unable to check revocation for the
certificate. 0x80092012 (-2146885614)
------------------------------------
Revocation check skipped -- no revocation information available
Certificate is valid


Check End User Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 12
Issuer: [email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Non-root Certificate
Cert Hash(sha1): af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12
e8 cb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Missing Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
An internal certificate chaining error has occurred. 0x800b010a
(-2146762486)
------------------------------------
Incomplete certificate chain
Cannot find certificate:
[email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG

Do anybody know what is going wrong ?
Is there any bugs reported by Microsoft about this problem (Have been
searching at microsoft web site since yesterday but cannot found
anything) ?

Thanks in advance.

Best Regards,


Rudy

 

[Rudy Hartono]

Hi,

Since there are no body in this newsgroup respond to my previous
posting, Can any body suggest the correct newsgroup to post it ?

Best Regards,


Rudy

Hmm,

Strange, try on WinXP and Win2003 server and everything works fine.

Can anybody from Microsoft respond on this ?

Best Regards,

Rudy

Hi,

I have a problem with a Win2k Certificate Chain validation. (Try using
Win2K SP2 and Win2K SP4)

I have 3 certificates:
1. Root CA Certificate
2. Intermediate CA Certificate
3. End User Certificate

I put Root CA Certificate to Trusted Root Certification Authorities
Current User Store and Intermediate CA Certificate to Intermediate
Certification Authorities Current User Store and End User Certificate
to Personal (My) Current User Store.

When I view the Root CA Certificate, the Certificate Viewer said the
Certificate is valid. It is the same when I view Intermediate CA
Certificate.
But when I view End User Certificate, it said "Windows does not have
enough information to verify this certificate" and on Certification
Path tab the status is "The issuer of this certificate could not be
found".

Check Root CA Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 01
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c
f0 6a
No key provider information
No stored keyset property
Certificate is valid

Check Intermediate CA Certificate using certutil.exe and here is the
result:
================ Certificate 0 ================
Serial Number: 06
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Certificate Template: SubCA
Non-root Certificate
Cert Hash(sha1): b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95
8b fb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

CertContext[0][1]: dwInfoStatus=c dwErrorStatus=0
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Serial: 01
f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c f0 6a
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

Exclude leaf cert:
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Full chain:
01 d7 91 7e 65 13 4b 1a 6d 2d f9 e5 2c 29 29 d3 56 bc 05 dd
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
The revocation function was unable to check revocation for the
certificate. 0x80092012 (-2146885614)
------------------------------------
Revocation check skipped -- no revocation information available
Certificate is valid


Check End User Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 12
Issuer: [email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Non-root Certificate
Cert Hash(sha1): af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12
e8 cb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Missing Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
An internal certificate chaining error has occurred. 0x800b010a
(-2146762486)
------------------------------------
Incomplete certificate chain
Cannot find certificate:
[email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG

Do anybody know what is going wrong ?
Is there any bugs reported by Microsoft about this problem (Have been
searching at microsoft web site since yesterday but cannot found
anything) ?

Thanks in advance.

Best Regards,


Rudy

 

[Vishal Agarwal[MSFT]]

Could you please send the certificate (attach them as text files or just put
base64 enocded cert in the mail).

Also on Win2003 Server, could you also run:

Certutil -verify ee.cer subca.cer

Certutil -verify subca.cer rootca.cer

Thanks,
Vishal[MSFT]
--
This posting is provided "AS IS" with no warranties, and confers no rights

Hi,

Since there are no body in this newsgroup respond to my previous
posting, Can any body suggest the correct newsgroup to post it ?

Best Regards,


Rudy

(e-mail address removed) (Rudy Hartono) wrote in message

Hmm,

Strange, try on WinXP and Win2003 server and everything works fine.

Can anybody from Microsoft respond on this ?

Best Regards,

Rudy

(e-mail address removed) (Rudy Hartono) wrote in message

Hi,

I have a problem with a Win2k Certificate Chain validation. (Try using
Win2K SP2 and Win2K SP4)

I have 3 certificates:
1. Root CA Certificate
2. Intermediate CA Certificate
3. End User Certificate

I put Root CA Certificate to Trusted Root Certification Authorities
Current User Store and Intermediate CA Certificate to Intermediate
Certification Authorities Current User Store and End User Certificate
to Personal (My) Current User Store.

When I view the Root CA Certificate, the Certificate Viewer said the
Certificate is valid. It is the same when I view Intermediate CA
Certificate.
But when I view End User Certificate, it said "Windows does not have
enough information to verify this certificate" and on Certification
Path tab the status is "The issuer of this certificate could not be
found".

Check Root CA Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 01
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c
f0 6a
No key provider information
No stored keyset property
Certificate is valid

Check Intermediate CA Certificate using certutil.exe and here is the
result:
================ Certificate 0 ================
Serial Number: 06
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Certificate Template: SubCA
Non-root Certificate
Cert Hash(sha1): b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95
8b fb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

CertContext[0][1]: dwInfoStatus=c dwErrorStatus=0
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Serial: 01
f7 62 df 4e e3 b4 69 24 a2 f8 7a b9 27 8e 64 8d 88 0c f0 6a
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)

Exclude leaf cert:
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
Full chain:
01 d7 91 7e 65 13 4b 1a 6d 2d f9 e5 2c 29 29 d3 56 bc 05 dd
Issuer: [email protected], [email protected], OU=Development,
O=CE-Infosys, C=SG
Subject: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Serial: 06
Template: SubCA
b3 d6 d0 e1 30 31 8a 7b d3 05 6b 1f 50 70 b7 11 dc 95 8b fb
The revocation function was unable to check revocation for the
certificate. 0x80092012 (-2146885614)
------------------------------------
Revocation check skipped -- no revocation information available
Certificate is valid


Check End User Certificate using certutil.exe and here is the result:
================ Certificate 0 ================
Serial Number: 12
Issuer: [email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Non-root Certificate
Cert Hash(sha1): af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12
e8 cb
No key provider information
No stored keyset property
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN
(0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=1 dwErrorStatus=40
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
Missing Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Issuer: [email protected],
[email protected], OU=Development, O=CE-Infosys, C=SG
Subject: [email protected], CN=User_D1, OU=Development,
O=CE-Infosys, C=SG
Serial: 12
af 71 a8 13 8d ea 3d 38 c4 f6 c2 b3 6f 3f c8 28 1f 12 e8 cb
An internal certificate chaining error has occurred. 0x800b010a
(-2146762486)
------------------------------------
Incomplete certificate chain
Cannot find certificate:
[email protected], [email protected],
OU=Development, O=CE-Infosys, C=SG

Do anybody know what is going wrong ?
Is there any bugs reported by Microsoft about this problem (Have been
searching at microsoft web site since yesterday but cannot found
anything) ?

Thanks in advance.

Best Regards,


Rudy

 

[Rudy Hartono]

Hi Visal,

Thanks for your reply.

I did found a mistake on my side on the end user certificate, where
the not after validity date is outside the not after validity date of
the intermediate ca certificate. By using the command line that you
gave me, I found this.

After fixing above problem, I still found the same problem.

Here is the result from certutil -verify enduser.cer subca.cer on
Win2003:
CertIssuer:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
CertSubject:
[email protected]
CN=User_D1
OU=Development
O=CE-Infosys
C=SG
Issuing CA CertIssuer:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Issuing CA CertSubject:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Issuing CA is not a root: Subject name does not match Issuer

Issuing CA Subject name matches Cert Issuer
Certificate signature is valid
Certificate is current
CA Key Id matches Key Id

ERROR: CA Issuer name does not match Key Authority name (8007000d)
Issuer serial number matches Key Authority
Issuer Name:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
KeyAuthority Name:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG

KeyId:
0000 a6 a9 a2 92 f8 ba f1 13 78 7d 10 e3 8d 49 fe a4
.........x}...I..
0010 c1 3b 93 58 .;.X

Key Authority SerialNumber: 06

CA Serial Number: 06
Certificate has no revocation-check extension

user_d1(1).der does NOT verify as issued by
(e-mail address removed) -- Revocation check skipped.
CertUtil: -verify command FAILED: 0x8007000d (WIN32: 13)
CertUtil: The data is invalid.
***************************************************************

The result from certutil -verify subca.cer rootca.cer on Win2003:
CertIssuer:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
CertSubject:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Issuing CA CertIssuer:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Issuing CA CertSubject:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Issuing CA Subject name matches Cert Issuer
Cert is a CA certificate
Certificate signature is valid
Certificate is current
CA Key Id matches Key Id
CA Issuer name matches Key Authority name
Issuer serial number matches Key Authority
Certificate has no revocation-check extension

(e-mail address removed) verifies as issued by
(e-mail address removed) -- Revocation check skipped.
CertUtil: -verify command completed successfully.
***************************************************************

From the result above, I can see that certutil failed to verify
the issuer "CA Issuer name does not match Key Authority name".
But I have check it and it is exactly the same
(not only in string, but the DER also).

End user certificate:
-----BEGIN CERTIFICATE-----
MIIEnDCCA4SgAwIBAgIBFDANBgkqhkiG9w0BAQQFADCBijELMAkGA1UEBhMCU0cx
EzARBgNVBAoTCkNFLUluZm9zeXMxFDASBgNVBAsTC0RldmVsb3BtZW50MSQwIgYD
VQQDExtjYV9kZWNlbnRyYWxAY2UtaW5mb3N5cy5jb20xKjAoBgkqhkiG9w0BCQEW
G2NhX2RlY2VudHJhbEBjZS1pbmZvc3lzLmNvbTAeFw0wMzExMTMxNjAwMDBaFw0w
NDExMTAxNTU5NThaMHExCzAJBgNVBAYTAlNHMRMwEQYDVQQKEwpDRS1JbmZvc3lz
MRQwEgYDVQQLEwtEZXZlbG9wbWVudDEQMA4GA1UEAxMHVXNlcl9EMTElMCMGCSqG
SIb3DQEJARYWdXNlcl9kMUBjZS1pbmZvc3lzLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA0Hz3LM52gbAzy9llaQCn9y2fVPRECpF9vjAAX7WYCzsiwtXs
iO8d8HkumTI7uczPDxm9aFiqKFMJmmZZW+BCY15KIjZrPhpSn4XGe38EChexw295
W0balklQ4BsdqJJD4qC5f8xSVqi5+gHH0nkInw2Yst2sxQfoKX+0VhHIqOsCAwEA
AaOCAacwggGjMIG3BgNVHSMEga8wgayAFKapopL4uvETeH0Q441J/qTBO5NYoYGQ
pIGNMIGKMQswCQYDVQQGEwJTRzETMBEGA1UEChMKQ0UtSW5mb3N5czEUMBIGA1UE
CxMLRGV2ZWxvcG1lbnQxJDAiBgNVBAMTG2NhX2RlY2VudHJhbEBjZS1pbmZvc3lz
LmNvbTEqMCgGCSqGSIb3DQEJARYbY2FfZGVjZW50cmFsQGNlLWluZm9zeXMuY29t
ggEGMB0GA1UdDgQWBBRVpZnl3SNZo6XV3vbEp35J8AacrDALBgNVHQ8EBAMCBSAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYKKwYB
BAGCNxQCA6AYDBZ1c2VyX2QxQGNlLWluZm9zeXMuY29tgRZ1c2VyX2QxQGNlLWlu
Zm9zeXMuY29tMCYGA1UdEgQfMB2BG2NhX2RlY2VudHJhbEBjZS1pbmZvc3lzLmNv
bTApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUAcwBlAHIwDQYJ
KoZIhvcNAQEEBQADggEBAGBqLeJPro/j3nFkAjZhMLrcS0wlWffd2edeiJV476Zz
gYZk4Drt/yaGovZwgUk/o2OI5KsI+1SffPA9g0W61tHPEb+h7WEsTh2FPtcz4fFs
KFb2MqZ7xyyDSuSA3MRstQDLCLJ8VrefW3PKgtqW6NjeHesOgc4puchkIbewV9BX
UQhzIt3uQAuCc6vv44dgUSO9DKbB5CE85kqLxDDLEqgsv6n7Xo03D+5mPCyCPt2A
WuRGxVjhHqbaBJbINJQXjJH0SrKx/ibqvWzZ5fcmKrBBuGu8oZmQuj7sVtouezUq
Tl9wCxe/fWXLb/j3yCT2kD4RZOqVn77HLDKOvL29gvs=
-----END CERTIFICATE-----

Intermediate CA certificate:
-----BEGIN CERTIFICATE-----
MIIEmzCCA4OgAwIBAgIBBjANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJTRzET
MBEGA1UEChMKQ0UtSW5mb3N5czEUMBIGA1UECxMLRGV2ZWxvcG1lbnQxGjAYBgNV
BAMTEWNhQGNlLWluZm9zeXMuY29tMSAwHgYJKoZIhvcNAQkBFhFjYUBjZS1pbmZv
c3lzLmNvbTAeFw0wMzExMTAxNjAwMDBaFw0wNDExMTAxNTU5NTlaMIGKMQswCQYD
VQQGEwJTRzETMBEGA1UEChMKQ0UtSW5mb3N5czEUMBIGA1UECxMLRGV2ZWxvcG1l
bnQxJDAiBgNVBAMTG2NhX2RlY2VudHJhbEBjZS1pbmZvc3lzLmNvbTEqMCgGCSqG
SIb3DQEJARYbY2FfZGVjZW50cmFsQGNlLWluZm9zeXMuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0/ScAlAL1RmhteV7QTDZH/1bCKe2ivChxKd6
3or4xAhaGwXQ1puc+Fz1E2HMcrjbdcCq6IVHvbDAlVzelN7E+hnvkGXD3DywlXAH
zIFJmta6M+twwZdZXpDXoAU1hUFrjE44lop1WO9CLdN27FYCdqjK69ReCV3bIfzB
3/fYYL5WQzwkgDDctQqWri1OdQXI9H1njlf8EvG5Jg4Z+Vwy3O4HRXnd7u0gSVf0
Jp9Rlvz9zNy4/eTLhLa/SkLsSN0c8NNgK+PFhtf731QkSo8+Pp9W5fmXfXoVcjDZ
YIK1+99/7DD1o1vxSDxZrIMaOYNTH+/qpvM2e+qYVrgyrAofpQIDAQABo4IBHTCC
ARkwgaAGA1UdIwSBmDCBlYAUngHAkEnie/HejjJxh5F9bvDzyXCheqR4MHYxCzAJ
BgNVBAYTAlNHMRMwEQYDVQQKEwpDRS1JbmZvc3lzMRQwEgYDVQQLEwtEZXZlbG9w
bWVudDEaMBgGA1UEAxMRY2FAY2UtaW5mb3N5cy5jb20xIDAeBgkqhkiG9w0BCQEW
EWNhQGNlLWluZm9zeXMuY29tggEBMB0GA1UdDgQWBBSmqaKS+LrxE3h9EOONSf6k
wTuTWDALBgNVHQ8EBAMCAgQwHAYDVR0SBBUwE4ERY2FAY2UtaW5mb3N5cy5jb20w
DwYDVR0TAQH/BAUwAwEB/zAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkq
hkiG9w0BAQQFAAOCAQEAmq0bgCfRke0yWXU6lnRM736y6x8YVu9I6/EN8Yrigs5/
gaZGPGPWkY41VKhBHMJf4253lr2v9kzke7Ha7024CGT8Z18D/6ZarIc3b57pUwxj
QIEIi41jCn90KBK3BGcF7prIWB0Df1excCdOrbs1FTJA37lMOYfSRq6Ki/8vJAzj
LPFfGEuvx2XT/NoUKWthgU8HApXY71uj9Goj7VJEHRVPtqRjD9keZGQrEmr1sfau
eMlemtt/faUIfSyQVgJjCpe9CQQm5eQMNeX5cw9weCRfKTuGepoNIkSzeUWhSuuJ
g99zO7i39TnnGmZ2um4YthO4aGfja4m8NhIRD17Naw==
-----END CERTIFICATE-----

Root CA Certificate:
-----BEGIN CERTIFICATE-----
MIIDxDCCAqygAwIBAgIBATANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJTRzET
MBEGA1UEChMKQ0UtSW5mb3N5czEUMBIGA1UECxMLRGV2ZWxvcG1lbnQxGjAYBgNV
BAMTEWNhQGNlLWluZm9zeXMuY29tMSAwHgYJKoZIhvcNAQkBFhFjYUBjZS1pbmZv
c3lzLmNvbTAeFw0wMzEwMTkxNjAwMDBaFw0xMzEwMTkxNTU5NTlaMHYxCzAJBgNV
BAYTAlNHMRMwEQYDVQQKEwpDRS1JbmZvc3lzMRQwEgYDVQQLEwtEZXZlbG9wbWVu
dDEaMBgGA1UEAxMRY2FAY2UtaW5mb3N5cy5jb20xIDAeBgkqhkiG9w0BCQEWEWNh
QGNlLWluZm9zeXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2L8G9qOH67M/i6viZ8K1k+2DhhpcCrKDVj68iYXTWL3asRULgBZ3G6T5kFqAEf61
PTCCM7yui+Lb0YFYBcuYC3USSh6JWa/sSjr8oHnsChNjZj3P66flsCxq9I5djP4K
T30sr904oVse53BAPqpy+1fTfsXZd9v44vcupz9bBS0Zw3FmGV93twlDp8sP2wrX
XnmvsqOi0vhFoIgYMMx13Q/pcE58JreiSS3U6iWc3PikvW2H1pwrgl2QsbRxBgEE
C/7pisGD+h/fU5Wq+341ZJcLuVuu4h11/j/1wA0vKQu41Y1Ngw4SZnLhOc4NbA1I
NXbkKrIINjDuHRPhYfuR1wIDAQABo10wWzAdBgNVHQ4EFgQUngHAkEnie/HejjJx
h5F9bvDzyXAwCwYDVR0PBAQDAgIEMBwGA1UdEgQVMBOBEWNhQGNlLWluZm9zeXMu
Y29tMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADggEBALXRAwUH29Ct
2gXjSMXDSFHSoXRQsC8AkDWBWPWgNy60G+FzRuXrCmLYAtKaj2zuC1VaYeWxLjzW
rXJOoBfv1NsADy6q27xZF3L4j2PKpm4vXJcxayaLX+ZGnoFC6AUd5RgOEcr/AiuF
zoynFU+x+D9dc3dNi3PdYp47Dn5QbZW806o20JMMY8vWXzm9jhJa2UsRdhqSXy7C
e/S+kLxqC0qVpj8FtkgRDZG4CRAI5pAboDUc7AhPibx093rg4QkfWcaUS17wv8m6
0aoVos/oVwlhEA97i/8CG/nAo8Vw7JbIeKw+pSrT/EzHj3524UehWCu5QfBYzIaE
IFMgkySmHnM=
-----END CERTIFICATE-----

FYI, the Win2k SP4 still said that the end user certificate is
invalid and on Win2003 is valid.

Best Regards,


Rudy

 

[Vishal Agarwal[MSFT]]

Your end-entity certificate has incorrect AKI extension.

The AKI extension is:
Authority Key Identifier
KeyID=a6 a9 a2 92 f8 ba f1 13 78 7d 10 e3 8d 49 fe a4 c1 3b 93 58
Certificate Issuer:
Directory Address:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG
Certificate SerialNumber=06

The CertificateIssuer part is incorrect. In AKI extension, the
CertificateIssuer represents the Issuer of the Signing Certificate (in your
case that would be Root Certificate).
The CeritifcateIssuer in this extension should have been:
[email protected]
[email protected]
OU=Development
O=CE-Infosys
C=SG

In Win2003, the certificate is not showing any problem as its smart to use
KeyId for chaining instead of CertificateIssuerName.
In Win2KSP4, the chaining engine is not smart enough to use KeyId.

Hope it makes sense.

Thanks,
Vishal[MSFT]

 

[Rudy Hartono]

Hi Visal,

I believe this is a mistake from Microsoft.

If we refer to RFC 3280

4.2.1.1 Authority Key Identifier

The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs
or
due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or on the issuer name and serial number.

Can you try to explain to me why Microsoft would refer the issuer
as a Root CA instead of the direct issuer (in this case the sub ca)
???

If we take a look above, it said:
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate.

By this I believe the Authority key identifier shall came from the
authority which sign the certificate (i.e. sub ca certificate not
root ca certificate)

If lets say microsoft expect root CA DN on the AKI, why it behave
differently between Win2K SP4, WinXP SP1, and Win2003 ?

It would be very hard for us to support Microsoft in this case since
there is a different behaviour between its own product.

And just for your information, after googling for several hours, I
found this:

http://groups.google.com.sg/groups?...%248k4%241%40FreeBSD.csie.NCTU.edu.tw&rnum=11

Hope it will open Microsoft's developer eyes......

Best regards,

Rudy

 

[Rudy Hartono]

Hi Visal,

Another question for Microsoft:

From the RFC 3280, the AuthorityKeyIdentifier is:

AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL
}

If Microsoft expect a root CA Certificate on the authorityCertIssuer
and authorityCertSerialNumber, how Microsoft can find a Issuer
certificate if I do not include keyIdentifier (since it is optional) ?

Best Regards,


Rudy

 

[Vishal Agarwal[MSFT]]

The quoted phrase from the RFC is "... the issuer name and serial number."

This phrase leaves out useful information to answer the question "of what
certificate?"

There are multiple possible interpretations.

1) A nonsensical interpretation is that this means "the issuer name and
serial number of the subject certificate". This would be completely
redundant data (subject certificate information only), and is of no help to
identify the signing certificate's public key, which is the intent of the
RFC.

2) Our interpretation is that this means "the issuer name and serial number
of the certificate used to sign the subject certificate"

3) A third interpretation is that this means "the issuer name of the subject
certificate and the serial number of the certificate used to sign the
subject certificate"

The most useful interpretation of the RFC is that when the Issuer and Serial
Number fields of the Authority Key Identifier extension are populated, the
two fields should be the Issuer and Serial Number of the signing (parent) CA
certificate. They could also be described as the Issuer certificate's Issuer
Name and Serial Number. This relatively unique combination is useful to find
the issuing CA certificate, which is the purpose of the AKI extension.

The alternate RFC interpretation of setting these two fields to the Issuer
Name of the certificate *containing* the AKI extension and the Serial Number
of the issuing CA certificate is the same as saying the AKI extension should
contain the issuing CA certificate's *Subject* Name and Serial Number. Since
there is no correlation or expectation of uniqueness between an issued
certificate's Subject Name and Serial Number expressed in the RFCs, this
interpretation would not necessarily lead to identifying a unique
certificate. It is rather common for non-Microsoft CAs to issue certificates
with Serial Numbers like "01", "02", .... If multiple CAs are installed, and
machines or users enroll for certificates from both CAs, it is quite
conceivable that certificates with the same Subject Name and Serial Number
may be issued. If the two CAs are at all well-behaved, the two CA Subject
Names should not match, so it would be reasonable to expect that there will
not be two certificates issued with the same Issuer Name and Serial Number.

Microsoft products have been consistent in relying on the second
interpretation for both the server use and the client interpretation of the
AKI extension's Issuer Name and Serial Number fields.

You can also refer to Book "Planning for PKI" by Russ Housley and Tim Polk
and refer to Page 88 about how Authority Key Identifier extension is
interpreted (same as our interpretation).

It would be quite reasonable for you to request an interpretation of the RFC
text from the RFC authors or owners, in order to support or refute our
interpretation. I would be interested in their opinions.

The chain building logic in older Microsoft clients (Windows NT4 and Windows
2000 SP4 and older) apparently wasn't smart enough to fall back to using the
AKI extension's KeyId field when the Issuer Name and Serial Number fields
are populated with inconsistent data. The chain building logic in Windows
2000 SP5, Windows XP and Windows 2003 Server should overcome this limitation
because it is significantly more robust. Presumably, this is the cause of
the differing behavior identified below. Note that the behavior in regard to
the interpretation of the Issuer Name and Serial Number does not differ
between products, it is only the fallback client behavior that differs,
exposed only when the AKI extension contains what our client interprets as
incorrect data.



Thanks,

Vishal[MSFT]


--
This posting is provided "AS IS" with no warranties, and confers no rights

Hi Visal,

Another question for Microsoft:

From the RFC 3280, the AuthorityKeyIdentifier is:

AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL
}

If Microsoft expect a root CA Certificate on the authorityCertIssuer
and authorityCertSerialNumber, how Microsoft can find a Issuer
certificate if I do not include keyIdentifier (since it is optional) ?

Best Regards,


Rudy


(e-mail address removed) (Rudy Hartono) wrote in message

Hi Visal,

I believe this is a mistake from Microsoft.

If we refer to RFC 3280

4.2.1.1 Authority Key Identifier

The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs
or
due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or on the issuer name and serial number.

Can you try to explain to me why Microsoft would refer the issuer
as a Root CA instead of the direct issuer (in this case the sub ca)
???

If we take a look above, it said:
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate.

By this I believe the Authority key identifier shall came from the
authority which sign the certificate (i.e. sub ca certificate not
root ca certificate)

If lets say microsoft expect root CA DN on the AKI, why it behave
differently between Win2K SP4, WinXP SP1, and Win2003 ?

It would be very hard for us to support Microsoft in this case since
there is a different behaviour between its own product.

And just for your information, after googling for several hours, I
found this:

http://groups.google.com.sg/groups?...%248k4%241%40FreeBSD.csie.NCTU.edu.tw&rnum=11

Hope it will open Microsoft's developer eyes......

Best regards,

Rudy

 

[Rudy Hartono]

Hi Visal,

1) A nonsensical interpretation is that this means "the issuer name and
serial number of the subject certificate". This would be completely
redundant data (subject certificate information only), and is of no help to
identify the signing certificate's public key, which is the intent of the
RFC.

I agree with you in this case.

2) Our interpretation is that this means "the issuer name and serial number
of the certificate used to sign the subject certificate"

This is the point. If we take a look again on my case:
1. Root CA sign Sub CA Certificate
2. Sub CA certificate sign end user Certificate

So on Sub CA Certificate, the AKI extension shall describe a property
of Root CA Certificate and on End User Certificate,
the AKI extension shall describe a property of Sub CA Certificate.
Am I right ?

3) A third interpretation is that this means "the issuer name of the subject
certificate and the serial number of the certificate used to sign the
subject certificate"

I also agree with you.

The most useful interpretation of the RFC is that when the Issuer and Serial
Number fields of the Authority Key Identifier extension are populated, the
two fields should be the Issuer and Serial Number of the signing (parent) CA
certificate. They could also be described as the Issuer certificate's Issuer
Name and Serial Number. This relatively unique combination is useful to find
the issuing CA certificate, which is the purpose of the AKI extension.

I belive here is the part where Microsoft get it wrong.

The alternate RFC interpretation of setting these two fields to the Issuer
Name of the certificate *containing* the AKI extension and the Serial Number
of the issuing CA certificate is the same as saying the AKI extension should
contain the issuing CA certificate's *Subject* Name and Serial Number. Since
there is no correlation or expectation of uniqueness between an issued
certificate's Subject Name and Serial Number expressed in the RFCs, this
interpretation would not necessarily lead to identifying a unique
certificate. It is rather common for non-Microsoft CAs to issue certificates
with Serial Numbers like "01", "02", .... If multiple CAs are installed, and
machines or users enroll for certificates from both CAs, it is quite
conceivable that certificates with the same Subject Name and Serial Number
may be issued. If the two CAs are at all well-behaved, the two CA Subject
Names should not match, so it would be reasonable to expect that there will
not be two certificates issued with the same Issuer Name and Serial Number.

I agree with you in this case.

Microsoft products have been consistent in relying on the second
interpretation for both the server use and the client interpretation of the
AKI extension's Issuer Name and Serial Number fields.

You can also refer to Book "Planning for PKI" by Russ Housley and Tim Polk
and refer to Page 88 about how Authority Key Identifier extension is
interpreted (same as our interpretation).

Here I quote from the Page 88 of the book:

The authority key identifier points to a public key that can be used
to verify the signature on particular certificate. The authority key
identifier MAY be the issuer name or serial number of a certificate
or a string.

If the authority key identifier extension contain an issuer name or
serial number pair, then the identified certificate contains the
public key.

Description of the picture found on page 88:

Issuer and serial number point to the certificate containing the
public
key needed to validate the certificate signature.

And now lets go back to my case:

1. Root CA Certificate is [email protected] .....
2. Sub CA Certificate is [email protected] ...
3. End User Certificate is [email protected] ...

Root CA Certificate sign Sub CA Certificate and Sub CA Certificate
sign End User Certificate.

So from the book that you refer to me:

On Sub CA Certificate AKI extension I shall put
- Subject Key Identifier of Root CA Certificate
- DN of Root CA Certificate which is (e-mail address removed)
- Serial number of Root CA Certificate

On End User Certificate AKI extension I shall put
- Subject Key Identifier of Sub CA Certificate
- DN of Sub CA Certificate which is (e-mail address removed)
- Serial Number of Sub CA Certificate

On End User Certificate AKI extension Microsoft style
- Subject Key Identifier of Sub CA Certificate
- DN of Root CA Certificate which is (e-mail address removed)
- Serial Number of Root CA Certificate

If we read one more time for the book you have refer to me:

If the authority key identifier extension contain an issuer name or
serial number pair, then the identified certificate contains the
public key.

Issuer and serial number point to the certificate containing the
public
key needed to validate the certificate signature.

Question:
On Microsoft style AKI, how can I found a public key needed to
validate
the certificate signature for End User Certificate if there a no Sub
CA
Subject Key Identifider included ???

Answer:
My certificate:
According to the book, I will try to find a Certificate that
contain a DN which is Sub CA DN and a serial number which is Sub
CA
serial number. Using this two criteria, I will find the
Certificate
which is Sub CA Certificate. And after that, extract the public
key from the Sub CA Certificate and try to validate the signature
on end user certificate. And hmmm I found the signature is valid
!!!

Microsoft style:
According to the book, Microsoft will try to find a Certificate
that
contain a DN which is Root CA DN and a serial number which is Root
CA
serial number. And ohhhh, Microsoft find the Certificate which is
Root
CA Certificate. And after that, extract the public key from the
Root
CA Certificate and try to validate the signature on end user
certificate. And ohhhh the signature is not valid !!!

I think my mail is long enough, and I would glad to get a reply from
you.

Best Regards,


Rudy

 

[Vishal Agarwal[MSFT]]

Please look at diagram (a) of the book I refered (on page 88) and please
verify the AKI value of the end certificate (Subject:Alice Adams).
IssuerName in AKI is HawkData and NOT FoxConsulting.
If this doesn't clear it up, please ask RFC owners to clear the
interpretation. I would be interested in their opinion.

Thanks,
Vishal[MSFT]

 

[Guest]

I have similar error when using a Smart Card certificate to logon using the Microsoft GINA. Using certutil -verify everything looks ok. Error is internal certificate chaining error. Any suggestion please.