iCall CRL update with Route Domains and Auto-Sync
Problem this snippet solves: iCall script to update CRL file within F5 BIG-IP when the HTTP request must run from a specific Route Domain and also uses logger to write logs to the default LTM location. The original was to also update an iFile of the CRL file for use within an iRule however I have removed that due to it being a very special case (I may add another snippet later to detail that one). Important point here is we update the CRL file located within a folder (or partition) that was linked to a Sync-Only Device Group with auto-sync enabled e.g. CRL files are created and saved to /Common/ crl / This way the iCall script does not need to trigger any sort sync and the rest of the configuration can be left as manual sync. Code : sys icall handler periodic /Common/someCrl-CrlUpdate { arguments { { name rd value 2 } { name url value https://172.31.0.1/somepath/to/crlUpdateFile.crl } { name host value somecrl.CADomein.com } { name folder value tempCrlDirectory } { name sslCrl value /Common/crl/someCrlFile.crl } } interval 600 script /Common/iCallCrlUpdate } sys icall script /Common/iCallCrlUpdate { app-service none definition { set logTag "iCallCrlUpdate" set logLevel "notice" # Getting handler provided arguments foreach arg { rd url host folder sslCrl ifileCrl } { set $arg $EVENT::context($arg) } # Create a directory to save files to disk set crlDir /var/tmp/$folder exec mkdir -p $crlDir exec /bin/logger -i -t $logTag -p local0.$logLevel "Running, CRL URL=$url, Host=$host, SSL CRL=$sslCrl, iFile CRL=$ifileCrl, Directory=$crlDir, rd=$rd" # Download CRL file from provided route domain (rd) and url arguments and save to temporary directory set status [exec /usr/bin/rdexec $rd /usr/bin/curl-apd -s -o $crlDir/LatestCRL.crl -w %{http_code} -H Host:$host $url] if {$status == 200} { # Update F5 SSL CRL file tmsh::modify sys file ssl-crl $sslCrl source-path file:$crlDir/LatestCRL.crl exec /bin/logger -t $logTag -p local0.$logLevel "F5 CRL files update complete." } else { exec /bin/logger -i -t $logTag -p local0.error "Command /usr/bin/rdexec $rd /usr/bin/curl-apd -s -o $crlDir/LatestCRL.crl -w '%{http_code}' -H 'Host: onsitecrl.trustwise.com' $url, failed with status=$status" } } description none events none } Tested this on version: 12.1
SSL client profile - certificate authentication - multiple CRL files
Hi guys, currently I'm running a tests with certificate-based user authentication, using LTM/APM. In general everything is working fine, except for the fact, that there is no option to check several CRL files in one SSL client profile. As there are multiple CAs, that have issued client certificates, I need to check several CRL files. The documentation is not very specific about this piece of information. There are only statements, that it is not allowed to have multiple CRLs in a single master file. I have tried to use CRLDP, but this does only work in conjunction with LDAP. I can only provide the CRLs via file upload to BIG-IP or via HTTP downloads from an internal server. The only idea I have so far, but which is still not tested, is to use several SSL client profiles, one for each Trusted CA, assign the correct CRL file, stored locally on the BIG-IP, and the assign the SSL client profiles dynamically, based on the requested hostname in the SNI extension. To be honest, I cannot believe that there is no easier way to achieve this. Any ideas on that? Thanks in advance. Greets, svs
Support dynamic CRL check for clientSSL profile (BIG-IP 15.1)
Hi, Did anyone tested (dynamic) CRL validator object for client SSL profile? (BIG-IP v15.1): It should work in v 15.1 (fixed bug 743758 - https://cdn.f5.com/product/bugtracker/ID743758.html ) I'm getting following errors for all client certificates: err tmm1[21207]: 01a40008:3: Unable to build certificate trust chain for profile /clientssl_profile tmm1[21207]: 01260009:4: clientIP:62042 -> VIP:443: Connection error: ssl_hs_do_crl_validation:6014: alert(46) unknown certificate error With CRL File it works ok, but file does not automatically fetch, check, and cache CRL files… Kr, EPXCreate Your Own Certificate Authority
Problem this snippet solves: The main goal of this article is to share an easy way to create your own Certificate Authority (CA) for your lab enviroment with APM module. REF - https://github.com/DariuSGB/LabCA This repository is composed by a set of scripts that give you an easy way to: Create your own root CA. Create your own intermediate CA, signed by your root CA. Create your own certs, signed by your intermediate CA or your root CA. Create your own OCSP cert, for using it in your OCSP responder. Create your own CRL cert, for using it directly in your APM. Revoke your certs (remember to refresh your CRL cert after that). Create your own PKCS#12 cert (from regular PEM certs/keys) for installing it in your windows enviroment. Invoke a OCSP responder of your certs enviroment (remember to create a OCSP cert first). How to use this snippet: Download and install your enviroment using these commands: git clone https://github.com/DariuSGB/LabCA.git cd LabCA chmod +x $(ls | grep -v README) Tested this on version: 14.1F5 BIG-IP LTM VE - disk space issue
We do have a cron job running which updates a CRL file on regular basis in order to allow F5 to use up to date CRL file for verification of client certificate during mTLS. What we have noticed is, that the HDD space is constantly being filled up. We did some investigation and we found out, that there are always files being created in the ./config/filestore/.trash_bin_d/ folder Please see below an example ls -lh ./config/filestore/.trash_bin_d/.backup_1597885592_196_d/Common_d/certificate_revocation_list_d/:Common:trust2408-full_88715_317 ls -lh ./config/filestore/.trash_bin_d/.backup_1597885592_196_d/Common_d/certificate_revocation_list_d/:Common:trust2408-prod_79040_294 trust2408-prod / trust2408-full are the certificate revocation lists created by the script. This is causing, that the file system below is full and F5 can no longer operate properly Here is a difference within 24 hours Status from 19/08/2020 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--vda-set.2._config 2.1G 467M 1.5G 24% /config Status from 20/08/2020 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--vda-set.2._config2.1G805M1.2G41% /config I see that there are 10 files generate in less than 24 hours, each file has 43M. At the end of the day it will eat up all free space and cause F5 to not function properly any longer. I would expect, that these files which are in "./config/filestore/.trash_bin_d/.backup_nnnn " foler are automatically removed by F5 on regular basis. Or am I missing anything here? We do have 4 F5 load balancers which have this script enabled and only 2 of them have this issue. All the setup is the same. Has anyone experienced anything similar? Any advice is highly appreciated.
CRL & OCSP validtion of client certificates from X509 fields
I have requirement to create a Client certificate authenticated VIP with revocation checks. The problem is that the client certificate presented can be issued from one of about 100 different CAs. There is an XML feed which provides me all of the valid CA certificates and I already have a solution to get these into a certificate bundle on the F5, so that's not a problem. I also have an iRule to check the certificate fingerprint against a whitelist, again this works great. However, I am required to check for certificate revocation. Each certificate will have either (or both) a CRL distribution point or an OCSP responder listed in its X509 fields. Is there anyway I can get the 5 to automatically check for certificate revocation against these fields without having to manually import all of the CRL lists and/or setup all the OCSP responders manually? Or failing that, is the a (simplish) way for the F5 to scan the CA bundle and automatically download all the CRL files and concatenate them.
How to understand "Update CRL" field in LTM's Certificate Authority profile?
Hi, I am wondering, how should I understand the CRL related fields in LTM's CA profile (Local Traffic > Profiles > SSL > Certificate Authority)? I cannot find any documentation for this profile. I would like to use this CA profile in APM's machine certificate check and make sure that machines with revoked certificates are denied access to APM resources. I understand that the "Certificate Revocation List (CRL)" field defines a static CRL file stored locally which I previously created under System > File Management > SSL Certificate List. But using CRL without a periodic and automatic update does not make sense. But I am struggling to understand what exactly would LTM do if I check the "Update CRL" checkbox under CA profile. How would LTM update this CRL? Where would it get the information for this update from? Would it read the CRL location URL from the certificate and try to access it? Anybody has an idea on how this is meant to work?
