Trouble with Document Signing Certs
- We've recently created a document signing template and implemented it on our PKI server (running Server 2008). Everything appears to be correct, but the certificates issued display a message when opened in Windows. "All the intended purposes of this certificate could not be verified." The Key Usage field is set for "Digital Signature" and the Enhanced Key Usage field is set for "Document Signing". I attempted to use the certificate to sign a document anyway, but received an error in Word stating that the signature could not be added to the document. I've run over all of my template settings and I can't come up with anything I'm missing. Any ideas?
Answers
- hThis is an easy one (not shown in the certutil -verify command though) as you are not testing for a specific policy OID.
Your CA is signed by the GTE Cybertrust Global Root CA.
If you look at the actual root CA certificate in the trusted root store, it is restricted to the following application policies (or EKUs)
Secure Email
Client Authentication
Server Authentication
Code Signing
You will never be able to issue a Document Signing certificate from a subordinate CA in this chain. You are limited to the four EKUs shown above.
When you attempt to use it, it fails, because Document Signing is not allowed by the root of the CA chain.
Brian- Marked As Answer byJoson ZhouMSFT, ModeratorFriday, November 06, 2009 6:17 AM
All Replies
Hi,
Please export the certificate to a .cer file, run certutil –verify against the .cer file, and then export the output here for further research.
Thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.There's the certutil output. Thank you.N:\>certutil -verify user_docsigning.cer Issuer: CN=PKISERVER DC=school DC=edu Subject: E=user@school.edu CN=LastName, FirstName OU=4325 OU=4300 OU=Users OU=FSA DC=University DC=school DC=edu Cert Serial Number: 173e7315000000000250 dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ChainContext.dwRevocationFreshnessTime: 61 Days, 22 Hours, 31 Minutes, 28 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwRevocationFreshnessTime: 61 Days, 22 Hours, 31 Minutes, 28 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=PKISERVER, DC=school, DC=edu NotBefore: 10/29/2009 8:44 AM NotAfter: 10/29/2010 8:44 AM Subject: E=user@school.edu, CN="LastName, FirstName", OU=4325, OU=4300, OU=Users, OU=FSA, DC=University, DC=school, DC=edu Serial: 173e7315000000000250 SubjectAltName: Other Name:Principal Name=user@University.school.edu, RFC822 Name=user@school.edu Template: New Document Signing 7a 94 af e3 4e 39 c6 6f 60 ee 68 2f 3e 22 23 aa 16 74 67 1c Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) CRL 219: Issuer: CN=PKISERVER, DC=school, DC=edu 92 27 75 fe 24 7e de 1a 3f 13 7f 70 3f 66 c8 cc 14 8e 45 ea Delta CRL 222: Issuer: CN=PKISERVER, DC=school, DC=edu 14 2e e0 7f b7 92 81 cf dd d9 c3 b8 02 ac 40 b5 6f 71 88 53 Application[0] = 1.3.6.1.4.1.311.10.3.12 Document Signing CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=0 Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US NotBefore: 7/8/2009 8:05 AM NotAfter: 7/8/2018 8:04 AM Subject: CN=PKISERVER, DC=school, DC=edu Serial: 07273ed9 b0 6f 9c 38 af 1a 2a d7 c5 db ee ab 32 0f 32 4d b5 46 90 27 Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) CRL 283: Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US 79 4b f4 ca 8b f2 d0 24 10 2e 0b e7 f8 1f 25 06 66 66 ab a1 Issuance[0] = 1.3.6.1.4.1.311.13.2.3 OS Version Issuance[1] = 1.3.6.1.4.1.311.2.1.14 Certificate Extensions CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US NotBefore: 8/12/1998 7:29 PM NotAfter: 8/13/2018 6:59 PM Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US Serial: 01a5 97 81 79 50 d8 1c 96 70 cc 34 d8 09 cf 79 44 31 36 7e f4 74 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) Exclude leaf cert: bd 59 09 09 59 0a 48 29 5c 67 31 64 e1 7c 9f 86 12 b0 a8 3a Full chain: 2e 8b 65 f4 b6 7f 67 8f 03 3a 4c d0 94 ac e7 34 73 c3 bd cb ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.4.1.311.10.3.12 Document Signing Leaf certificate revocation check passed CertUtil: -verify command completed successfully. N:\>- hThis is an easy one (not shown in the certutil -verify command though) as you are not testing for a specific policy OID.
Your CA is signed by the GTE Cybertrust Global Root CA.
If you look at the actual root CA certificate in the trusted root store, it is restricted to the following application policies (or EKUs)
Secure Email
Client Authentication
Server Authentication
Code Signing
You will never be able to issue a Document Signing certificate from a subordinate CA in this chain. You are limited to the four EKUs shown above.
When you attempt to use it, it fails, because Document Signing is not allowed by the root of the CA chain.
Brian- Marked As Answer byJoson ZhouMSFT, ModeratorFriday, November 06, 2009 6:17 AM
- Thank you Brian. Bummed that I missed that, but glad to know what the problem is.
