Problem issuing subordinate CA cert from root CA - server 2008

[trmatthe]

Hi. I have a standalone root CA and an Enterprise subordinate. I've
run setup on the enterprise subordinate and generated a certificate
request. When I take this to the root and try to perform a Certificate
Request, I browse to the req file and am presented with a popup
saying:

Certificate Request Processor
The certification authority's certificate contains invalid data.
0x80094005. Denied by policy module.

I get an event ID 53, source CertificationAuthority in the app log for
this.

I'm not sure what I'm doing wrong here. I can't find anything on this
message. I do have EnhancedKeyUsage set to Microsoft Trust List
Signing on the root but I'm pretty confident that is correct for a
restricted root. Can anybody offer advice here?

I'm considering removing the EnhancedKeyUsage tomorrow and checking to
see if the subordinate cert is issued then.

All help much appreciated :)

[Martin Rublik]

Hi,

is it possible to send a dump of the request? E.g. certutil -dump request.req?

Regards

Martin

[Paul Adare]

There's nothing wrong with the request, the problem is that the root CA
cert can only be used for trust list signing which means it can't issue CA
certificates.

--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca

[trmatthe]

On Oct 29, 5:56 am, Paul Adare <pkad...@gmail.com> wrote:
> There's nothing wrong with the request, the problem is that the root CA
> cert can only be used for trust list signing which means it can't issue CA

Many thanks Paul and Martin,

I was a bit suspicious that I'd got the Enhanced Key Usage wrong so
I'll
take you through my thought process :)

Early on I thought that my root just needed KeyCertSign & CRLsign as
KeyUsage (from RFC 3280). However, I can't find any method of
manually
configuring Key Usage in CAPolicy.inf. So, I went with the above EKU
OID which I thought encompassed all I need. The generated certs in
fact
have a Key Usage of Digital Signature, Cert Sign,Offline CRL Sign,
CRL
Sign which seems pretty good. I'm left to infer that the Key Usage is
constructed from the EKU somehow?

Can you make any suggestions as to an appropriate EKU for a root
which is restricted to just issuing (subordinate -obviously) CA certs
and
signing CRLs? Or a method of specifying the bits in Key Usage?

thanks,
Tim

[trmatthe]

Well, I rebuilt the root and removed the EKU section then tried to
issue the cert based on the .req and it failed with the same error!

I have dumped the CSR below. Any clues? I did briefly wonder about the
path length constraint, but I understand 0 means no constraint.

thanks,
tim

PKCS10 Certificate Request:
Version: 1
Subject:
CN=MyCorp Issuing CA
O=MyCorp
C=XX
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
Algorithm Parameters:
05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
0000 30 82 01 0a 02 82 01 01 00 bc 52 30 5d d6 bf c1
[SNIP]
0100 3d ec db 2c f0 8e 0a d9 a9 02 03 01 00 01
Request Attributes: 3
3 attributes:
Attribute[0]: 1.3.6.1.4.1.311.13.2.3 (OS Version)
Value[0][0]:
6.0.6001.2.Service Pack 1
Attribute[1]: 1.3.6.1.4.1.311.2.1.14 (Certificate Extensions)
Value[1][0]:
Unknown Attribute type
Certificate Extensions: 3
2.5.29.19: Flags = 1(Critical), Length = 5
Basic Constraints
Subject Type=CA
Path Length Constraint=None
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
63 1d 50 38 55 14 39 20 82 5f 3c db e5 fe 09 95 48 58 36 ac
2.5.29.15: Flags = 0, Length = 4
Key Usage
Digital Signature, Certificate Signing, Off-line CRL Signing,
CRL Signing (86)
Attribute[2]: 1.2.840.113549.1.9.14 (Certificate Extensions)
Value[2][0]:
Unknown Attribute type
Certificate Extensions: 5
1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
CA Version
V0.0
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
63 1d 50 38 55 14 39 20 82 5f 3c db e5 fe 09 95 48 58 36 ac
1.3.6.1.4.1.311.20.2: Flags = 0, Length = c
Certificate Template Name (Certificate Type)
SubCA
2.5.29.15: Flags = 0, Length = 4
Key Usage
Digital Signature, Certificate Signing, Off-line CRL Signing,
CRL Signing (86)
2.5.29.19: Flags = 1(Critical), Length = 5
Basic Constraints
Subject Type=CA
Path Length Constraint=None
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Signature: UnusedBits=0
0000 14 72 93 f9 45 29 b3 26 ff 4b 86 a2 4a 7c 8a cd
[SNIP]
00f0 5d 3e 7a 0f b1 31 b2 55 61 de b6 31 49 21 7f 71
Signature matches Public Key
Key Id Hash(rfc-sha1): 63 1d 50 38 55 14 39 20 82 5f 3c db e5 fe 09 95
48 58 36 ac
Key Id Hash(sha1): fd 11 4c db 13 f5 36 20 19 f7 3c b2 a1 5a b1 fc c7
bc 9b c8
CertUtil: -dump command completed successfully.

[trmatthe]

Thanks for both of your help with this problem. I narrowed the fault
down to a typo in the CAPolicy.inf :( I had PathLength set to 0 when
it should have been 1.

For reference though, the OID I used (Trust List Signing) seems to
incorporate CA cert issuing as I have no problems using that EKU OID
on my root when issuing certs.

thanks
tim

[Stardust]

In your request below I see two "Certificate Extensions". Why is that?

"trmatthe" wrote:

> .
>

[Stardust]

<I sent another reply to this but it didn't show up - resending>

My question was why should the path length be 1? Doesn't path length 1 mean
that your SubCA can also issue certitificates that can sign EE certificates?
If your SubCA is an issuing CA and you don't want it to sign SubCA certs then
PathLength = 0 must have been correct. Why was pathlength = 0 an issue?

"trmatthe" wrote:

> .
>