{"id":449,"date":"2018-11-04T21:14:08","date_gmt":"2018-11-05T03:14:08","guid":{"rendered":"http:\/\/zewwy.ca\/?p=449"},"modified":"2019-08-19T20:00:22","modified_gmt":"2019-08-20T01:00:22","slug":"resolving-a-down-ca","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2018\/11\/04\/resolving-a-down-ca\/","title":{"rendered":"Resolving a down CA"},"content":{"rendered":"

<\/span>Downed CA!<\/span><\/h1>\n

First off I wanted to address that this wasn’t the intended post of today, this was suppose to be part 2 of the Global Protect post, which is the second dependency; Certificates. However I recently had to get a new cert at work, and discovered this same issue as I had deployed my CA following a decent blog tutorial online by StealthPuppy, and sure enough the same sight provides a follow up on how to fix a mistake made, we all make them and these are great opportunities to learn, so lets get learning!<\/p>\n

So you might happen to open up the Certificate Authority Snap and point it to your CA server, to find this…. it’s shutdown….<\/p>\n

\"\"<\/a>Fear not StealthPuppy has given us some helpful tips<\/a> to resolve this!<\/p>\n

<\/span>The Issue<\/span><\/h2>\n

You might find your certificate authority, in this case, a subordinate certificate authority that is not started, perhaps after a server reboot. Attempting to start the CA, results in this message:<\/p>\n

The revocation function was unable to check revocation because the revocation server was offline.
\n0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)<\/p><\/blockquote>\n

Which looks like this:<\/p>\n

\"\"<\/a><\/p>\n

In the Application log on the subordinate CA, I can see event id 100 from source CertificationAuthority:<\/p>\n

Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. stealthpuppy Issuing CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).<\/p><\/blockquote>\n

As well as, event id 48 from the same source, CertificationAuthority:<\/p>\n

Revocation status for a certificate in the chain for CA certificate 0 for stealthpuppy Issuing CA could not be verified because a server is currently unavailable. The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).<\/p><\/blockquote>\n

Certificate 0 is the subordinate CA\u2019s certificate, issued by the offline Root CA.<\/p>\n

I bypassed this portion of the blog as I didn’t want to have pictures of before the next required step soooo….<\/p>\n

<\/span>The Workaround<\/span><\/h2>\n

Of course, you probably want to get the CA up and running as quickly as possible. The easy way to do that is to disable CRL checking with the following command on the CA server:<\/p>\n

