This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Why should the offline root and issuing certification authority use separate CAPolicy.inf files?
CAPolicy.inf
The files must be identical so that certificate extensions remain consistent.
Each role has different certificate policy, constraint, renewal, and publication requirements.
Empty authority information access and certificate revocation list sections on the subordinate control the certificate signed by the root.
What happens to existing certificates after an administrator corrects an authority information access address in CAPolicy.inf?
Existing certificates remain unchanged.
Certificate Services updates existing certificates after the next service restart.
Domain clients replace the address during the next policy refresh.
What should an operator do after certreq.exe -submit reports that a request was taken under submission?
certreq.exe -submit
Submit the request again until the certificate is issued automatically.
Restart Certificate Services, then copy the request directly to the issuing server.
Record the request identifier, inspect the request, approve it, then retrieve the certificate.
Why is EDITF_ATTRIBUTESUBJECTALTNAME2 a material certification authority setting?
EDITF_ATTRIBUTESUBJECTALTNAME2
It changes the certification authority key length during renewal.
It permits subject alternative names from request attributes across the certification authority.
It automatically publishes certificate revocation lists to web servers.
Why might a non-domain appliance reject a certificate even when the root certificate is published in Active Directory Domain Services?
Active Directory publication always blocks non-domain certificate validation.
The issuing certification authority must be configured as an enterprise root.
The appliance needs the root through its own operating system, application, or device trust mechanism.
What additional authorization layer should you verify when a certificate chains to a trusted root but certificate-based domain sign-in fails?
Enterprise authentication certification authority authorization, replication, certificate usage, mapping, validity, and revocation.
Only the local Trusted Root Certification Authorities store.
Only the web server MIME type for the root certificate.
What does configuring authority information access and certificate revocation list distribution point extensions not do?
Add retrieval addresses to newly issued certificates.
Copy certification authority certificates and revocation lists to the web publication location.
Define the locations that clients use for chain building and revocation checking.
When should the certification authority database and transaction logs use separate storage failure domains?
Whenever separate drive letters can be created on the same physical disk.
Only when the certification authority uses a hardware security module.
When measured performance, recovery, backup, or independent failure objectives justify the design.
What should operators do when Certificate Services repeatedly restarts while the hardware security module reports unavailable key storage?
Stop the restart loop, preserve evidence, recover the dependency, then verify the key and service.
Increase the number of automatic restart attempts indefinitely.
Disable hardware security module event logging.
When can an old issuing certification authority certificate be removed from enterprise authentication authorization after renewal?
Immediately after the replacement certificate is published.
After dependent certificates are replaced or expire and replication, clients, authentication, and rollback are validated.
Only after removing the trusted root certificate from every client.
You must answer all questions before checking your work.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?