OCSP service under IIS throws HTTP 500 error, Root Agency Cert bit length defaults to 512

This is only the third time in 25 years that I’ve done this so I’m no seasoned professional when it comes the RSA and PKI. I’ve started, backed up, and restarted four times and can’t get past one point in the process. I’m stuck at configuring the OCSP service under IIS.

The OCSP service can’t respond and it’s been difficult tracking down possible causes. After creating custom event views for the PKI components, I found event log warnings for:

CertificationAuthority Event ID: 93

The certificate (#0) of Active Directory Certificate Services My-Enterprise-CA does not exist in the certificate store at CN=NTAuthCertificates,CN=Public Key Services,CN=Services in the Active Directory's configuration container. The directory replication may not be completed.

CertificationAuthority Event ID: 103

Active Directory Certificate Services added the root certificate of certificate chain 0 to the downloaded Trusted Root Certification Authorities Enterprise store on the CA computer. This store will be updated from the Certification Authorities container in Active Directory the next time Group Policy is applied. To verify that the CA certificate is published correctly in Active Directory, run the following command: certutil -viewstore "ldap:///CN=My-Enterprise-CA,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=mydomain,DC=com?cACertificate?base?objectClass=certification Authority" (you must include the quotation marks when you run this command). If the root CA certificate is not present, use the Certificates console on the root CA computer to export the certificate to a file, and then run the following command to publish it to Active Directory: Certutil -dspublish %certificatefilename% Root.

The command suggested in the Event ID 103 Warning, fails with the message:

CertUtil: -viewstore command FAILED: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)

CertUtil: The system cannot find the file specified.

Further investigation of this led to discovering that the “Root Agency” certificate bit length was only 512, and the suggestion of recreating the certificate with a minimum of 1024 bits. But I want to confirm this before doing so to ensure there’s something I haven’t missed in coming to this conclusion. There may in fact be more than one cause here.

The PKI "CAPolicy.inf" file I setup calls for a bit length of 4096, but there is nothing in that file to address the issue of a minimal bit length for RSA of 1024, and I have found nothing in my reading that suggested this as well. Why it defaults to 512 bits I can’t say, I have assumed since Windows requires a minimum bit length of 1024, that this would have been the default OOBE for AD CA services. The fact that I have started, backed up and restarted four times, may have introduced elements affecting the current outcome, so where to go from here eludes me.

More Background:

I’m installing and configuring a Windows Certificate PKI for my development and learning domain. My approach has been as follows:

1. Setup a non-domain joined, offline Windows 2019 Server as the Root-CA, hardened to prevent access from non-administrative types. This machine issues the Root-CA and the Subordinate Enterprise-CA hosted on another domain joined server.
2. Setup an Enterprise-CA on a domain joined Windows 2019 Server to host the Enterprise-CA and the PKI for my local domain.
3. On the Enterprise-CA install the Certificate Authority, Certificate Authority Web Enrollment, Online Responder, and IIS services.
4. At the point where I launch the Certificate Authority snap in and configure the location for the OCSP responder using a URL such as http://ocsp.corp.mydomain.com/ocsp it fails, I have confirmed DNS settings are correct and functional. Yet, IIS returns a 500 error.
5. Investigating that, led to an error message about not being able to locate a CRL, and that led to the error of the Root Agency certificate bit length being less than 1024. I’m hoping the fix is as simple as re-issuing a Root Agency certificate with bit length of 2048, but when it comes to PKI, nothing so far has been simple, so I want to run these issues by some experts who can help me keep from blowing up my lab environment any further.

Thanks,