• Check Point
  • FAQ on How CRL Check Mechanism on a Check Point Gateway Works

FAQ on How CRL Check Mechanism on a Check Point Gateway Works

Maxim Bilyukov compiled this FAQ about How the Certification Revocation List (CRL) check mechanism works on a Check Point gateway. Maxim Bilyukov is a Technical Solutions Architect at AKON Technologies and has been working with Check Point Firewalls for five years. Read more …

network monitoring

A Check Point gateway must check that the certificate it received from another entity for authentication purposes has not been revoked. This is achieved by using certificate revocation lists (CRLs). In case the certificate has been issued by the Internal Certificate Authority (ICA), CRL is managed by the security management server.

This FAQ covers the specifics of CRL check implementation on Check Point gateways.

Gateway receives a certificate from another peer during IKE phase 1 negotiation. How exactly is CRL check performed?

At the beginning, the gateway checks the “CRL Distribution Points” field of the certificate it received. Then the corresponding cache is checked in the following manner:

First, the gateway checks presence and validity of the local CRL cache (cache is stored per distribution point). If CRL is present and is not expired (i.e. valid), the gateway uses this cache to check the certificate’s validity. Otherwise, the Check Point firewall sends a request to the host(s) that are listed in the [policy] section of the $FWDIR/conf/masters files in order to get the latest version of CRL.

vpn debug excerpt while trying to establish VPN tunnel with valid local cache:

(For the sake of brevity, part of debug output has been omitted)

[vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwValidateRevocation_e: validating using crls [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwFetchCRL_e_With_Reason: fetching crl for certificate dn: CN=cp-gw-02 VPN Certificate,O=gaia-sms..9m8yyi [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] X509 Certificate Version 3 Serial Number: 17643 Issuer: O=gaia-sms..9m8yyi Subject: CN=cp-gw-02 VPN Certificate,O=gaia-sms..9m8yyi [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwCRLCache_GetFromCache: entered. [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwCRL_CRLisValid: [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] thisUpdate: Tue Mar 17 07:12:24 2015 Local Time [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] nextUpdate: Tue Mar 24 07:12:24 2015 Local Time [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] now:Tue Mar 17 16:35:32 2015 Local Time [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] crl start grace period=7200 crl end grace period=1800 crl size val=0 [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwCRLCache_Get: dp 'http://gaia-sms:18264/ICA_CRL3.crl' [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwCRL_validateRevocation: validate cert: [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] Subject: CN=cp-gw-02 VPN Certificate,O=gaia-sms..9m8yyi [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] with CRL: [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] Issuer: O=gaia-sms..9m8yyi This update: Tue Mar 17 07:12:24 2015 Local Time Next update: Tue Mar 24 07:12:24 2015 Local Time Extensions: Issuing distribution points (Critical): URI: http://gaia-sms:18264/ICA_CRL3.crl DN: CN=ICA_CRL3,O=gaia-sms..9m8yyi [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] fwCert_OurValCerts: validation OK [vpnd 13409 2012104384]@cp-gw-01[17 Mar 16:35:32] vpn1ValidateCertEvent::validateCertificates: Validating certs completed with status 0. (exchange 21)

vpn debug excerpt while trying to establish VPN tunnel without valid local cache:

(For the sake of brevity, part of debug output has been omitted)

[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:57] fwValidateRevocation_e: validating using crls [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:57] fwFetchCRL_e_With_Reason: fetching crl for certificate dn: CN=cp-gw-01 VPN Certificate,O=gaia-sms..9m8yyi [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:57] X509 Certificate Version 3 Serial Number: 80237 Issuer: O=gaia-sms..9m8yyi Subject: CN=cp-gw-01 VPN Certificate,O=gaia-sms..9m8yyi [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRLCache_GetFromCache: entered. [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRLCache_GetFromCache: <strong>no cache given</strong>. [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRLCache_Get: dp 'http://gaia-sms:18264/ICA_CRL3.crl' [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] <strong>fwCRLCache_Get: dp (http://gaia-sms:18264/ICA_CRL3.crl) was not found in memory cache.</strong> [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRLCache_Get_from_dp: dp (http://gaia-sms:18264/ICA_CRL3.crl) was not found in cache (memory). [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] <strong>fwCRLCache_Get: dp (CN=ICA_CRL3,O=gaia-sms..9m8yyi) was not found in memory cache.</strong> [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwFetchCRL_e_With_Reason: <strong>CRL was not found in cache. Will fetch it async. </strong> [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRL_convert_uri: original URI is "http://gaia-sms:18264/ICA_CRL3.crl"

How exactly does a gateway fetch the CRL from the ICA (Internal Certificate Authority)?

The gateway always fetches the CRL by the same method – HTTP GET request on TCP port 18264 (FW1_ica_services).

ICA stores multiple CRL files (for SIC certificates, for VPN certificates, etc.), files are numbered sequentially: ICA_CRL1, ICA_CRL2…

As mentioned before, the gateway determines what CRL file is needed in every situation by looking at the ‘CRL Distribution Points’ field of a certificate.

Which parameters have a CRL by default?

By default, a CRL that has been issued by the ICA is valid for one week.

A new CRL is issued upon expiration of approx. 60% of the lifetime of the current CRL (i.e. 4 days), or immediately after some certificate has been revoked.

A CRL which has been expired keeps being valid for another 30 minutes (CRL grace period).

How does a gateway determine what host it should reach in order to get a CRL?

When trying to fetch a CRL (for a certificate, issued by ICA) a gateway tries to reach all objects that are listed in the [policy] section of the $FWDIR/conf/masters file.

strace output for vpnd process while trying to fetch a CRL:

1752write(2, "[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58]
 <strong>resolver_gethostbyname: Performing gethostbyname for fake-sms</strong>n", 111) = 111 1752<strong>open("/etc/hosts", O_RDONLY)
</strong>= 36 1752read(36, "#This file was AUTOMATICALLY GENERATEDn#Generated by /bin/hosts_xlate on Mon Mar 16 15:31:05 2015n#
 n#DO NOT EDITn# n10.10.73.101 cp-gw-01n127.0.0.1 localhostn::1 localhostn", 4096) = 179 1752read(36, "", 4096)= 0 1752close(36) = 0
1752<strong>connect(36, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}</strong>, 28) = 0 1752<strong>send(36,
"21401110fake-sms</strong>341", 26, MSG_NOSIGNAL) = 26 1752write(8, "[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18]
<strong>resolver_gethostbyname6: getaddrinfo failed. reason=Name or service not knownn"</strong>, 127) = 127 1752write(8, "[vpnd 1752
1978582720]@cp-gw-01[18 Mar 10:10:18] <strong>get_ips_or_sicnames_from_list: Failed to get the obj of fake-
sms from objects.C</strong>n", 129) = 129

vpn debug while trying to fetch a CRL:

[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] fwCRL_convert_uri: original URI is "http://gaia-sms:18264/ICA_CRL3.crl" [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] RangesMap::RangesMap: called. <strong>obj=gaia-sms</strong>. resolve_only_clust_ifs=0 is_gateway=0 <strong>MainIP=4:<10.10.72.100></strong>, 6:<::> [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] RangesMap::RangesMap: called. <strong>obj=bogus-sms</strong>. resolve_only_clust_ifs=0 is_gateway=0 <strong>MainIP=4:<10.10.72.10></strong>, 6:<::> [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] fwCRL_convert_uri: URI was converted to "http://10.10.72.100:18264/ICA_CRL3.crl" [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] fwCRL_convert_uri: URI was converted to "http://10.10.72.10:18264/ICA_CRL3.crl" [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] fwCRL_Internal_Fetcher: <strong>fetching from URI: http://10.10.72.100:18264/ICA_CRL3.crl</strong> [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] Snatcher constructor [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] fwCRL_Internal_Fetcher:<strong> fetching from URI: http://10.10.72.10:18264/ICA_CRL3.crl</strong> [vpnd 5428 2012436160]@cp-gw-01[18 Mar 12:22:17] vpn1ValidateCertEvent::validateCertificates: Validating certs will be async. (exchange 2)

How does a gateway resolve object names from the $FWDIR/conf/masters file?

Upon its start, vpnd process reads the $FWDIR/database/objects.C file. This file contains the description of the objects in the management server database, including their IP address, NAT settings, etc.

strace output for vpnd process upon its start:

<strong>open("/opt/CPsuite-R77/fw1/database/objects.C", O_RDONLY) = 11</strong> brk(0xa5ed000)= 0xa5ed000 fstat64(11, {st_mode=S_IFREG|0660, st_size=1725808, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77f71000 read(11, "(nt:antispam_policy (ntt: (Global_Mail_Security_Policynttt:add_disclaimer (true)nttt:allow_mail_track (none)nttt:block_list_blocked_track (log)nttt:block_list_mode (on)nttt:customized_spam_server ()nttt:disclaimer_text ("Email secured by Check Point")nttt:email_size_scan (4096)nttt:ip_rep_mode (on)nttt:ip_rep_spam_actions (reject)nttt:ip_rep_spam_conf_level (90)nttt:ip_rep_spam_track (log)nttt:ip_rep_sus_spam_actions (reject)nttt:ip_rep_susspam_conf_level (80)nttt:ip_rep_susspam_track "..., 8192) = 8192

While attempting to resolve the object address from the $FWDIR/conf/masters file (e.g. while trying to fetch the CRL), vpnd uses the following sources: /etc/hosts file, DNS servers, and also the data that has been extracted from the objects.C file (the latter has the highest priority).

Data from the objects.C file is stored in the dynamic memory allocated by the system kernel to the vpnd process.

strace output for the vpnd process while trying to resolve the object’s IP address:

1752write(2, "[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:09:58] <strong>resolver_gethostbyname: Performing gethostbyname for fake-sms</strong>n", 111) = 111 1752<strong>open("/etc/hosts", O_RDONLY) </strong> = 36 1752read(36, "#This file was AUTOMATICALLY GENERATEDn#Generated by /bin/hosts_xlate on Mon Mar 16 15:31:05 2015n# n#DO NOT EDITn# n10.10.73.101 cp-gw-01n127.0.0.1 localhostn::1 localhostn", 4096) = 179 1752read(36, "", 4096)= 0 1752close(36) = 0 1752<strong>connect(36, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}</strong>, 28) = 0 1752 <strong> send(36, "21401110fake-sms</strong>341", 26, MSG_NOSIGNAL) = 26 1752write(8, "[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] <strong>resolver_gethostbyname6: getaddrinfo failed. reason=Name or service not knownn"</strong>, 127) = 127 1752write(8, "[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] <strong>get_ips_or_sicnames_from_list: Failed to get the obj of fake-sms from objects.C</strong>n", 129) = 129

How does the CLR cache mechanism (CRL Prefetch) work?

In order to decrease time for establishing a VPN tunnel (fetching a CRL could be rather slow process due to the large file size, which could lead to an IKE negotiation delay or even timeout), the gateway keeps a local copy of CRL.

Generally, when a local cache is present, a gateway tries to fetch a new CRL (from every host in $CPDIR/conf/masters file) every 2 hours. This parameter is configured via SmartDashboard menu Policy –> Global Properties –> SmartDashboard Customization –> Certificates and PKI properties –> prefetch_crls_duration.

Also the CRL cache is updated/flushed upon policy installation on a gateway. This behavior is configured on the same tab Policy –> Global Properties –> SmartDashboard Customization –> Certificates and PKI properties.

A CRL cache has limited lifetime – 24 hours by default (configured from Certificate Authority Properties window).

vpn debug excerpt while saving a CRL cache on a gateway:

(For the sake of brevity, part of debug output has been omitted)

[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRL_CRLisValid: [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] crl start grace period=7200 crl end grace period=1800 crl size val=0 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwFetchCRL_cb: Good CRL, successful fetch. [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: <strong>Put CRL (http://gaia-sms:18264/ICA_CRL3.crl) in the memory cache - timeout 86400,</strong> crl_to 86400 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: Put CRL in the FDB file till Thu Mar 19 10:10:18 2015 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] CrlDB::Key: buf= http://gaia-sms:18264/ICA_CRL3.crlinternal_ca [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] CrlDB::Key: key= 27c1ece094c15bfb48c78c960ecba984 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_new: name= /opt/CPsuite-R77/fw1/database//CrlCache version= 1 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_new: path= /opt/CPsuite-R77/fw1/database//CrlCache_1 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] FileDB_Locker::Lock: _opt_CPsuite-R77_fw1_database__CrlCache_1 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_store: save 517 bytes in '27c1ece094c15bfb48c78c960ecba984' [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRL_Hook_cb: first successful fetch. This fetch will be processed.

If a CRL cache has not been updated till its lifetime expiration, it will be deleted from a gateway.

If a CRL fetch has been successful (the gateway was able to get a CRL from one of the hosts, and hence updated its own cache) the CRL cache lifetime effectively resets back to 24 hours.

The time of the last successful refresh of a CRL cache can’t be determined from modification time of $FWDIR/database/CrlCache_1/rec_<random string> file (this is where CRL cache is stored on the file system, more on that later). Modification time of this file is updated on every CRL fetch attempt, even if it was unsuccessful.

In case you would want to find out how much time is left until the CRL cache will be deleted, vpn debug could be used.

vpn debug excerpt while the CRL is checked by a gateway:

(For the sake of brevity, part of debug output has been omitted)

[vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] fwCRLCache_GetFromCache: entered. [vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] fwCRL_CRLisValid: [vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] crl start grace period=7200 crl end grace period=1800 crl size val=0 [vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] fwCRLCache_Get: dp 'http://gaia-sms:18264/ICA_CRL3.crl' [vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] fwCRLCache_Get: crl 0x6ede91a0, &amp;amp;lt;strong&amp;amp;gt;exp 86060&amp;amp;lt;/strong&amp;amp;gt; [vpnd 24579 2012128960]@cp-gw-01[16 Mar 19:42:57] fwCRLCache_Get: tempcrl (nil), exp 0

If a gateway was unable to refresh the CRL cache in a period of 24 hours, then the cache is deleted from the gateway. Also the modification time of the& $FWDIR/database/CrlCache_1/rec_<random string> file stops being updated by subsequent fetch attempts.

When there is no valid CRL cache, the gateway tries to fetch it either every hour, or when there is a necessity (e.g. when some peer is trying to establish VPN tunnel).

How is the cache stored on a gateway?

The gateway stores a local copy of the CRL in multiple places:

strace output for the vpnd process while fetching the CRL:

(For the sake of brevity, part of debug output has been omitted)

1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] nnfwFetchCRL_cb: Entering for dp: http://gaia-sms:18264/ICA_CRL3.crln&amp;quot;, 118) = 118 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwFetchCRL_cb: 1 X509 CRLsn&amp;quot;, 76) = 76 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] Issuer: O=gaia-sms..9m8yyinThis update: Tue Mar 17 07:12:24 2015 Local TimenNext update: Tue Mar 24 07:12:24 2015 Local Timenn&amp;quot;, 175) = 175 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwFetchCRL_cb: Good CRL, successful fetch&amp;amp;lt;/strong&amp;amp;gt;.n&amp;quot;, 92) = 92 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwFetchCRL_cb: &amp;amp;lt;strong&amp;amp;gt;Writing CRL to web server n&amp;quot;, 90) = 90 1752 open(&amp;quot;/opt/CPsuite-R77/fw1/conf/extender/MyCRL/3ac593becbfc9eb649937af9ca1306d5.crl&amp;quot;, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 43 1752 write(43, &amp;quot;02021375020134621010r6t*206H206367r11550003313102763U4n2320gaia-sms..9m8yyi27r150317041224Z27r150324041224Z0+0242333132427r140704115511Z0232207627r141118084934Z240j0h0f63U3534113774Z240X240V206&amp;quot;http://gaia-sms:18264/ICA_CRL3.crl24400.13102763U4n2320gaia-sms..9m8yyi12101763U43f10ICA_CRL30r6t*206H206367r1155320211t253245203302347217A]3023371Af350$F-+2017Ilr20425623225534t33220&amp;amp;amp;gt;l274235 337307371256252z[233I&amp;amp;amp;gt;266fd6270&amp;amp;amp;gt;[210274322e322356;305]275G330267306&amp;amp;amp;lt;26?377350316207]342l217,2453042603443403359334337307224H206B210 232&amp;amp;amp;gt;4365206325`221226370264375d225253230355I23132737523211a234237w~?316240;p236240323tyB$25017275252Q2008C241214234254bP216312322M355373233372wI25634030726433323336331265350`250361)323)30D5211|Hm,]2372432303312213474t301207[37384P1v325306261315p22635426435245255::o274241344256272r207264.17353305304305431021533717735233231231=363252217{236/!eM200246267|&amp;quot;, 513) = 513 1752close(43) = 0 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: Put CRL (http://gaia-sms:18264/ICA_CRL3.crl) in the memory cache - timeout 86400, crl_to 86400n&amp;quot;, 160) = 160 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: Put CRL in the FDB file till Thu Mar 19 10:10:18 2015 nn&amp;quot;, 120) = 120 1752write(2, “[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] CrlDB::Key: key= 27c1ece094c15bfb48c78c960ecba984nn, 100) = 100 1752write(8, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_store: save 517 bytes in '27c1ece094c15bfb48c78c960ecba984'n&amp;quot;, 113) = 113 1752write(8, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_filename_pre: return /opt/CPsuite-R77/fw1/database//CrlCache_1/tmpXXXXXX n&amp;quot;, 126) = 126 1752 open(&amp;quot;/opt/CPsuite-R77/fw1/database//CrlCache_1/tmpC7J1aD&amp;quot;, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 44 1752write(2, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_filename_pre: return /opt/CPsuite-R77/fw1/database//CrlCache_1/rec_27c1ece094c15bfb48c78c960ecba984 n&amp;quot;, 153) = 153 1752 rename(&amp;quot;/opt/CPsuite-R77/fw1/database//CrlCache_1/tmpC7J1aD&amp;quot;, &amp;quot;/opt/CPsuite-R77/fw1/database//CrlCache_1/rec_27c1ece094c15bfb48c78c960ecba984&amp;quot;) = 0 1752write(8, &amp;quot;[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRL_Hook_cb: first successful fetch. This fetch will be processed.n&amp;quot;, 118) = 118

• Dynamic memory of vpn process – this is from where gateway actually reads the CRL cache in order to check certificate validity.

VPND memory dump fragment:

• $FWDIR/conf/extender/MyCRL/ directory.

After fetching the CRL from the distribution point, the gateway also puts a CRL copy into the $FWDIR/conf/extender/MyCRL/ folder.

The copy of the CRL stored there is in regular format (X.509 v2 CRL) and could be viewed by standard utilities.

• $FWDIR/database/CrlCache_1/ directory.

Another CRL copy is placed in the $FWDIR/database/CrlCache_1/ folder.

The filename has the format rec_<CrlDB Key>. The administration guide states that this file is actually the local CRL cache. The truth is this file is used only for reference on the file system, you couldn’t replace it by another (e.g. newer) CRL. As mentioned before, the copy used by the gateway is stored in memory.

vpn debug excerpt while saving the CRL cache locally:

[vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: Put CRL (http://gaia-sms:18264/ICA_CRL3.crl) in the memory cache - timeout 86400, crl_to 86400 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fwCRLCache_Put: Put CRL in the FDB file till Thu Mar 19 10:10:18 2015 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] CrlDB::Key: buf= http://gaia-sms:18264/ICA_CRL3.crlinternal_ca [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] &amp;amp;lt;strong&amp;amp;gt;CrlDB::Key: key= 27c1ece094c15bfb48c78c960ecba984&amp;amp;lt;/strong&amp;amp;gt; [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_new: name= /opt/CPsuite-R77/fw1/database//CrlCache version= 1 [vpnd 1752 1978582720]@cp-gw-01[18 Mar 10:10:18] fdb_new: path= /opt/CPsuite-R77/fw1/database//CrlCache_1 processed.

This copy of the CRL can not be viewed by standard tools, as it’s stored in a non-regular format.

The difference is in the first four bytes of the file, which are prepended to X.509 CRL by Check Point. I presume this might be the result of some hash function.

What is the maximum size of the CRL cache?

There is a SecureKnowledge article sk19836 that states that the gateway has a 1 Mb buffer to store the CRL cache. However, it also has a recommendation not to exceed 10K size.

How to manually flush a CRL cache?

You could force a CRL cache deletion by running the command

# vpn crl_zap

The whole directory $FWDIR/database/CrlCache_1/ is deleted upon its execution, but the CRL cache is kept in memory for a few more minutes.

How to view a cached CRL from a gateway’s CLI?

The cache could be viewed by running the command

# vpn crlview -view &amp;amp;amp;lt;path-to-CRL&amp;amp;amp;gt;.

Remember, though, that you can not view the file in $FWDIR/database/CrlCache_1/ by this utility, instead you should use the one located in $FWDIR/conf/extender/MyCRL/ directory.

What happens if a gateway has failed to check the received certificate against the CRL?

In case the gateway was neither able to locate the appropriate CRL in its cache, nor fetch one from the distribution point (which is the security management server in this ICA scenario), the tunnel establishment will fail with the following message:

Hence, you should ensure the reliability of the CRL distribution point(s).

The other way to approach the temporary inaccessibility of the CRL distribution point is to increase the CRL cache validity period. In this case however you’ll have to face the tradeoff between security and impact of a CRL distribution point failure.

At last, quick troubleshooting tips to resolve CRL-related issues:

  1. Check current time and date on a gateway, CRL might not be valid yet from a gateway perspective (check NTP settings)
  2. From a gateway, check the CRL distribution point reachability by http (use wget or curl utilities) (check port 18264)
  3. If the issue has not been resolved by the first two steps, enable vpn debug and look for the word “CRL” in the output.

Maxim Bilyukov is a Technical Solutions Architect at AKON Technologies. He has been working with Check Point Firewalls for five years. If you want to contribute as well, click here.

We have hundreds of automation elements to prevent problems from occurring in your environment. Check out our top picks for Check Point firewalls automation. 

BlueCat has acquired LiveAction

It’s official! BlueCat has acquired LiveAction’s network observability and intelligence platform, which helps large enterprises optimize the performance, resiliency, and security of their networks.

Learn more