Sometimes (for example, during a changeover period) Certification Authority may have more than one valid CA certificate (and key pair, of course): new CA certificate is already issued and installed, but the old one has not yet expired. Normally after installation of a new CA certificate CA will issue only certificates signed by the new CA certificate. However, sometimes it is necessary to issue a certificate using old (but still valid) CA certificate. One example is OCSP signing certificates. This problem is documented, see, for example, section "Renewing OCSP Response Signing certificates" here: http://technet.microsoft.com/en-us/library/cc770413%28WS.10%29.aspx
To request from CA a certificate signed by specific CA certificate, CSR must contain Authority Key Identifier (AKI) extension matching Subject Key Identifier extension of CA certificate which should be used. By default, Windows 2008 CA will reject CSRs containing AKI extension, and will log message "An Authority Key Identifier was passed as part of the certificate request %1. This feature has not been enabled.". See here: http://technet.microsoft.com/en-us/library/cc774592%28WS.10%29.aspx
To enable CSRs with AKI, registry key "UseDefinedCACertInRequest" must be set to 1, then Windows 2008 CA will accept such CSRs.
If CA you are using is enterprise CA and is online, then Windows 2008 Online Responder (OCSP server component) should automatically renew OCSP signing certificates, and will take care about requesting it to be signed by correct CA certificate (at least that's how I understand it...). But if CA is standalone, then OCSP certificate must be renewed manually via creating CSR and submitting it to CA (for example, using certreq.exe utility).
Process of including AKI into CSR is terrifically underdocumented and includes direct manipulation of ASN.1 structures, but after some reading and experiments I think I was able to do that. However, I still can not issue needed certificate.
Here is what I did: created base-64 encoding of BER-encoding of ASN.1 structure containing AKI extension with value of Subject Key Identifier of CA certificate which should be used for signing. There are two methods how this extension can be put into certificate request: via certutil.exe or via certreq.exe.
Using certreq.exe, it is possible to put extension into policy .inf file used for generating CSR (see certreq.exe documentation):
.....
[Extensions]
2.5.29.35=<Base-64 encoded value of extension>
.....
Then this .inf file can be used to generate CSR via "certreq.exe -new", and the CSR can be submitted to CA (via "certreq.exe -submit" or some other way). ("2.5.29.35" is id-ce-authorityKeyIdentifier - OID of AKI extension).
Another way is to generate and submit to CA a CSR without AKI, and then set it via certutil on CA:
certutil.exe -setextension <Request ID> 2.5.29.35 0 @<File name with value of extension>
So far, so good: both methods seem to succed. CSR is submitted to CA, and when I do "View Attributes/Extensions", I can see that it really contains Authority Key Identifier which I expect and which matches Subject Key Identifier of old CA certificate. Problems start when I try to issue a certificate from this request.
If AKI was inserted into request using certreq.exe, then when I try to issue a certificate it silently moves from "Pending Requests" to "Failed Requests", and the following message is logged in Event Log:
"Active Directory Certificate Services denied request <request number> because The requested property value is empty. 0x80094004 (-2146877436). The request was for <Subject from CSR>. Additional information: Error Constructing or Publishing Certificate Resubmitted by <My user name>"
If AKI was set using certutil.exe, then certificate is issued, but it contains wrong AKI - it is equal to SKI of new CA certificate instead of old one. That is, it works like if I didn't try to set AKI at all.
Little bit lost here. Any ideas?