\n
\n
\n
\n
certutil \u2013setreg ca\\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE<\/pre>\n<\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n<\/div>\n<\/div>\n
Run this from an elevated command prompt and you should now be able to start the CA and get on with the business of troubleshooting.<\/p>\n
\"\"<\/a><\/p>\n
Perfect, now lets fix this!<\/p>\n
<\/span>The Cause<\/span><\/h2>\n
My CRL was online as it is available in Active Directory (for domain joined machines) and via HTTP at subca.zewwy.ca, an alias of the subordinate CA. I\u2019ve tested that I can retrieve the CRL by putting the HTTP path into a browser and I\u2019m prompted to download a file.<\/p>\n
\n
\n
\n
<\/div>\n<\/div>\n<\/div>\n
\n
\"\"<\/a><\/div>\n
<\/div>\n<\/div>\n<\/div>\n
Through having spent some time recently with setting up an Enterprise PKI in my lab and for a project, I\u2019ve come to know the command line tool certutil.exe<\/a>. This tool is available in all versions of Windows and should be the first tool to use to troubleshoot and manage certificates and certificate authorities on Windows.<\/p>\n
Certutil can be used to perform many functions, one of which is to verify a CRL. I know the path to the CRL file because I can view the CRLs on the file system (in C:\\Windows\\System32\\certsrv\\CertEnroll) and I\u2019ve previously configured CRLs for both CAs<\/a>.<\/p>\n
To verify the CRL, use the -URL switch with the HTTP (or LDAP) path to the CRL:<\/p>\n
\n
\n
\n
\n
certutil -URL \"http:\/\/subca.zewwy.ca\/CertEnroll\/OFFLINE-ROOT-CA.crl\"<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
This will display the URL Retrieval Tool<\/strong> that shows that the CRLs are able to be contacted and show a status of OK.<\/p>\n
\"\"<\/a><\/p>\n
*NOTE* I discovered this works directly on the Windows Core Server, if you happened to be running Core (I do as I love optimization, specially when you have to work in lab environments). Except as you might have noticed from the screenshot, the radio buttons are all messed (wonder what library handles that, that wasn’t in core…)<\/p>\n
However, if we load a target certificate, in this case, the subordinate CA\u2019s cert, we can start to see why we have an issue with the CRL.<\/p>\n
Select the certificate for the subordinate CA that has been previously exported to the file system (in C:\\Windows\\System32\\certsrv\\CertEnroll) \u2013 click Select, open the certificate and click Retrieve again. This time, we can see a new line that shows that the base CRL for the subordinate CA\u2019s certificate is Expired. (Unfortunetly I had to simply use his source images as in my case I had to also correct my CDP locations on my sign Sub CA Certificate as I had mentioned in my initial Setup Offline Root CA blog post, but I guess I didn’t do it in my lab, so I sort of had to fix to birds with one stone, the CPD locations in my cert by reissuing that, and the offline root ca CRL file, so my additional steps were a bit beyond these exact steps, I also didn’t take snapshots as I wanted to get back on pace with my blog post)<\/p>\n
\"\"<\/a><\/p>\n
The CRL for the subordinate CA\u2019s certificate will come from the root CA, so we\u2019ll need to check that CRL. Open the CRL file (C:\\windows\\system32\\certsrv\\CertEnroll\\stealthpuppy Offline Root CA.crl<\/em>) \u2013 double-click or right-click and Open<\/strong>. Here we can see the CRL information, including the next publishing time (Next CRL Publish).<\/p>\n
\n
\"\"<\/a><\/p>\n<\/div>\n
At the time of troubleshooting, this date was in the past and because the Root CA is offline and the CRL is hosted on a different server (the subordinate CA), this particular CRL will never receive an update. So, when the subordinate CA has rebooted, it has checked the Root CA\u2019s CRL and found it expired. Hence the certification authority service won\u2019t start.<\/p>\n
<\/span>How To Fix It<\/span><\/h2>\n
Now we know why the certification authority service won\u2019t start and an understanding of why the CRL is offline, even if the wording doesn\u2019t match the symptoms. If the error message had told me the CRL had expired instead of being offline, I might have saved some troubleshooting time. We now know that we need to re-publish the CRL from the Root CA.<\/p>\n
Start the offline Root CA, log into it and open the Certification Authority<\/strong> console. We will first want to ensure that the CRL publication interval is extended so that we don\u2019t run into the same problem in the near future. Open the properties of the Revoked Certificates<\/strong> node to view and set the publication interval. The default interval is 1 week, obviously too often for an offline Root CA.<\/p>\n
Instead, set this value to something suitable for the environment you have installed the CA into. Remember that you\u2019ll need to boot the Root CA and publish a new CRL before the end of this interval, otherwise, you\u2019ll have exactly the same issue.<\/p>\n
\n
\n<\/div>\n
Now publish a new CRL \u2013 right-click the Revoked Certificates<\/strong> node and click All Tasks<\/strong> \/Publish<\/strong>.<\/p>\n
\n
\n<\/div>\n
Copy the updated CRL (from C:\\Windows\\System32\\certsrv\\CertEnroll<\/em> by default) from the Root CA to the CRL distribution point and overwrite the existing CRL file (C:\\Windows\\System32\\certsrv\\CertEnroll<\/em> again on my subordinate CA).<\/p>\n
Now if we again use certutil.exe to verify the CRL, it comes up roses:<\/p>\n
\n
\n<\/div>\n
To ensure that the subordinate CA\u2019s certification authority service will start, re-enable CRL checking:<\/p>\n
\n
\n
\n
\n
certutil \u2013setreg ca\\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE<\/pre>\n<\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n<\/div>\n<\/div>\n
If you have re-published the CRL from the Root CA correctly, the service should start and you can then shut down the Root CA. Then open Outlook and put a reminder in the calendar for a week before the CRL expires again.<\/p>\n
<\/span>Conclusion<\/span><\/h1>\n
I\u2019ve had this issue with an Offline CRL a few times now and not really understood what the issue is until I took the time to troubleshoot the issue properly. I don\u2019t spend that much time with an enterprise PKI and it\u2019s easy to underestimate the complexity of setting up AD Certificate Services correctly.<\/p>\n","protected":false},"excerpt":{"rendered":"
Downed CA! First off I wanted to address that this wasn’t the intended post of today, this was suppose to be part 2 of the Global Protect post, which is the second dependency; Certificates. However I recently had to get a new cert at work, and discovered this same issue as I had deployed my … <\/p>\n
Continue reading “Resolving a down CA”<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[4,8],"tags":[18,17],"class_list":["post-449","post","type-post","status-publish","format-standard","hentry","category-infosec","category-server-administration","tag-certificates","tag-pki"],"_links":{"self":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/449","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/comments?post=449"}],"version-history":[{"count":4,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/449\/revisions"}],"predecessor-version":[{"id":661,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/449\/revisions\/661"}],"wp:attachment":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/media?parent=449"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/categories?post=449"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/tags?post=449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}